По-прежнему интересно, каким образом осуществляется поиск адреса. Буквально неделю назад рассматривался случай, когда Rocketdata имели от заказчика адрес, этот адрес был обозначен в OSM на контуре здания именно в том виде, в котором заказчик его передал, но Rocketdata по неизвестным причинам решили, что в OSM обозначено не нужное здание, а какое-то другое, имеющее иной адрес, и в итоге добавили POI в кучу мусора, расположенную даже не рядом с нужным зданием.
Создаётся ощущение, что Rocketdata адреса ищет не в OSM, а в какой-то другой адресной базе, возможно, имеющей меньше записей.
Rocketdata, не могли бы Вы прямо прояснить, каким образом Вы проверяете корректность расположения POI, имея в наличии данные об адресах? Вероятно, в Вашем алгоритме есть какой-то недостаток, из-за которого Вы добавляете дубликаты уже существующих POI (при этом дубликатами Вы почему-то называете точки, добавленные вручную другими редакторами в правильном месте) или добавляете POI там, где их и в помине нет. Мне кажется, важно понять, что проблема не в том, что пользователи находят ошибки (у кого их не бывает?), а в том, что Вы скрываете алгоритмы своей работы и не позволяете сформулировать рекомендации по их улучшению.
Точка 69 (Нижний Тагил, Свердловское шоссе, 65)
Вы собираетесь удалить весь полигон, на который указаны ещё теги здания. Это большое здание, не удаляйте.
Если магазин закрылся, но здание осталось на месте, то удалите только теги, которые относятся к POI (shop, name, name:, opening_hours, contact:, access). Остальные теги не трогайте.
Если вы уверены, что здания сносят, то помимо предыдущих изменений нужно заменить building=yes на was:building=yes, при этом оставив адресные теги.
Сам полигон должен остаться.
Если магазин закрылся, но здание осталось на месте, то удалите только теги, которые относятся к POI. Остальные теги не трогайте.
Если вы уверены, что здания снесли, то помимо предыдущих изменений нужно заменить building=yes на was:building=yes, при этом оставив адресные теги.
Сам полигон должен остаться.
Повторяю (вроде уже 2 раза говорил вам в прошлом году): внесите изменения в свой алгоритм, если Вы видите ключ building или building:part, значит лучше не удалять его.
Выборочно проверил эти точки, почти все содержали дубли. Проверьте ещё раз.
Санкт-Петербург, Балканская, 5
Опять промахнулись в соседнее здание, погрешность около 170 метров. При этом на их сайте указано правильно.
Важный момент: кинотеатры (и некоторые другие POI) редко строят новые, зато часто одна сеть покупает кинотеатры у другой сети.
Многие точки, которые вы добавляете, уже имеют “соседей” в одном ТЦ. Маленькая вероятность что в одном здании появился ещё один кинотеатр, зато скорее всего этот кинотеатр закрылся и на его месте появился другой.
Ваша задача не плодить несколько новых точек, а определить “судьбу” предыдущего кинотеатра и либо заменить теги на уже существующей точке, либо удалить старую точку.
И уточнить координаты, разумеется (для этой сети кинотеатров особенно заметно). Часто замечаю, что на сайте компании точка на карте установлена более-менее верно, а вы вносите менее точно. Не очень понял причину, нужны пояснения чтобы определить причину такого алгоритма.
Добрый вечер!
Сформировали список компаний, у которых проблемы с адресами и координатами.
Заметили, что и на их официальном сайте некоторые точки находятся в странных местах. Уже отправили на обработку. Спасибо, что почистили!
Добрый вечер!
Мы получаем данные - адрес и координаты - от клиента. И проверяем соответствие предоставленного адреса и координат вручную. Если клиент передал адрес и координаты, которые совпали, почему не должны ему верить. Дубли могут возникать, если у компании изменился идентификатор собственной точки и они загрузили вторую. Но перед загрузкой мы проверяем наличие дублей адресов.
Поставим задачу для разработки, чтобы исключал удаление полигонов.
По Билайну: у них несколько точек в одном здании, на сайте уже смотрели, но лучше проверим лишний раз.
Мираж Синема переделаем, исходя из ваших комментариев.
Спасибо большое за проверку!)
Если адрес и координаты совпали и вы верите клиенту - это хорошо. Но почему верите тогда, когда координаты ведут туда, где вообще нет здания? Полагаю, игнорирование такого симптома ошибочных данных и приводит к POI, расположенных в разных странных местах.
Как ваша система отображает ситуацию, когда клиент предлагает добавить POI в пределах здания, в котором уже ранее POI с тем же названием была добавлена без адреса? Обычные редакторы, как правило, добавляют POI точно по расположению, но без указания адреса, т. к. действуют по принципу ‘я вижу на местности, что тут есть POI - ровно сюда и ставлю, заполняя name и shop/amenity’. Да, возможна ситуация, когда в пределах одного большого торгового центра располагаются несколько магазинов одной сети, но тогда при добавлении, по идее, об этом должна иметься информация.
Здравствуйте!
По первому, заменим все на DNS Technopoint, возможно, где-то пропустили.
По второму, удалим тег vending=parcel_pickup.
Спасибо за правки!