Импорт Перекрестка

Думал, перетащить в прошлое положение будет хватать. Прошу прощения, исправлюсь.

Т. к. дубликаты погибают как-то уж больно неторопливо, хочу предложить в качестве совета алгоритм, который можно применить для первичной проверки.

  1. загружаем из областей, в которых осуществлялся импорт, все точки, линии и отношения с name=Перекресток и name=Перекрёсток,
  2. строим таблицу расстояний между всеми загруженными объектами (для линий можно брать координаты любой из точек линии, для отношений-мультиполигонов - координаты любой из точек любой из линии отношения),
  3. выделяем объекты, у которых есть “соседи” на расстоянии, скажем, менее 300 метров,
  4. внимательно смотрим на получившийся набор, размышляем, выкидываем дубликаты.

Примеры дубликатов, не удалённых на момент написания этого сообщения:
1: новая точка в 100 метрах от существующей,
2: новая точка в 50 метрах от существующей,
3: новая точка в 100 метрах от существующей (интересно, как должен выглядеть супермаркет в 5-этажной брежневке),
4: новая точка в 15 метрах от существующей,
5: новая точка в 10 метрах от существующей.

Ну и до кучи мысль по поводу дальнейшей валидации. По моим представлениям, у каждого магазина должен существовать какой-то уникальный идентификатор (как-то же их различают в отделе кадров, транспортном цехе и бухгалтерии). Его можно было бы добавить в тег ref или в специальный тег вида x5_retail_group_id. Это потом облегчало бы периодическую проверку на наличие всех магазинов в базе (в пределах страны) и нахождение нужного магазина (например, при необходимости исправить изменившийся режим работы).

P. S. Реально, а как они товар в магазины возят? Зашёл на сайт https://www.perekrestok.ru/shops/map - у них там и адреса неправильные попадаются, и точки на карте в километре от магазинов стоят. Может, обязать директора каждого магазина запустить на телефоне навигатор и выдать правильное положение?).

Магазины привязываются по адресу - это унифицированный идентификатор, без всяких там не валидируемых x5_retail_group_id. Незачем городить огород на пустом месте.

Валидация магазинов “Перекрёсток” по адресу, на мой взгляд, не взлетит: во-первых, адрес может быть не внесён в OSM, во-вторых, такой способ требует определения адреса POI из расположения зданий с соответствующим адресом, в-третьих, в базе X5 адрес может быть написан в абы каком формате (считай - не анализируемом роботом), в-четвёртых, адрес в базе X5 может не соответствовать адресу на местности и т. д. и т. п. Хороший идентификатор является уникальным и не позволяет записать себя произвольным образом (пример - цифровой код железнодорожной станции). Рискну предположить, что код магазина должен где-то отображаться в чеке (хотя могу представить ситуацию, когда фактически отдельный магазин является для финансовой отчётности одной из касс какого-то другого магазина).

P. S. Таки хочется переломить ситуацию, когда на магазин приходится по 2, а то и по 3 объекта в базе OSM (меня, извините, на проверку 700 периодически импортируемых с разных учётных записей “Перекрёстков” не хватит). Нужно предложить что-нибудь простое, понятное и работающее).

Практически все дубликаты были внесены x5_ru, самое простое - удалить те точки, что он добавил, рядом с которыми есть второй магазин.
Если кто опять начнёт вносить дубликаты - откатывать целиком сразу, как нарушающие принципы импортов. Не дожидаясь перитонитов.

Всё это попытки прикрутить квадратные колёса к велосипеду без педалей - ехать как нормальный он всё равно не будет.
Адреса добавляются, исправляются и уточняются, с этим никогда не было проблем, было бы желание.

Валидацию импортёры и не делают. “Валидацией” они называют “мы вам сейчас зальём кучу данных, но, так и быть, дадим их поисправлять перед этим”.

У заказчика требования другие, чем у маперов.
Заказчику кажется важным лишь то, чтобы все магазины были на карте.
Появятся лишние или нет они и не задумываются.

