0001947: Импорт точек с одинаковыми названиями и координатами

Notes
(0011525) zed (manager) 06-06-2013 11:33	>Поскольку у меня это изменение не сохранено отдельным коммитом, вот его дифф: Наложите свой дифф на отдельный клон репо, подчистите закомментированный код и сделайте пул реквест.

(0011526) vasketsov (manager) 06-06-2013 11:58	>Реализована проверка координат с учётом погрешности и в случае если координаты и название совпадают - метка не импортируется Не понял, а можно попонятнее? Сейчас есть возможность не создавать дублирующую метку с тем же названием. Идея - разрешить создавать дубли меток с тем же названием, если они достаточно далеко от всех других меток с таким же названием? А цель какая?

(0011527) vdemidov (manager) 06-06-2013 12:13	>Качество кода тоже может быть не ахти, поскольку я дельфи изучал исключительно внося изменения в SasPlanet Ну оставленные закомментированные куски кода свидетельствуют не о незнании делфи, а о небрежности.

(0011528) Robbi (developer) 06-06-2013 12:14	Идея вот в чем: Есть kml файл с точками. Делаем импорт в категорию 1. Из категории1 точки переносим в категорию 2, 3, 4 .... , меняем значки меток по необходимости. kml изменился, очищаем категорию 1, импортируем, получаем дубли всех точек перенесённых в 2, 3, 4 ... Поскольку метод equal их теперь определяет разными. И по какой-то причине при повторном импорте точки координаты оказывались не равными, а отличающимися на очень небольшую величину. Чтобы побороть это я добавил проверку не равенства координат, а разницы между ними.

(0011529) zed (manager) 06-06-2013 12:39 edited on: 06-06-2013 12:51	>И по какой-то причине при повторном импорте точки координаты оказывались не равными, а отличающимися на очень небольшую величину. По причине того, что это тип Double и простое сравнение переменных такого типа, как например Integer, не прокатывает. Неочевидные особенности вещественных чисел How to compare double in delphi?

(0011530) Robbi (developer) 06-06-2013 12:55	Ну я не стал уточнять, но "какая-то причина" может быть как на этапе импорта так и на этапе экспорта в формат kml. Округление с другой точностью или ещё что. Плюс одна точка может быть в разных исходных файлах с одним именем, но минимально отличающимися координатами

(0011531) vasketsov (manager) 06-06-2013 13:23 edited on: 06-06-2013 13:25	>получаем дубли всех точек перенесённых в 2, 3, 4 Не обязательно, в принципе можно сделать пропуск дублей по имени и без учёта категории, то есть глобально. >координаты оказывались не равными, а отличающимися на очень небольшую величину А что будет клинически плохого, если метки в базе меток чуть-чуть сдвинутся в пределах погрешности (это будут сантиметры)? Или в исходном файле постулируется существование нескольких разных меток с одинаковыми именами в разных местах?

(0011532) Robbi (developer) 06-06-2013 13:35	если метки сдвинутся - это не имеет значения. Одноименные объекты - часто встречаются, например в БД церквей России есть одноименные, но в разных местах, в БД АЗС и других объектов, где сам факт наличия точки с определенной иконкой важнее названия.

(0011533) vasketsov (manager) 06-06-2013 14:07	То есть правильно ли я понял, что требуется следующее: а) для каждой импортируемой метки ищем метку с таким же точно названием (среди всех категорий) в некотором радиусе; б1) если не нашли ни одной - создаём новую; иначе б2) если нашли одну - обновляем существующую метку (мало ли описание поменялось, координату уточнили, иконку заменили и т.п.); иначе б3) если нашли более одной - значит обновлять будем аналогично б2, но ближайшую к импортируемой. Так? >сам факт наличия точки с определенной иконкой важнее названия Если первое верно - тогда это непонятно, что значит важнее названия, если название метки - это один из атрибутов поиска дублей? Если была АЗС и переименовалась, должен появиться дубль при импорте или нет?

(0011534) Robbi (developer) 06-06-2013 15:26	Да, за исключением того, что обновлять не надо, приоритет за данными уже находящимися в БД. Максимум что может иногда стоит обновить - описание. Если точка переименовалась, то достоверного способа определить переименовалась ли или была создана новая в том же месте нет, кроме как хранить ещё и данные об источнике или ещё какую доп. информацию, поэтому надо добавлять переименованную метку. Наличие точки с иконкой важнее названия точки в случае данных типа: азс, ограничение скорости, опасное место и т.д. Важно увидеть иконку. Поэтому все азс могут иметь одно название, но они гарантированно будут на большом расстоянии друг от друга, поэтому должны добавляться. Если между одноименными точками расстояние в пару метров - то скорее всего это одна и та же точка

