Современные БД это замечательно, но бывают и бессерверные решения. Например, у StreetComplete нет своей копии БД, они используют в качестве бэкенда Overpass API. Довольно глупо ради голой дедупликации отсекать себя от возможности использовать эти инструменты. Со временем таких инструментов будет становться все больше и больше. Например, с полным карлсруэ валидатор по списку объектов можно сделать вообще не программируя, пользуясь гугл таблицами. Поэтому было бы неплохо если бы кто-то из считающих что отсутствие дублирования в базе вызвался доработать overpass чтобы дефолтные значения полей addr:* брались из полигона при загрузке данных, а не при исполнении запроса. Это ведь несложно, как вы говорите.
“Беречь базу” и “экономия места” это очень опасные аргументы. Сейчас ради экономии мы удалим избыточный addr:*, завтра кому-то не понравится что дорога отмечена с точностью 1000 точек на километр и он упростит ее до 100 точек на километр, послезавтра еще кто-то упростит до 25 ведь “современные средства позволяют интерполировать сплайнами”. Другому покажутся избыточными площадные дороги отрисованные по openaerialmap. Третьему отдельные деревья. Это скользкая дорожка ступив на которую однажды очень трудно остановится.
То, что дедупликация помогает от ошибок это заблуждение. Когда кто-то двигает границу населенного пункта и какие-то дома вылетают из адресации или улетают в другой регион мы об это узнаем лишь случайно, когда кто-то обнаруживает что что-то не работает. А если бы у нас был полный карлсруэ, у нас была бы возможность сразу получить “красный флаг” – адреса на зданиях не соответствуют полигону границ, разбирайтесь что не так. Причем такую проверку можно сделать на maproulette даже не программируя.
То же самое с адресами на POI. OSM это живая карта, там постоянно кто-то что-то двигает. Если POI нет собственного адреса и ее сдвинули за пределы здания, она теряет адресацию и мы этого никогда не узнаем. Если бы адресация была, можно было бы сделать проверку “POI с адресом за пределами здания” хоть в JOSM, хоть на maproulette. К тому же адрес POI не всегда можно вычислить из адреса здания однозначно. Скажем, школы маппятся полигоном amenity=school и на территории этого полигона бывает несколько зданий с разными адресами, в то время как адрес у школы только один.
Раз уж здесь перешли от аргументов к мнениям, предлагаю сформулировать вопросы:
-
Должны ли мапперы проставлять теги addr:country, addr:city и addr:region?
а) всегда, когда есть такая возможность
б) только если значение тега отличается от того, что можно вычислить из границ
в) допустимо эти теги не использовать
г) не должны никогда
-
Как мапперы должны поступать с существующими тегами addr:country, addr:city и addr:region?
а) удалять всегда
б) удалять только если значение отличается от того, что можно вычислить из границ
в) удалять только если значение ошибочное
г) исправлять если значение ошибочное и не трогать если значение правильное
-
Как мы должны относиться к массовым правкам тегов addr:country, addr:city и addr:region на основании вычисленных из границ значений?
а) автоматизированные правки в этом вопросе недопустимы
б) автоматизированные правки допустимы только если они добавляют теги, правки удаляющие или изменяющие эти теги недопустимы
в) автоматизированные правки допустимы только если они удаляют теги, дублирующие информацию которую можно вычислить из границ
г) автоматизированные правки допустимы во всех случаях
Исходя из ответов на эти вопросы у нас три стратегии:
- Автоматически удалить все теги addr:country, addr:city, addr:region если они дублируют информацию которую можно вычислить из границ и в дальнейшем систематически удалять эти теги и проводить разъяснительную работу с мапперами, которые их используют. Т.о. теги addr:country, addr:city, addr:region останутся только в качестве костыля для ситуаций когда адресация почему-то не соответствует границами.
- Автоматически заполнить недостающие теги addr:city, addr:region и в дальнейшем поощрять автоматическую и полуавтоматическую синхронизацию этих тегов с полигонами границ.
- Не трогать существующие теги специально но и не давать автоматически их исправлять. Т.е. на долгое время законсервировать существующее положение вещей когда полную схему карлсруэ использовать на практике бесполезно, а исправлять ее руками бессмысленно.
Было бы неплохо, если бы люди, склоняющиеся к первой или второй стратегии задались вопросом “готов ли лично я вести эту работу?”
