Інкерман є частиною Балаклавського району, тому admin_level Інкермана має бути нижчим(більшим), ніж admin_level Балаклавського району:
Інкерман admin_level=8
Балаклавський район admin_level=7
Я наполягаю, щоби всі райони, ради та інші **утворення всередині населених пунктів **понизити на 9 рівень. Щоби не було плутанини: чи то Шевченківський район входить у місто Київ, чи то місто Київ входить у Шевченківский район.
Бо комп’ютер - не людина, і не зрозуміє таких “очевидних” речей. Для нього існують лише точка з тегами place=city, name=Київ та полігон з name=Шевченківський район, admin_level=6.
Або інший приклад: полігон з name=Шевченківський район, admin_level=6 та точка з place=village, name=Тетянівка (у Харківській обл). Ось тут як бути? Що конвертеру робити? Включати Тетянівку до Шевченківського району чи вважати Шевченківський район частиною Тетянівки?
І взагалі, дуже погано, що у нашій класификації немає поняття “населений пункт”. Бо карту, в якій неможливо визначити межі кожного населеного пункту та його приналежність до області, району чи ради, неможливо використовувати у навігації. А без можливості “залити карту у навігатор” наша карта нічим не ліпша від гуглокарти, яндекса чи паперової карти.
А за яким шаблоном виставляти name для селищних/сільрад? Наприклад, в тій самій Львівській області, для котрої я повносив межі 70% сільрад.
І стара проблема, як бути з кордонами сіл в межах однієї сільради? Адже голубі зони (згідно кадастру) можуть бути розкидані по усій території сільради. Тобто в яких-то випадках сільрада = село, а в інших треба окремо створювати кордони сіл. І невідомо за яким принципом.
Nominatim, наприклад, вертає таку адресу при запиті на “Тетянівка”: Татьяновка, Шевченковский район, Харьковская область, 63621, Украина. Проаналізувати в яких адміністративних полігонах знаходиться центр НП і відсортувати його за admin_level - не так вже й важко
Кордони сіл в межах однієї сільради – place=village лінії/мультиполігони за принципом “не включати поля, ліси, великі водойми на околиці села”, залишаючи тільки “місця компактного чи не дуже проживання, присадибні ділянки, фабрики, заводи, ферми”. Думаю що ділянки що знаходяться десь далеко в полі, далеко від будинків не є частиною села(place=village), але адміністративно належать сільраді(admin_level=8).
Якщо сільрада = село, то має бути два звязки з однаковим списком членів:
type=boundary, boundary=administrative, admin_level=8, name=“[] сільська рада"
type=multipolygon, place=village, name="[]”
В даному випадку треба перевірити членом якого зв’язку є точка (place=city, name=Київ), звісно що вона входить до зв’язку із admin_level=4, name=Київ, а не до admin_level=6, name=Шевченківський район. Ось від цього і треба відштовхуватись. А також завдяки цьому можна перевіряти (зробити ще один валідатор ) на правильність прив’язування точки place=* до відповідного полігону place=*
dudka, перш ніж пропонувати якусь схему тегування, слід продумати особливості її використання і людьми-маперами, і програмами-конвертерами, валідаторами, пошуковими сервісами. Передбачити різні нюанси. А не просто “передрати” структуру КОАТУУ як школяр “передирає” домашнє завдання, а потім на всі зауваження відгавкуватися “це проблема конвертера”, “це проблема Номінатіма”, “а я так хочу”.
Це до чого цей плач?
КОАТУУ відображає реальний адміністративний поділ України. Саме це і варто відобразити в admin_level, а не якісь видуманий dimonster’ом чи кимось іншим адмінподіл.
Ні у конвертерів, ні у номінатіма немає проблем з запропонованою схемою тегування, проблеми тільки особисто у вас.
Може вам ще налаштувати щоденну конвертацію і заливати в навігатор?
Ваше сферичне “чітать пробовалі?” абсолютно неінформативне.
Якщо є якісь проблеми з конфігом - описуйте проблему і радьтеся з розробниками osm2mp якщо чогось не розумієте. borism346зміг скористатися даними admin_level для заповнення даних районів і областей, можливо і у вас вийде.
) на правильність прив’язування точки place=* до відповідного полігону place=*