dudka, перш ніж пропонувати якусь схему тегування, слід продумати особливості її використання і людьми-маперами, і програмами-конвертерами, валідаторами, пошуковими сервісами. Передбачити різні нюанси. А не просто “передрати” структуру КОАТУУ як школяр “передирає” домашнє завдання, а потім на всі зауваження відгавкуватися “це проблема конвертера”, “це проблема Номінатіма”, “а я так хочу”.
Це до чого цей плач?
КОАТУУ відображає реальний адміністративний поділ України. Саме це і варто відобразити в admin_level, а не якісь видуманий dimonster’ом чи кимось іншим адмінподіл.
Ні у конвертерів, ні у номінатіма немає проблем з запропонованою схемою тегування, проблеми тільки особисто у вас.
Може вам ще налаштувати щоденну конвертацію і заливати в навігатор?
Ваше сферичне “чітать пробовалі?” абсолютно неінформативне.
Якщо є якісь проблеми з конфігом - описуйте проблему і радьтеся з розробниками osm2mp якщо чогось не розумієте. borism346зміг скористатися даними admin_level для заповнення даних районів і областей, можливо і у вас вийде.
А що воно дає? Звідки така необхідність? Наприклад, для Львівської міськради ви також пропонуєте районам виставити admin_level=9? І вас не хвилює, що місто Винники підпорядковане Личаківському району і за логікою має мати admin_level нижчий за район.
dudka, є питання. ти пропонуєш наступне:
6 - райони областей, міськради обласного значення
7 - райони міст обласного значення
8 - “голі” міста обласного значення, міськради районного підпорядкування, селищні ради, сільські ради
А як бути з “голими” містами районного підпорядкування. Тобто, міськрада мінус села, межу яких можна провести по генплану.
Потрібно намалювати “голий” [мульти]полігон і поставити на нього place=city/town і при цьому ніяких admin_level.
Аналогічно і “голі” міста обласного значення не потрібно позначати admin_level=8. Наприклад, Львів - це place=city, без admin_level=*.
Проблема у тому, що відношення multipolygon не підтримує роль admin_centre. Мене бентежить необхідність використовувати “костилі” аби однозначно звязати точку place з полігоном place. Адже тоді звязати можна буде тільки по name.
Пропоную замість відношення multipolygon юзати всеж відношення boundary без тегу admin_level, або навіть і без тегу boundary=administrative
Ніби нічого поганого й немає в цій пропозиції, але все ж якось не хочеться.
place-лінія і place-точка описують один і той же об’єкт, для кожної place-лінії завжди має існувати place-точка.
Алгоритмічно просто знайти внутрішню place-точку для place-лінії. Без зв’язку хіба значно складніше?
Конвертер розуміє полігон place і як окрему лінію, і як мультипролігон. І йому достатньо, щоби точка place була всередині полігону чи мультиполігону place з тим же name та place=xxx
Два методи прийнятні. Але відношення все ж кращі. Ті самі аргументи, що і з вулицями, але мова навіть не про це.
Якщо покрити пазлом з міськ/сільрад велику область, ви побачите, що просто place-лінії у вас почнуть зникати. Вам доведеться використовувати відношення multipolygon або ж boundary. І от перший тип відношення, на мою думку, не дуже підходить.
boundary - це ж той самий multipolygon + додаткові ролі (admin_centre, label)
Як виявилося, даних admin_level недостатньо. Як виявилося, пан olehz рік тому позначив міські райони Києва тегом place=city_district
Причому цей тег ніде не задокументований. Але Борис346 його й використав для конвертера (конвертер з конфігом Бориса ігнорує мультиполігони 6 адмін.рівня, якщо там є цей тег).
Народ! То може, треба ввести нові теги place=region (область), place=district (район в області), place=subdistrict (територія сільради чи селищної ради в районах області)? І використовувати їх для адресації. А про admin_level забути. І нехай пан Дудка крутить тим admin_level як циган сонцем