Uk:Один об’єкт — один елемент в OSM

From OpenStreetMap Wiki
Jump to: navigation, search
Доступні мови — One feature, one OSM element
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

Один об’єкт — один елемент в OSM — одна з гарних звичок. Це означає, що один об’єкт реального світу треба мапити тільки одним елементом OSM.

Об’єкти мапи

Загальні правила

Елемент OSM повинен представляти тільки один об’єкт реального світу:

  • Об’єкт, який містить будівлі на території (наприклад: школа), треба мапити як земельну ділянку окреслену полігоном з полігонами будівель в середині. Теґи потрібно додавати до полігону земельної ділянки, а не будівлям, попри те що будівлі можуть бути різними (тому що будівлі на території школи можна вважати частиною школи).
  • Об’єкт, що є будівлею, форма і положення якого відомі, повинен бути полігоном з відповідними теґами.
  • Об’єкт, положення якого відомо, але форма якого або невідома, або не має значення, повинен з’явитися як точковий об’єкт з відповідними теґами.
  • Об’єкт, який неможливо описати одним полігоном зазвичай позначається за допомогою зв’язку. Знов таки, теґи такого об’єкта потрібно додавати до зв’язку, а не до членів зв’язку. Якщо теґи не розповсюджуються на всіх членів зв’язку - в такому випадку кожен член позначається власними теґами. Наприклад:
    • relation:waterway - для позначення довгих річок
    • relation:route - для позначення туристичних маршрутів, маршрутів громадського транспорту, або інших маршрутів
    • relation:site - для позначення будинків, що знаходяться в різних локаціях, але укладають єдину сутність, наприклад будівлі університету що розділений на кілька кампусів

Приклади невдалих випадків

  • Полігон будівлі, що представляє об’єкт певного призначення, з точкою інтересу (PОІ) в середині. Перенесіть теґи з точки на будівлю і вилучіть точку.
  • Полігон, що представляє територію з єдиною будівлею, що позначена теґами. Перенесіть теґи на зовнішній об’єкт, лишивши на полігоні будівлі тільки ключ будівлі.
  • Полігон, що представляє територію, на якій знаходиться полігон будівлі, в середині якої знаходиться точка з теґами. Перенесіть теґи на полігон території з будівлі та точки, вилучивши точку.

Випадки, коли кілька теґів можуть бути потрібні

  • Більше ніж два схожих об’єкти на одній території, наприклад дві школи на спільній території. Зазвичай, якщо школи є окремими, вони повинні мати окремі території, але якщо вони відрізняються лише будівлями, територію треба позначити відповідним теґом landuse=, а будівлі — позначити кожну окремо.
  • Будинки багатоцільового призначення. Будівлю потрібно позначити теґом building=*, а ПОІ в середині позначити точками чи полігонами, що відповідають об’єктам в середині будівлі, наприклад: магазини в торговому центрі

Застосування теґів

Один теґ повинен відповідати лише за одну сутність:

  • Сутність може мати кілька псевдонімів, до тих пір доки вони стосуються ідентичних понять, використання одного теґу канонічного виду є гарним рішенням.
  • Теґи можуть охоплювати кілька різновидів однієї сутності, але вони не повинні об’єднувати різні поняття.
  • Високорівневі теґи можуть мати ієрархію сутностей, там де вони не можуть бути однозначні (ви можете створити щось своє у разі потреби), або там де тип невідомий. Вкладення атрибутів іноді є корисним (напр. natural=wetland + wetland=reedbed).

Недоліки:

  • Теґи «Парасольки». Напої можливо придбати в різних місцях. Ці місця можуть бути різними сутностями — бари, кафе, магазини, торгові автомати, питний фонтанчик і т.д. Хтось може спроектувати систему пошуку напоїв і може використовувати такі об’єкти й розробити відповідні правила, щоб звузити вибір.

Винятки: вулиці

Вулиці є (спірним) виключенням з наведеного правила. Одна вулиця з однією назвою, яку люди вважають однією сутністю, зазвичай, представляється множиною з’єднаних ліній, кожна з яких має спільну назву (теґ name=*) але відмінні значення для інших теґів. Це може розглядатись як порушення цього правила. Однак, така практика вже є сталою і найближчим часом зміни не передбачаються. Для групування відрізків вулиці в один об’єкт використовується зв’язок Relation:street, але такий підхід не набув широкого використання.

Зауважте, що цей випадок застосовується тільки до вулиць (ліній, позначених теґом "highway"). У всіх інших випадках об’єкти мають позначатись одним (набором) теґом(ів), як про це йдеться на початку.

Дивіться також

  • Relation:multipolygon — спосіб позначення складних полігонів (поширений приклад: об’єкти розділені дорогою)
  • Relation:site, якщо об’єкт не може бути представлений простим мультиполігоном (об’єкти розпорошені по місцевості чи регіону)
  • building:part=* — описує спосіб позначення складних будинків