Поддерживаю. IMHO, что-то типа ref:esr=* и ref:express=* не помешало бы.
Это родилось из КЛАДР-о бота, который сам расставлял кода, поэтому ему важно было отличать то что ставят юзеры от того что ставит бот. Просто не надо ничего ставить ботом, а просто показывать расхождение - тогда и эти теги ххх:user не нужны.
Я правильно понимаю, что эти все :user - костыли для бота? Если да, то нужен скрипт, который esr:user переименует в ref:esr. Можно сделать также проверку совпадения имени на точке и в ЕСР.
А можете повторить вкратце аргументацию? Из-за множества неточностей? Ну так, можно ограничиться внесением только несомненных соответствий, а от вноса подозрительных или неоднозначных случаев отказаться.
Имхо коды КЛАДРа и ОКТМО имеет смысл обозначать через ref:kladr и ref:oktmo, тут им самое место, а от схемы *:user действительно лучше избавляться как от костылей исторических использовавшихся ботами.
Подобные коды, думается, могут весьма сильно помочь при машинной обработке данных ОСМа.
Я не вижу в них смысла если есть валидатор который их сопоставляет. Который актуализировать проще чем разбросанные данные. Где эти коды могут с лёгкостью удалить. И первоначально *:user= использовали только для тех случаев, когда автоматически сопоставить объекты не получалось, а не на всё подряд.
А если кто-то захочет сделать сервис который по коду ОКТМО пользуясь данными ОСМа отображает геометрию или дополнительную информацию? И это только гипотетический пример, мало ли для чего может понадобиться явное соответствие между ОСМовскими объектами и кодами госструктур. Или вы предложите разработчику самостоятельно строить дерево муниципалитетов и проводить соответствия, т.е. по факту дублировать функции валидатора, вместо того что бы сразу воспользоваться готовыми данными?
Кроме того если у нас есть поддерживаемый валидатор, то он сможет уведомлять людей о смене кодов и уже они их актуализируют в полуавтоматическом режиме, ну и показывать когда эти коды кто-то удалит, так что проблем с актуализацией и гипотетическими удалениями, лично я, особых не вижу.
P.S.: Обсуждение уже свелось к оффтопику, может переместиться куда-нибудь?
А с валидатор нормально функционирует? Просто например здесь ситуация не обновилась после изменений внесённых более недели назад, хотя дата дампа уже вроде обновилась как минимум два раза с тех пор.
Данные OSM в валидаторе пока от 2 июня. Дата обновления - это дата прогона парсера, пришлось это сделать, в частности, из-за того, что после изменения точности данных по координатам все значения стали равны 1.0000000.
Ещё раз спасибо за увеличение разрядности координат. Тут другая напасть вылезла - не хватает escaping-а кавычек в файлах csv.
В частности ломается на такой строке (файл osm2esr.csv):