Привіт. У нас в Україні існує проблема із адміністративними кордонами усіх рівнів, навіть із обласними - далеко не завжди на лініях адмін. зв’язків стоять теґи із рівнем кордону.
Хтось може написати коротенький скрипт, який би пройшовся по всіх веях зв’язків type=boundary, boundary=administrative? Треба на самі лінії проставити теґи boundary=administrative та admin_level=N, де N - найстарший (найменше число) серед усіх адміністративних рівнів цього вею.
Якщо чесно, давно вже час виправити цей безлад, а вручну дуже довго та постійно вилазять помилки
Мені чомусь здалося, що так має бути, бо про це в нас вже йшла мова. Окрім того, я просто подивився, як роблять в інших країнах. Плюс, плагін Relation Toolbox пропонує дублювання теґів для адмін. кордонів за замовчанням. А ще тому, що в нас в теґах цих веїв повний безлад - хтось дублює, хтось ні.
поддерживаю топикстартера! об дублировании тегов на линии для адм. границ даже в вики предельно ясно написано! только со скриптами аккуратно - в дон.обл. без скриптов сделано аккуратно все.
посути без прогрузки всех веев из всех отношений которые содерат данный конкретный участок границы - невозможно его правильно отрендерить… именно поэтому рекомендуется указывать прямо на вее теги - потому как прогружать все релейшены и все веи из этих релешенов не в каждом случае возможно
Если есть отношение, часть мемберов которого обрезаны - ты все равно можешь запросто узнать admin_level оставшихся way-ев. Другое дело, если парсер вообще не умеет работать с отношениями, но под парсеры/рендеры мапить какбы не правильно, тем более такие ущербные (которые только way понимают). Тут вики править надо, а не границы. Если покрыть всю Украину мозаикой сельрад и каждый НП обвести admin_level-ом 9 - получим около 50 тысяч полигонов, а следовательно сотни тысяч веев.
А взагалі-то все одно - дублювати чи ні. Головне один раз визначитися, прописати таке правило у вікі і робити завжди однаково. Ordnung muss sein.
Я за те, щоб дублювати.
Так проблема в тому, що реалізувати повноцінне дублювання неможливо. Тільки часткове. В силу того, що одна й та ж лінія входить у різні адмінкордони, з різними рівнями і назвами.
Писати все через крапко-кому, як заведено в OSM?
admin_level=8;9 (умовно, для прикладу)
name=Кременчуцька міська рада;Кременчуцький район
А що як лінія входить ще в треті-четверті відношення, не адмінкордони? Теж все на лінію чіпляти?
Це прямий шлях до тегозвалища, яке ніякі рендери не розберуть.
Відношення усе красиво вирішують. Через них ми можемо отримати усю необхідну інформацію. Отримана інформація буде структурованою, однозначною, несуперечливою. Отримана з веїв інформація такою не буде.
В тому то й справа, що для лінії адмінкордону не потрібна назва. Потрібні тільки 2 теґи - boundary=administrative та admin_level=*. А в admin_level прописується найстарше значення.
Відношення ніхто не відкидає, звичайно. Просто лінії потребують уточнень. Якщо дублювати, то ось такі теґи має, наприклад, кордон по річці:
Добре, давайте по простому, в кількох словах.
Будь-яка дія робиться ж не просто так, а з певною метою, вирішує якусь конкретну практичну проблему, і при цьому бажано щоб вона не створювала нових проблем. Інакше смисл дії сумнівний.
Так от, нинішня ситуація з відношеннями мені бачиться взагалі безпроблемною. Цілком припускаю, що, імовірно, я вузько мислю чи коло моїх вимог до OSM не таке широке як у інших користувачів, але все необхідне я через відношення отримую, і отримую якісно
Тому прошу розтлумачити: от ця конкретна дія з переносом тега на лінію - вона дійсно комусь здатна полегшити життя, вирішити якусь практично існуючу проблему?
Якщо це так - можна лише вітати. Тим більше коли відношення зберігаються, то я як і раніше, продовжую їх використовувати, і мені повинно бути байдуже
А якщо ні - то навіщо плодити сутності?
Пропоноване тегування - це анохронізм так само як is_in, place_name, de_place і т.п. Аргументів в користь використання цих тегів ви так і не навели. Якщо вже і писати скрипти для масового корегування, то для очистки від надлишкового сміття, а не навпаки
Я наводив аргументи, чому я підняв це питання - вище по темі гляньте. Достатньо навіть того, що кожна лінія зроблена аби як без стандартизації.
Але, як я вже казав, це навіть другорядне питання, зараз треба визначитися із способом редагування в цілому. Якщо дублювання - це анахронізм, то тоді треба видаляти всі дублі. Он вище я навів приклад річки, в якій із зв’язку дубльовано назву, тип, waterway та вікіпедію. Якщо їх прибрати, то річка в джосмі вже виглядає не синьою, а звичайною сірою лінією. Можливо, рендер взагалі не зможе розпізнати таку річку, я не пробував. Вас таке влаштовує?
Вічне питання дублювання інформації
назви вулиць на лініях доріг, будинків і звязках
назви річок на лініях, полігонах, звязках
номери доріг на лініях доріг і звязках
адмін-левели на лініях кордону і звязках
OSM-DB настільки неструктурована, що без цих дублювань не обійтися як би кому не хотілося.
Особисто я не маю нічого проти цих дублювань.
Я бачу тільки одну проблему - користувачі iD і Potlach видаляють лінії кордонів, оскільки в цих редакторах ці лінії не відображаються як кордони.
Кілька разів на місяць відбувається таке. Виправити недоліки iD і Potlach неможливо, а дублювання вирішило б цю існуючу проблему.
Можна сприймати звязки адмінодиниць(наприклад полігонів place=state) як об’єднання ліній кордонів(наприклад ліній admin_level=4), а не просто абстрактних нетегованих ліній.