(0011535) vasketsov (manager) 06-06-2013 15:40	>Максимум что может иногда стоит обновить - описание ))))))))))))) через раз его обновлять? ))) >все азс могут иметь одно название, но они гарантированно будут на большом расстоянии друг от друга А как быть с двумя АЗС одной сети, которые находятся на разных сторонах шоссе друг напротив друга?

(0011536) vasketsov (manager) 06-06-2013 15:40	>хранить ещё и данные об источнике А если есть уникальный идентификатор в источнике - что мешает его запихнуть в метку?

(0011537) Robbi (developer) 06-06-2013 15:44	>>Максимум что может иногда стоит обновить - описание >))))))))))))) >через раз его обновлять? ))) Это стоило прочитать как иногда возможно появляется необходимость обновить описание какой-то метки, но крайне редко, поскольку в исходных kml чаще всего публикуется основная информация об объектах, крайне редко обновляемая. Расстояние между азс одной сети на разных сторонах шоссе заведомо больше 2-3 метров.

(0011538) Robbi (developer) 06-06-2013 15:48	>>хранить ещё и данные об источнике >А если есть уникальный идентификатор в источнике - что мешает его запихнуть в >метку? Ну как вариант можно хранить имя исходного файла, например, но это сомнительный идентификатор источника.

(0011539) vasketsov (manager) 06-06-2013 17:30	>основная информация об объектах, крайне редко обновляемая Тогда мне непонятно, в чём проблема разрешить фиктивные обновления. Кроме того, приоритет существующей информации над импортируемой ставит под вопрос саму идею импорта данных из некоего источника. Либо этому источнику доверяют, либо он недоверенный, и данные проходят аудит. А так изменения в данные вносятся не в месте их возникновения - это всегда плохо. >можно хранить имя исходного файла Нонсенс. Идентификатор надо брать из источника, откуда появляются импортируемые данные. Такое ощущение, что решается задача какого-то очень странного импорта непонятно чего, причём подробности тщательно скрываются ))).

(0011540) Robbi (developer) 06-06-2013 18:20	Да ничего не скрывается, уже называл, база данныг геокешинга, база данных церквей России, база данных музеев, база данных азс и прочее. Давно пора закрыть инцидент, код который я написал решает мою задачу на 100%. И проще не добавлять в программу эту функцию чем придумывать кому ещё она в таком виде может понадобиться

(0011541) vasketsov (manager) 06-06-2013 21:10 edited on: 06-06-2013 21:15	>база данныг геокешинга, база данных церквей России, база данных музеев, база данных азс и прочее Откуда это, как обновляется, официальная ли информация,...? >код который я написал решает мою задачу на 100% Это только так кажется (только не надо злиться и возражать). Весь мой опыт разработки ИС подсказывает, что этот код решает какую-то одну очень частную задачу, и в лучшем случае решает её только сейчас, так как приведённое решение неустойчиво к изменению выходных данных. Даже простой вопрос, что будет при переходе АЗС от одной сети к другой, уже ставит в тупик алгоритм и приводит к дублям. Про демонтаж АЗС даже как-то заикаться неудобно ))) Но прежде всего непонятно даже, почему кажется, что все эти принципиально разные (в контексте импорта и синхронизации с внешним источником) данные могут импортироваться по ОДНОМУ алгоритму.

(0011542) Robbi (developer) 06-06-2013 21:23	Да я и не злюсь. Не надо возражать-не буду. Я не ставлю вопроса синхронизации, только импорта данных без очевидного дублирования. БД АЗС можно полностью удалить и импортировать заново, ничего не пострадает. одно лишнее действие ручками отменяет написание кучи кода для синхронизации. Я много кода написал чтобы эти БД с оф сайтов скачать, поэтому мудрить полноценную синхронизацию - это лишнее. Для меня задача стоит так: С нескольких сайтов я периодически скачиваю kml, добавляю в сас в категорию неразобранное. на досуге просматриваю и перемещаю в категорию посетить интересное, меняя иконку. Посещенные лежат в третьей категории с третьей иконкой. Мне важно чтобы не портилось содержимое второй и третьей категории при обновлении первой и в первой не создавались дубли того, что уже есть во второй и третьей. Это всё немного упрощённо, конечно, описано, но оно работает =) Раз в таком виде лишь кажется, что код уже полгода решает успешно задачу, значит можно смело закрывать тикет, обсуждать-то нечего :)

