Uk:Any tags you like

Не соромтеся винаходити нові теґи! Якщо ви хочете позначити щось, що можна перевірити та замапити в OpenStreetMap, але для цього не існує чинної схеми теґів, ви можете винайти їх та використовувати нові теґи. Навіть популярні нині теґи колись використовувалися вперше, дуже часто без проходження процесу подання пропозиції.

Однак це не означає «не соромтеся ігнорувати наявні схеми теґів і почати позначати аптеки за допомогою unicorn=parking_lot». Крім того, не можна використовувати мапінг під рендерер – не зловживайте усталеними теґами лише для того, щоб зімітувати певну поведінку для певного споживача даних, особливо, коли використані теґи мають інше призначення. І, звісно, одностороння зміна визначення наявних теґів чи ключів неприйнятна, тому будьте обережні, створюючи нове значення для наявного ключа.

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

Документування теґів, відсутніх в Обʼєктах мапи

Основна стаття: Створення сторінок описів теґів чи їх значень (en)

Отже, ви дотримувалися рекомендацій і шукали у Вікі, об’єктах мапи, пропонованих об’єктах, відхилених об’єктах, пропонованих звʼязках і архівах списків розсилки і все ще не можете знайти теґ для того, що ви хотіли б замапити? Taginfo, мабуть, є найкориснішим сховищем підбору теґів. У ньому перераховуються теґи, які фактично використовувалися в базі даних, і як часто вони використовувалися. Він також містить список інших теґів, які використовувалися в поєднанні з будь-яким конкретним теґом на одному об’єкті.

Пам’ятайте, що OpenStreetMap не має жодних обмежень щодо вмісту теґів, які можна призначити точкам, лініям або полігонам. Ви можете використовувати будь-які потрібні теґи, але будь ласка, задокументуйте їх тут, у Вікі OpenStreetMap, навіть якщо вони не потребують пояснень. Документування дозволяє іншим знаходити ваші об’єкти або навіть виправляти помилки на мапі, які вони можуть зустріти поряд з вами.

Документування особливо корисне пізніше, якщо хтось запропонує теґування для підмножини обʼєктів, які ви додаєте. Тоді ваш досвід і обʼєкти можна включити в цей процес подання пропозиції, і в можливо навіть перевести в нову схему теґування, якщо її приймуть.

Вибір теґів для використання

Наприклад, якщо ви хочете нанести на карту всі гнізда  білого лелеки, ви повинні створити сторінку endangered_nest=сiconia_ciconia і задокументувати на цій сторінці для чого він використовується. Будьте готові, що хтось інший може пізніше запропонувати іншу та більш структуровану схему для документування інших аспектів життя видів, що знаходяться під загрозою зникнення, теґування, яке також дозволяє документувати знахідки їх посліду також, це може використовуватись для захисту територій від зведення нової забудови.

Ви можете переглянути, наприклад, Стандарти IOF щодо класифікаційних стандартів, які використовуються в мапах для орієнтування, щоб перевірити, чи вони допоможуть вам і, чи ваш новий теґ може бути сумісним з потребами (цих) користувачів. Ймовірно, існують інші подібні документи.

Коли створювати пропозицію

Ви повинні створити пропозицію для своїх обʼєктів, якщо:

1. Ваші обʼєкти становить загальний інтерес, або
2. Ви не впевнені, як саме їх додавати, або
3. Остання запропонована форма для їх позначення була відхилена, або
4. Ви хочете змінити значення теґу, який вже використовується
5. Ви хочете отримати відгуки від інших маперів, зокрема людей із різних регіонів

(Зауважте, що створення пропозиції не є вимогою для того, щоб ваші обʼєкти зʼявились на Стандартній мапі [1], а також затвердження пропозиції не є гарантованим способом, щоб ваші обʼєкти зʼявились на Стандартній мапі [2] також. Однак, якщо ваш об’єкт пройшов процес пропозиції та був прийнятий більшістю, у вас, звичайно, буде набагато більше людей, які проситимуть показати об’єкт, таким чином підвищуючи шанси його появи на основних мапах.)

Чого не треба додавати на мапу

Сутності в базі даних OpenStreetMap мають стосуватися певної території чи об’єкта з географічними характеристиками. Наприклад, додавання розташування базової станції точки доступу WLAN вважається прийнятним, але додавання великої кількості точок них з позначенням рівня сигналу є небажаним. Таку інформацію краще зберігати в окремому сервісі.

Будь ласка, враховуйте домовленості спільноти, щодо практики мапнігу та перевірюваності даних. Не додавайте на мапу історичні, тимчасові чи гіпотетичні обʼєкти, такі як рейтинги чи сферу діяльності того, чи іншого законодавчого органу.

Примітка, щодо обмеження щодо мапінгу приватної інформації.

Як називати нові теґи

Це спроба задокументувати наявні домовленості, якими користуються люди, які винаходять нові теґи, на основі поточних теґів з Map features і останніх пропозицій. Виправлення та додаткові форми, які люди бачили у широкому використанні, будуть із задоволенням прийняті!

Теґ – в термінах програмного забезпечення (key, value) є парою рядків Юнікоду, який ми записуємо у вигляді key=value.

Залежно від того, чи підходить те, що ви хочете, до певної вже визначеної категорії, ви можете визначити новий основний ключ, нове значення для наявного ключа, нову властивість, яка змінює одну чи більше комбінацій ключ/значення, або новий метод уточнення.

Якщо сумніваєтеся, чи варто визначати щось абсолютно нове, чи використовувати наявну комбінацію з новими властивостями чи вдосконаленнями, зважте на те, що:

• нові властивості не повинні змінювати усталені визначення таким чином, що суперечить очікуванням здорового глузду щодо них

