Помітив сьогодні масові правки від Kostik, суть яких зводиться до копіювання атрибутивної інформації (name:*, addr:postcode…) з точки place на полігональні кордони відношення
На мій протест проти такого дубляжу Kostik відповів, що це необхідно для osm2mp. Що є типовим прикладом мапінгу під рендер - обєктивних причин навіщо дублювати дані, а не підправити код osm2mp нема.
Загалом пропоную вичистити БД ботом від подібного хламу. Що в результаті зменьшить час на опрацювання дампу вигрузки України. В цю категорію потрапляє наступне:
Дубляж тегів на точці place/кордоні і релейшені
Дубляж тегів wikipedia (типу wikipedia:ru, wikipedia:uk)
Перенесення атрибутивної інформації про вулицю (тег wikipedia) з сегментів у відношення
Групування сегментів і будинків вулиці у відношення і видалення addr:street
Якщо хтось проти якогось з пункту, або навпаки знає про інші приклади надлишковості, дайте знати
Навіть видаливши ці дані час на опрацювання дампу або не зміниться взагалі, або зміниться настільки, що це буде непомітно. Можливо збільшиться за рахунок того, що буде створено 100500 зв’язків.
3 - за
4 - проти видалення addr:street
1,2 - всеодно
ref дублюється на лініях і в зв’язках, наприклад тут - проти видалення ref з ліній.
місцями admin_level присутній на лініях і в зв’язках, наприклад тут - проти видалення admin_level з ліній.
А можливо навпаки зменьшиться. Якщо ніхто не проти, для тесту спробую обійти ботом Львівську область і тоді побачимо результати (різницю в розмірі і різницю в часі імпорту)
Який сенс одночасно підтримувати 2 схеми? Ботом можна зводити усі нові правки до однієї (Питання лише в тому яка з них краща)
Спробуй видалити addr:street зі свого локального pbf-файлу(osmosis’ом або чимось іншим) і порівняй.
Якщо буде значно швидше - включи цю процедуру у свій процес імпорту.
Тема видалення addr:street уже підіймалась щонайменше разів 5.
Будь ласка не видаляй addr:street ні у Львівській області, ні в будь-якому іншому регіоні.
addr:street - основна схема тегування адрес, associatedStreeet-зв’язки - для внесення інформації про вулицю(додаткові name:**, wikipedia, source:name тощо)
безглуздо розпорошувати адресну інформацію по різним об’єктам, логічніше коли addr:housenumber, addr:street, addr:suburb, addr:postcode знаходяться поруч
overpass-запити, що використовують addr:street значно простіші і швидші в порівнянні з запитами, що використовують associatedStreeet-зв’язки
пустий addr:street заплутує новачків які користуються iD
Ну в такому разі треба додати addr:street на усі будинки, що залінковані за допомогою відношень. І тоді можливі 2 варіанти:
Дублювати відношеня і схему addr:*
Відмовитись цілком від відношень вулиць (навіщо потрібне дублювання? додаткові name:** на відношеннях ніде не використовується - усі існуючі рендери беруть інформацію з сегментів. А пилити відношення суто для wikipedia беззмістовно - вішати так само на сегменти аби не розпорошувати атрибутивну інформацію)
Новачків багато що заплутує. Давайте від мультиполігонів відмовимось бо це за складно? Є статистика скількі addr:street внесли через iD в порівнянні з іншими редакторами? Цей аргумент - це приклад мапінгу під рендер. Нічого не заважає вдосконалити iD для роботи з associatedStreet (редактор може сам проаналізувати усі наявні у місті вулиці і дати юзеру можливість вибирати зі списку)
Улица - это не одна дорога. Это сумма сегментов дорог (разное покрытие, разный статус, разная допустимая скорость) + сумма домов (земельных участков). В итоге когда ты меняешь тег для одного сегмента - по хорошему надо поменять его и для других. А на практике имеем ситуцию когда для одного стоит A, для другого B, а для третего вообще не проставлен. Хорошо это или плохо - я не знаю
Було б добре, addr:street зручні для одних цілей, відношення - для інших.
osm2mp, а також інші скрипто-конвертори яким накладно працювати з гео-інформацією будуть проти.
Щоб отримати англійську addr:street простіше знайти name:en у зв’язку, ніж гео-пошуком шукати найближчу лінію з відповідним name, з якої вже потім взяти name:en.
Що таке “мапінг під рендер” написано тут, згадка про нього недоречна.
Цей аргумент про те, що новачкам, та й не тільки їм зручніше користуватися простішими схемами, а не складнішими.
associatedStreet абсолютно не поширені в Європі, окрім одиничних випадків, тому не варто сподіватися, що хтось реалізує таку функціональність.
Если не ошибаюсь, то уже сейчас в iD реализовано следующее: у поля “Улица” (addr:street=) есть выпадающий список, в котором содержатся name= близлежащих улиц. Новичок просто выбирает необходимое значение.
Мне лично эта функция нравится, потому что она увеличивает количество валидных addr:street=* (например, “Квіткова вулиця”) и уменьшает количество невалидных (например, “ул. Цветочная”).
Ти пропонуєш тримати 2 датасети суто як приклад для новачків? Якщо так, то це зайве - в iD важко не здогадатись що вбити в поле вулиця
До чого тут гео-функціонал? Навіщо шукати найближчу лінію, якщо саме відношення вже містить id сегментів? Я не бачу різниці звідки брати name:en (відношення чи сегмент). Проблема з osm2mp у тому, що людям простіше дублювати дані, замість того аби зробити маленьку правку в коді
Основною гарною звичкою є запобігання використанню неправильних теґів, або ж викривлення даних, що вводяться, лише для того щоб показати певну лінію на мапі
і от саме дублювання в результаті призводить до викривлення даних (міняють щось на точці, але забувають змінити на кордоні), лише для того щоб osm2mp відпрацьовував для частини НП
Я ще дуже просто зробити опечатку. Особливо буде зручно коли доведеться шукати усі будинки за адресою вул. Леніна, і для кожного вводити текстом нову адресу
це була моя відповідь на пропозицію “Відмовитись цілком від відношень вулиць”
уяви, що немає звязків, як osm2mp робитиме переклад адрес з української на англійську?
Все ж таки дублювання і викривлення - не одне і те саме. Однакові і коректні дані на будинку і звязку чи на точці і кордоні н.п. не є викривленням.
Щоб не було опечаток і iD, і JOSM показують підказки.
Згідний, саме по собі не є. Але в результаті необхідності підтримувати усі складові відношення синхронізованими таки призводить до викривлення.
Мова про те, що відмова від обовязкової наявності addr:* нічим не загрожує (новачок завжди може внести addr:street - це поле є очевидним навіть без прикладів сусідніх будинків)
З іншої сторони обовязкова наявність addr:* створює потенційну проблему з майбутнім перейменуванням вулиць радянської доби. Замінити одне відношення простіше ніж сотні будинків.
До речі, те саме стосується і вживання addr:city. По-перше, вірогідність помилки при зміні кордонів, по-друге в Україні є приклади де одноіменні НП межують одне з одним, але знаходяться в різних районах. З іншої сторони робити сепарацію по адмінкордонам також не можна, адже є приклади, де будинки адміністративно належать одній сільраді (району), а адресу мають іншого села чи міста іншого району.
вот этого удалять ну ненужно, покрайней мере до тех пор пока там не наступит вдруг идеальный порядок. т.е. у каждого НП появится отношение с границей с включенной туда точкой и т.д. очень часто при разного рода “случайностях” восстановить исходный порядок а заодно и вобще увидеть что произошла катастрофа помогает какраз дублирование информации. как появится нормальный валидатор по НП и админграницам по украине и там будет всё чётенько - тогда можно будет избавится от дублей ботом.
На счет точек: год или 2 тому у нас было 100% соответствия с КОАТУУ (с поправкой на заброшенные села, которые все еще стояли на учете) + 100% линковка с существующими статьями wikipedia + почтовые индексы и населения (если такая информация была доступна на сайте ВР или википедии). Со временем это все начало ломаться (кто-то удалял точки, кто-то менял тег place и т.п.) Текущую ситуацию я не знаю. Но не думаю, что дубляж на границах - это лучший выход. Может лучше в рамках еженедельного задания довести валидность опять до 100% и сохранить бакап где-то на файлхостинге?
По поводу тегов на границах - думаю, надо удалить. Оставить теги в релейшенах. Ибо одна и та же линия одновременно может являться границей района, области и страны. И какой на неё admin_level ставить? Наивысший из перечисленных? Или все сразу?
Кстати, вроде бы osm2mp должен корректно обрабатывать релейшены административных кордонов. Не?
По поводу addr:street - удалять, но с осторожностью. Только если объект входит в отношение associatedStreet с таким же названием улицы.
Ну или другой вариант: удалить отношение associatedStreet и расставить везде addr:street. Но тогда москали взвоют, что у них адресный поиск на русском не работает и полезут переименовывать наши улицы на русский.
А вообще, ИМХО, бардак с системой адресации тянется уже давно и из-за этого карты ОСМ невозможно толком использовать в навигаторах. Обязательно где-то косяки всплывают. То населённый пункт не ищзется, потому что имеет “однофамильца” в соседнем районе, то улица не ищется, потому что на карте она на русском, а в поиске надо вбивать украинское название. Плюс к этому бардак с административный устройством и соответствием admin_level.
И, кстати, как правильно обозначать деревни? Я раньше делал точку посреди деревни и полигон вокруг деревни. И на точке, и на полигоне писал place=village, name=Іванівка, name:ru=Ивановка. Теперь я замечаю на карте релейшены с boundry=administrative, точка в роли admin_centre, а admin_level либо отсутствует, либо имеет значения 8 или 9.
Не хочется делать дурную работу, меняя обозначения то так, то сяк.
Если admin_level есть в отношениии то можно и не ставить. Если несколько, то ставить наивысший.
Поддерживаю.
Если отношения нет - оставлять как есть.
Если имена совпадают - удалять addr:street.
Для случая, где есть отличия - сделать валидатор и поправить на одном из ТЗ.
Также сделать валидацию для случая, когда дом не входит в отношение, но рядом есть дома, входящие в отношение с тем же названием.
Поддерживать обе схемы все равно прийдется - тут никуда не деться.
Раньше делали 8. Теперь склоняемся к варианту, где 8 - границы сеьсоветов, а 9 - самих сел. Пустой admin_level в релейшине не должно быть.