(0011543) Robbi (developer) 06-06-2013 21:27 edited on: 06-06-2013 21:28	>>база данныг геокешинга, база данных церквей России, база данных музеев, база >данных азс и прочее >Откуда это, как обновляется, официальная ли информация,...? geocaching.su http://www.karabin.ru/waypoints/ http://www.temples.ru/ http://nataturka.ru/ http://www.stations.rn-card.ru/gps/poi/rosneft_kml.zip http://avtocart-neft.ru/mapfiles/all_avtocart.kml http://www.lukoil.ru/new/azslocator/ ... Что-то на сайтах лежит, для каких-то сайтов я написал качалки с парсерами и генераторами kml

(0011545) vasketsov (manager) 07-06-2013 10:07	>http://www.lukoil.ru/new/azslocator У АЗС имеет смысл раскидывать по папкам (подкатегориям) сразу по регионам, тогда можно использовать оригинальную официальную нумерацию (идентификацию). В этом смысле при наличии официального источника импорт как раз должен подразумевать обновление существующих точек (возможно даже фиктивное). Я кстати был бы не прочь официальные АЗС лукойла с метками именно синхронизировать, а не просто что-то чтобы залетело, и потом разбираться. >http://www.karabin.ru/waypoints Подобные "базы" скорее всего вообще плохо устроены для автоматизированного импорта. Как пример - можно налететь на такое: http://www.karabin.ru/waypoints/viewtopic.php?t=2283 Исходя из возможного дублирования точек прямо в источнике, указания им произвольного названия, получается, что надо искать дубли при импорте по категории и координатам, и название как раз в идеале исключать (тема может быть переименована). Разве нет? >geocaching.su Все тайники имеют сквозную нумерацию, которую можно использовать для идентификации (как имя метки), и тогда это обычный импорт без приколов. Разве нет? >мудрить полноценную синхронизацию На самом деле для такой синхронизации надо лишь ссылку на источник (тип источника). Поскольку ранее таких задач в сасе не было (в сасе вообще отсутствует понятие синхронизации базы меток с внешними источниками), вполне можно сделать по уму как надо. Для SML потребуется добавить строковое поле, для SQLite вообще ничего добавлять не потребуется. Именно с этим и связан мой интерес к этой задаче. А не чтобы какую-то частность закодить.

(0011546) vasketsov (manager) 07-06-2013 10:10 edited on: 07-06-2013 10:12	Хотя вообще говоря полноценная синхронизация со ссылкой на источник и не нужна здесь нигде. Даже когда берутся POI с форума (http://www.karabin.ru/waypoints), темы или сообщения имеют сквозную нумерацию, и даже сейчас их можно корректно импортировать по номеру темы или сообщения.

(0011547) Robbi (developer) 07-06-2013 10:27 edited on: 07-06-2013 10:28	Вы привязываетесь к безусловному использованию синхронизации во всех случаях исходя из частных, я же говорю именно о чуть более интеллектуальном импорте данных. Официальной БД лукойла нет, насколько я знаю, только то, что на сайте. У меня она появилась благодаря моему скрипту. Синхронизировать удобнее, конечно, но мне хватает раз в год скормить сайт скрипту, а потом в сас импортировать kml предварительно очистив необходимую категорию. На сайтах типа лукойла стиль и объем данных для отображения меняется регулярно и привязываться к каким-то ID крайне сложно. Я не отрицаю, что подобные "базы" могут быть криво устроены с точки зрения разработчика, с точки зрения потребителя они крайне полезны для получения более или менее актуальной информации. И для них синхронизация - глупость. только удаление старой версии и импорт новой. Сохранённые же в других категориях метки должны остаться неизменными. Если в том же месте появилась точка с другим именем - повод проверить почему. Для геокешинга вообще публикуется kml со ссылкой на сервер, так, например, гугл планета земля импортирует ссылку и кеширует kml, периодически обновляя. Использовать id для имени плохо. Я экспортирую все отобранные точки как kml для использования на навигаторе с openstreetmaps. И что я буду видеть при клике по точке? Номер, вместо краткого описания которое заложено в имени? Вариант реализации, который могу предложить я: Сделать тип категории - автообновляемая с урл. С некоторой настраиваемой периодичностью САС будет обновлять и перезаписывать все точки этой категории. Опционально - не кэшировать в этой категории точки, если существует в радиусе N метров точка с идентичным именем. Также опционально - обновлять такие точки вместо игнорирования или дописывать новое описание в конец старого - типа версионность.

(0011548) vasketsov (manager) 07-06-2013 10:36	>Официальной БД лукойла нет, насколько я знаю, только то, что на сайте Именно так. Это и есть официальная информация. >привязываться к каким-то ID крайне сложно регион + номер АЗС = уникальный ключ регион - в категорию номер - в имя метки вуаля по имени метки кстати их можно искать для навигации - что тоже дополнительный бонус, так как номера АЗС по маршруту обычно хорошо известны, они на чеках пишутся. >Использовать id для имени плохо Смысл использования - сравнение имени (то есть id). Если будет внешний идентификатор - можно будет имя формировать как угодно. То есть поиск модифицируется только в той части, использовать имя метки или использовать поле внешней ссылки. >что я буду видеть при клике по точке? Зависит от навигатора.

(0011549) vasketsov (manager) 07-06-2013 10:39	>привязываетесь к безусловному использованию синхронизации во всех случаях исходя из частных Нет. Во-первых, я утверждаю, что даже сейчас можно импортировать перечисленные точки без дублей, крректно (с точки зрения саса) формируя имя точки. Во-вторых, про отказ от импорта (и всегда только синхронизация) речь не идёт. Синхронизация по своей сути выполняется тогда, когда есть официальный источник данных с исчерпывающей информацией. В приведённых примерах есть такие источники, а есть и просто несинхронизируемые помойки типа karabin.ru/waypoints

(0011550) Robbi (developer) 07-06-2013 10:43	Ну на словах то всё красиво, я понимаю это, и уже давно просчитывал эту возможность и отказался от ней, это требует гораздо более тщательной подготовки данных исходных, и хорошо, если есть возможность kml сформировать самому добавив необходимые данные в необходимой форме.

(0011551) Robbi (developer) 07-06-2013 10:45	>несинхронизируемые помойки типа karabin.ru/waypoints Зато именно в таких местах можно найти упоминания очень интересных объектов =)