Домовленості щодо синтаксису нових теґів

Рядки, вибрані для частини key, мають деякі традиційні форми:

• В ідеалі, key – має складатись з одного слова, в нижньому регістрі, з використанням британського правопису англійської, за можливості.
• Якщо це неможливо, ключ має представляти концепцію, слова якої поєднуються символом_підкреслення. Це дозволяє уникнути деяких проблем із пробілами, і загалом сталося тому, що люди OSM також мають тенденцію бути програмістами та люблять подібний синтаксис.
• Деякі символи мають особливе значення в різному контексті, і використання цих символів у ключах, ймовірно, спричинить усілякі проблеми. Серед символів, які не рекомендується використовувати в ключах: =, +, /, &, <, > ;, ', ", ?, %, #, @, \, . та ,.
• Бажано також уникати пробілів як символів у ключі (пробілів, вводів, табуляції тощо) та інших дивних символів, таких як недруковані символи.
• Деякі складніші ключі складаються з кількох слів або понять, розділених двокрапками. Вони повинні читатися зліва направо; декілька шаблонів уже широко використовуються:
  1. Додавання префіксів просторів назв, що схоже на деякі мови програмування. Об’єднує непов’язану інформацію у спосіб, який не суперечить іншим теґам OSM. Ідеально підходить для імпорту даних з інших джерел!
     • tiger:county=*, tiger:upload_uuid=* – все що стосується імпорту US TIGER
     • KSJ2:lat=*, KSJ2:curve_id=* – теґи, які використовувались у Japan KSJ2 import
  2. Повʼязані відомості, які разом виражають факт, що складається з кількох полів. Чудово підходить для адрес і незвичайних шаблонів назв.
     • name:left=*, name:right=* – по різні боки вулиця має різні назви (відносно до напрямку лінії-ОСМ)
     • addr:housenumber=*, addr:street=* – стосується адреси
  3. Розрізнення за кодом мови. Див Назви#Локалізація
     • name:en=*, name:cy=* – назви англійською та валійською
     • note:ja=* – примітка японською
  4. Відносно рідко. Інший шаблон, але створений у генеративний спосіб, де підчастини посилаються на інші визначені ключі. Це майже метатеґування.
     • source:name=* – джерело (source) походження відомостей для теґу name
     • source:ref=* – джерело (source) походження відомостей для теґу ref

Домовленості щодо синтаксису нових значень

Формат і умови залежать від того, чи представляє теґ якийсь обʼєкт, чи його властивість.

• Теґ може використовуватись для позначення конкретного обʼєкта (наприклад, дорога – highway) або його властивості (наприклад, ширина – width).

• Властивості можуть мати велику кількість значень, бути числовими (напр. width=2) або містити деякий перелік відповідних значень.
  • Назви – є прикладом властивостей обʼєкта (напр. теґ name=*), і ці значення є неструктурованими та гнучкими, зазвичай містять змішаний регістр, пробіли та інші спеціальні символи.

• Обʼєкти – доволі часто мають значення, які уточнюють категорію обʼєкта мапи (напр. highway=motorway).
  • Значення теґів обʼєктів слідують тим же домовленостям, що й ключі:
    • В ідеалі, значення теґу обʼєкта має бути одним словом в нижньому, з використанням британського правопису англійської, за можливості.
    • Якщо це неможливо, значення має представляти концепцію, слова якої поєднуються символом_підкреслення.

• Символ крапки з комою ";" може інтерпретуватись як роздільник значень – крапка з комою розділяє значення.

Уточнення та простори імен

У багатьох схемах теґування використовується загальний шаблон ітераційного уточнення, перевага якого полягає в тому, що схема може з часом зростати, та ставати все більш і більш описовою, залишаючись при цьому зворотно сумісною:

highway=crossing

crossing=uncontrolled

Памʼятайте про можливі конфлікти з іншими схемами теґування наслідуючи такий підхід. Уточнення також може здійснюватись за допомогою просторів імен.

Символи

База даних прийматиме будь-які символи Unicode (UTF-8) для ключів і значень. Однак найкраще для ключів (таких як highway) і значень класифікації (таких як trunk_link) використовувати символи ASCII у нижньому регістрі, підкреслення та двокрапки. Рекомендується уникати символів, які можуть викликати проблеми в різноманітному програмному забезпеченні для цих значень:

• Пробіли : Використовуйте натомість символ підкреслення '_' замість пробілів, також уникайте пробілів на початку та в кінці ключів;
• < > & / + ? # % ' " \ : Слід уникати використання спеціальних символів у XML, HTML та/або URL-адресах або використання для цитування;
• = : Оскільки знак рівняння використовується в багатьох місцях як символ розділення між ключем теґу та значенням теґу, уникайте знака рівності;
• ; : Використання крапки з комою обговорюється.

Значення довільної форми (наприклад, які використовуються для ключа name) використовують будь-які символи, які ви можете придумати. Уникайте пробілів на початку та в кінці значень.

Настанови зі стилю?

Ви можете розглядати це як посібник зі стилю, якщо хочете, але насправді це не так. Зрештою, інтерпретація залежить від користувача, і єдиним принципом, який дійсно застосовується, є  KISS («Роби коротше і простіше») або, як варіант, «Зробіть найпростіше, що може спрацювати». Чим чистіше та простіше, тим краще, якщо ви хочете, щоб більше людей прийняли ваш теґ/пропозицію.

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

• Just map
• Гарні звички
• Процес пропозиції
• How to invent tags від Jochen Topf
• Creating a page describing key or value
• Order of key parts

Споріднені визначення: ‹ any tags you want › ‹ whatever tags you want › ‹ whatever tags you like ›