Я знаю как некоторые члены сообщества призерают ботов. Видят покрывшиеся мхом данные, но продолжают призерать. Я в этом отношении более либерален и считаю, что если это можно безопасно автоматизировать, то стоит попробовать.
Так и есть, особенно в маленьких нас. пунктах. Там вообще просто в центре стоит точка, без привязки к зданию. В более крупных нас. пунктах (от 3 отделений и больше) точность гораздо лучше. Конечно из-за того, что НП размечает не на OSM, то отделения могут находиться где-то рядом. Я считаю так: лучше, чтобы пользователь пришёл и обнаружил, что отделение находится с другой стороны здания или в соседнем здании, чем пришёл и узнал, что отделения там вообще уже 2 года как нет. Я в шапке уже написал, что буду помечать отделения, в точности расположений которых есть сомнения. Сообщество потом может уточнять их местоположение, как и в случае с валидаторами. Приложения могут подсказывать пользователю, что не стоит надеяться на точность этой POI в интерфейсе.
Опять же, если такое отделение уже есть на OSM, то оно будет в приоритете, т.е. останется с корректным адресом.
Вы это знаете наверняка или предполагаете? Мне кажется, что тут вопрос сложнее, чем “не мапте по Google Maps”. Я не силён в юр. вопросах, но мы полностью придерживаемся правил НП. Взяли данные, оставили ссылку (хотя не понятно относится ли это к API) на их ресурс. Сомневаюсь, что нам необходимо знать откуда они берут каждый кусочек своих данных и проверять всю цепочку лицензиатов (где бы их ещё найти?). Более того я даже не знаю скажут ли они нам это. Мы получаем от них просто 2 сырых координаты. Могу ещё сказать, что во время проверки работы алгоритма я находил несколько отделений, которые были размечены далеко от нужного здания, хотя такой адрес на Яндекс.Картах был.
Если координаты были получены из Яндекс.Карт, то абсолютно неважно, через сколько “посредников” они прошли: вносить их в OSM нельзя. Никак и никогда.
И ещё. Есть в этом мире данные, источник которых неизвестен. Согласно правилам OSM, их нельзя вносить в базу. А можно вносить только те данные, источник которых точно известен и дал своё разрешение.
Поэтому нужно обязательно узнать у Новой Почты, откуда были взяты координаты, и можно ли эти координаты (а заодно и информацию об отделениях) вносить в OSM.
Если НП откажется рассказывать нам откуда берёт координаты или скажет, что берёт их с Яндекс.Карт, то единственный вариант - юзать геокодинг самим. Ну ок, можно попробовать что из этого получится. Где-то точность улучшится, но во многих случаях отделение будет стоять в середине улицы :(. Ещё можно попросить их, чтобы они всех сотрудников заставили включить GPS и добавить эти координаты в API. Но вероятность, что такая крупная компания сделает это для нас стремится к нулю. Посмотрим что они ответят.
А если НП не согласится дать нам разрешение на перенос отделений, то это будет печально. Ибо карты OSM мне нравятся, а вот неактуальные и куцые данные - нет.
Посмотрите тему про УкрПочту. Там используется валидация, геокодинг nominatim и ручное внесение.
По мере внесения добавляются/переименовываются улицы, здания. Единожды внеся хотя бы ref, можно будет следить. Иначе - никак.
Если НП берёт координаты с Яндекса и добавить в API GPS координаты не согласятся, то придётся делать полуавтоматическую синхронизацию. Первый раз вручную разметить всё, что Nomatim не осилил, а последующие разы опять же если Nomatim в недоумении, то тоже помогать ему ручками.
Ну, во-первых для всех точек, добавленных Nominatim’ом стоит ставить fixme=position.
На начальном этапе полуавтоматическое добавление самый верный способ.
Судя по API НП у точек есть свой ‘Ref’. Стоит узнать как часто он меняется и если достаточно устойчив,
можно воткнуть кго в OSM для уже созданных точек в качестве какого-нибудь левого тэга типа ref:novaposhta=‘…’
Тогда уже по нему в дальнейшем можно будет синхронизировать базы (время работы, удаленные/перенесенные отделения).
@militrik
C Кременчуком нет проблем. Там все отделения отлично мёрджатся, надо только удалить 2 дубликата. Гораздо более интересная ситуация с мелкими городами и сёлами, допустим: https://www.openstreetmap.org/#map=18/50.34318/30.30430. Тут скрипт не смёрджил 1-ое отделение. В итоге мы имеем 3 отделения в городе, вместо двух. Притом добавленное отделение по координатам НП расположено совсем не там, ибо геолокация Яндекса на тот момент (когда НП забивала координаты) такого адреса не знала.
В общем у этого коммита есть несколько проблем:
Дубликаты.
Неправильное местоположение там, где Яндекс карты не знают адрес. Будет отделение в центре города/улицы :).
Это я автор скрипта мержа и этого коммита. Знаю что не все идеально получилось, что заметил - подправил вручную. Но так все-таки лучше, чем было раньше
К сожалению не знал, что у вас тут похожая дискуссия уже была, иначе бы наверно тоже поучаствовал
В планах адаптировать его и для других данных, которые доступны в интернете. Например - банкоматов и отделений ПриватБанка и других банков
А скрипт вважає відділення одним і тим же, якщо розходження в координатах від вже нанесеного та даних яндекса складає N метрів? І скільки цих метрів?
Алгоритм был такой: считать корректным отделение если у него задан номер (например name=Нова Пошта 1) и находится в пределах двух километров от адреса, который предоставляет novaposhta.ua либо не имеет номера (name=Нова Пошта) и находится в пределах одного километра
В случае с Білокоровічами расстояние почти 2.5 км и скрипт, к сожалению, не распознал уже существующее отделение
Но теперь, созданное отделение имеет корректный source:pkey тег и созданную точку можно перенести в правильное место