Users who viewed this issue
User List	Anonymous (3719x), MATPOC (1x), vdemidov (1x)
Total Views	3721
Last View	24-11-2024 22:09

Issue History
Date Modified	Username	Field	Change
06-06-2013 11:29	Robbi	New Issue
06-06-2013 11:33	zed	Note Added: 0011525
06-06-2013 11:58	vasketsov	Note Added: 0011526
06-06-2013 12:13	vdemidov	Note Added: 0011527
06-06-2013 12:14	Robbi	Note Added: 0011528
06-06-2013 12:39	zed	Note Added: 0011529
06-06-2013 12:51	zed	Note Edited: 0011529	View Revisions
06-06-2013 12:51	zed	Note Edited: 0011529	View Revisions
06-06-2013 12:55	Robbi	Note Added: 0011530
06-06-2013 13:23	vasketsov	Note Added: 0011531
06-06-2013 13:25	vasketsov	Note Edited: 0011531	View Revisions
06-06-2013 13:35	Robbi	Note Added: 0011532
06-06-2013 14:07	vasketsov	Note Added: 0011533
06-06-2013 14:10	vdemidov	Additional Information Updated	View Revisions
06-06-2013 14:39	vdemidov	Tag Attached: импорт
06-06-2013 14:39	vdemidov	Tag Attached: метки
06-06-2013 15:26	Robbi	Note Added: 0011534
06-06-2013 15:40	vasketsov	Note Added: 0011535
06-06-2013 15:40	vasketsov	Note Added: 0011536
06-06-2013 15:44	Robbi	Note Added: 0011537
06-06-2013 15:48	Robbi	Note Added: 0011538
06-06-2013 17:30	vasketsov	Note Added: 0011539
06-06-2013 18:20	Robbi	Note Added: 0011540
06-06-2013 21:10	vasketsov	Note Added: 0011541
06-06-2013 21:15	vasketsov	Note Edited: 0011541	View Revisions
06-06-2013 21:23	Robbi	Note Added: 0011542
06-06-2013 21:27	Robbi	Note Added: 0011543
06-06-2013 21:28	Robbi	Note Edited: 0011543	View Revisions
07-06-2013 10:07	vasketsov	Note Added: 0011545
07-06-2013 10:10	vasketsov	Note Added: 0011546
07-06-2013 10:12	vasketsov	Note Edited: 0011546	View Revisions
07-06-2013 10:27	Robbi	Note Added: 0011547
07-06-2013 10:28	Robbi	Note Edited: 0011547	View Revisions
07-06-2013 10:36	vasketsov	Note Added: 0011548
07-06-2013 10:39	vasketsov	Note Added: 0011549
07-06-2013 10:43	Robbi	Note Added: 0011550
07-06-2013 10:45	Robbi	Note Added: 0011551
11-06-2013 08:07	vdemidov	Relationship added	duplicate of 0000900
11-06-2013 08:07	vdemidov	Status	new => resolved
11-06-2013 08:07	vdemidov	Resolution	open => duplicate
11-06-2013 08:07	vdemidov	Assigned To	=> vdemidov
11-06-2013 08:07	vdemidov	Status	resolved => closed

SASGIS