Мои претензии к импорту в текущем формате (помимо уже высказанных, к которым присоединяюсь). Из общения в чате с представителем Рокетдата я вынес, что в случае, если в базе уже был магазин, нанесенный, например, местным маппером, с временем работы, списанным с таблички, рокетдата все равно затирает это данными из базы. То есть данные с мест, с on the ground затираются данными из табличек и сайтов, которые, по моему опыту, часто не соответствуют действительности. Нарушение базового принципа проекта.

Решение: проставлять время работы только тогда, когда его нет на имеющейся точке (+ при дальнейших заливках менять его только если кроме аккаунтов Рокетдаты никто не трогал).

Мы учли ваши предложения. Сейчас мы собираемся добавить только изменения текущих точек, без создания новых.
По поводу поиска:
Мы ищем по вхождению русского и английского имени с учетом буквы Е и Ё (regex) по радиусу 100м. Также выбираем ближайшее к точке здание и ищем внутри этого здания.
Проверить будущий импорт можно по адресу https://osm.rocketdata.io/project/5084c
Имена и время работы добавляем только в случае отсутствия в точке на данный момент.

мне кажется, это мало (видя, как много “перекрестков” наставилось в центр деревень)

В любом случае, сейчас будет только обновление существующих.
По поводу поиска…нет, этого почти всегда хватает, если точка стоит в правильном месте. Сейчас у нас остались дубли в случае если координаты неправильные, либо если здание представлено в виде relation (к такому я был не готов, прямо сейчас исправляю)

Пример: координаты, в общем-то верные, адрес верный, магазин обозначен точкой, дубликат, добавленный в 15 метрах от существующей POI, не удалён.

Я описал как наше по работает сейчас. Признаю, в прошлом были проблемы, но растем, исправляемся.
За пример спасибо, исправил.

Не совсем ясно, есть ли у Вас сейчас план по поиску некорректных дубликатов, добавленных ранее, и их удалению. Это, конечно, хорошо, что к задвоенным-затроенным POI сейчас не планируется добавлять новые дубликаты, но ведь и со старыми надо разобраться, наконец. По крайней мере, на Вашей карте дубликаты не выделены.

План такой:


[timeout:1000];
node[name="Перекрёсток"];
foreach->.a(
node[name="Перекресток"](around.a:100)->.b;
(.b; - .a;);
out;
);

Буду вручную править.

ЮРИДИЧЕСКИЙ ВОПРОС.

Видел обсуждение в чате, считаю вопрос стоит действительно очень важный. Насколько я вижу, сайт предлагает вносить изменения от имени OSM-участников и в моем случае, у меня доверие, конечно, гораздо больше к этим данным и я с радостью готов их принять и редактировать.

С другой стороны, вопрос юридической чистоты очень важный, потому что большинство OSMеров не сильны в этом. И да это сложный вопрос! В OSM разрешается вносить только такие данные, которые удовлетворяют https://wiki.openstreetmap.org/wiki/RU:Open_Database_License/Contributor_Terms?uselang=ru и это совсем не лицензия ODBL! Для того, чтобы исключить неприятные случаи, что к вам массив данных попал из Yandex или из 2Гис, договор и NDA совсем не нужен. Достаточно, узнать кто обладает @Copyright на этот массив данных и то, что он опубликован по Public Domain. Например, этого можно достичь, если на сайте Перекресток будет этот массив данных и там будет ссылка на лицензию, которая подходит под Contributor_Terms.

Владеет данными компания, которая предоставляет данные о себе. Мы предоставляем компании лицензию на использование нашего ПО. Вот ссылка на наш договор с клиентом.
https://rocketdata.io/terms_and_conditions

Причем здесь ПО? БД с POI свободна или нет?

Это подходит под DbCL 1.0, т.к. клиент сам размещает данные через наше ПО. Ссылку на договор я отправил выше.