Fa:Namespace
فضای نام یا namespace پیشوند، پسوند یا میانوند برای کلید است. در موارد خاص می‌توانیم برای گروه‌بندی کلیدهایی که بسیار به هم مرتبط هستند یا به‌عنوان توصیفگر مکمل برای کلیدها آن را به کار ببریم. نویسهٔ دونقطه (:) برای جداسازی فضای نام در نام کلید استفاده می‌شود. مزیت‌های کلیدهای دارای فضای نام باید در کنار ناسودمندی‌های آن‌ها سبک‌سنگین شود.
گروه‌بندی کلیدهای بسیار مرتبط با استفاده از فضای نام کمک می‌کند که این گروه از کلیدها را مجزا کنیم که از تداخل نام‌ها پیشگیری می‌کند و بستر سطح‌بالاتری برای یک کلید خاص فراهم می‌کند.
فضاهای نام در قالب توصیفگر زمانی به کار می‌روند که یک خصوصیت (مانند کد زبان) برای گسترهٔ وسیعی از کلیدهای اصلی و نامرتبط به هم، قابل‌استفاده باشد.
از نظر فنی هر دو مفهوم تا حد زیادی یکسان دیده می‌شوند: کلیدهایی که حاوی جداساز دونقطه‌اند دقیقاً مانند هر کلید دیگری رشته‌ای از نویسه‌ها هستند.
اگر مقداری را مشابه با نحو (syntax) فضای نام ذخیره کنیم، مثلاً key:suffix=value که suffix یک مقدار متغیر است و هدف گروه‌بندی ندارد، اینجا با مفهوم فضای نام سروکار نداریم؛ صرفاً پسوندی است که با دونقطه جدا شده است.
کاربردهای نمونه از فضای نام
- addr=* برای حفظ بخشی از نشانی
- پسوند
:conditionalبرای کلیدهایی که مقداری با محدودیت‌های شرطی می‌گیرند. - تگ‌های contact=*
- فضای نام تاریخ — پسوند فضای نام تاریخ برای مشخص‌کردن اعتبار موقت تگ‌ها (در مقایسهٔ مفاهیم چرخهٔ حیات) پیشنهاد شده است؛ مثلاً
amenity:1835-1965 = schoolوname:1933-1945 = Adolf-Hitler-Straße. این پسوند آخرین بخش کلید است (مثلاً پس از پسوند کد زبان). هشدار: این syntax نسبتاً رایج است، اما صرفاً بخشی از یک پیشنهاده (proposal) است، درحالیکه از نظر فنی فضای نام مناسبی نیست. - generator:output=* برای ارائهٔ اطلاعاتی دربارهٔ توان خروجی نیروگاه تولید برق.
- is_in=* فضای نام قدیمی که هنوز در پایگاه‌داده وجود دارد.
- پسوند
:lanesبرای اطلاعات خطوط عبوری. - پیشوند چرخهٔ حیات — (در مقایسهٔ مفاهیم چرخهٔ حیات) پیشنهاد شده که از پیشوندهایی مانند
proposed:،disused:،construction:،abandoned:، یاdemolished:استفاده کنیم تا عارضه‌هایی را که در وضعیت خاصی هستند مشخص کنیم مثلا construction:aerialway=gondola. برای معابر و راه‌آهن روش دیگری به‌طور دفاکتو به کار می‌رود مانند "highway=construction + construction=motorway. مقایسهٔ مفاهیم چرخهٔ حیات را ببینید. - Multilingual names — code suffixes are in use for many keys such as "name:ro=..." indicating the Romanian name of a feature. See Map internationalization and Multilingual names for some uses. The suffix comes immediately after the main key.
- parking:lane=* and parking:condition=* to provide information about parking lanes for highway=*
- source=* to indicate source of all tags or only specific tag
- traffic:hourly=* indicate traffic density and can be used as namespace.
- Forward & backward, left & right suffixes to indicate that tag only applies in the some direction or side for the Way.
See also Namespace_tag_overview
Nomenclature
- namespace describes the whole concept (i.e. this page). When used as a prefix namespace, the word prefix is often omitted.
- prefix is the usage of a namespace in front of a key (used in Tags, Lifecycle_prefix, addr).
- suffix is the usage of a qualifier after a key (used in Tags, Conditional_restrictions, Key:name, Lanes).
- subkey is used in two contexts
- as an additional key which further describes a Feature (used in Key:waste, Key:motorboat)
- for describing a suffix (used in Lanes, Key:phone, Key:addr, Class:bicycle and Template:Tag/doc).
- infix is used very rarely (Tags, Talk right/left)
This wiki's software is also using the concept of namespaces but this is unrelated to OSM namespaces.
Consuming namespaces
At a basic level within the system, a key with a namespace will just be stored and treated as any other free-form text string (a string which just happens to have a colon character).
Many consumers of OSM data will treat keys like this. Consuming applications often match on keys they are interested in, and any unrecognised keys are ignored. This may indeed be the desired effect of a namespace. Namespaces can be used to separate out certain types of specialist information, side-lining this data away from the 'core' map data, to make it clearer that only more specialist consumers will be interested in it.
Over-namespacing
Namespacing is a great way to structure the data scheme, but it can also cause troubles for some data consumers, they call it over-namespacing.
- project related namespace; it can be tempting sometimes to just namespace a key to avoid clashing with other data instead of trying to integrate existing schemes, this is bad habit. OSM is a multi-scheme database, which means that every tag relates to more than one scheme, more than one use of the data, and so it's important to integrate with other schemes already used to maximise the curation of the data
- over-namespacing leads to inconsistency in the database: if we have projectfoobar:name=xxx and name=xxx, in many cases one will be updated and not the other. The simpler and more generic is the key, the more used it will be, the more curated it will be.
- over-namespacing leads to a disseminated data scheme: for example, someone interested in VHF channels data will have to look for harbour:VHF_channel key, plus seamark:habour:VHF_channel, plus VHF_channel, plus lock:VHF_channel, plus vhf to collect the data... Using only the vhf key should be enough to know that this data relates to the harbour or the lock or what else is the OSM object we are tagging.