|
Notes |
|
|
(0011525)
|
|
zed
|
|
06-06-2013 11:33
|
|
>Поскольку у меня это изменение не сохранено отдельным коммитом, вот его дифф:
Наложите свой дифф на отдельный клон репо, подчистите закомментированный код и сделайте пул реквест. |
|
|
|
|
>Реализована проверка координат с учётом погрешности и в случае если координаты и название совпадают - метка не импортируется
Не понял, а можно попонятнее?
Сейчас есть возможность не создавать дублирующую метку с тем же названием.
Идея - разрешить создавать дубли меток с тем же названием, если они достаточно далеко от всех других меток с таким же названием? А цель какая? |
|
|
|
|
>Качество кода тоже может быть не ахти, поскольку я дельфи изучал исключительно внося изменения в SasPlanet
Ну оставленные закомментированные куски кода свидетельствуют не о незнании делфи, а о небрежности. |
|
|
|
(0011528)
|
|
Robbi
|
|
06-06-2013 12:14
|
|
Идея вот в чем:
Есть kml файл с точками.
Делаем импорт в категорию 1.
Из категории1 точки переносим в категорию 2, 3, 4 .... , меняем значки меток по необходимости.
kml изменился, очищаем категорию 1, импортируем, получаем дубли всех точек перенесённых в 2, 3, 4 ... Поскольку метод equal их теперь определяет разными. И по какой-то причине при повторном импорте точки координаты оказывались не равными, а отличающимися на очень небольшую величину. Чтобы побороть это я добавил проверку не равенства координат, а разницы между ними. |
|
|
|
(0011529)
|
|
zed
|
06-06-2013 12:39
(edited on: 06-06-2013 12:51) |
|
|
|
|
(0011530)
|
|
Robbi
|
|
06-06-2013 12:55
|
|
|
Ну я не стал уточнять, но "какая-то причина" может быть как на этапе импорта так и на этапе экспорта в формат kml. Округление с другой точностью или ещё что. Плюс одна точка может быть в разных исходных файлах с одним именем, но минимально отличающимися координатами |
|
|
|
(0011531)
|
|
vasketsov
|
06-06-2013 13:23
(edited on: 06-06-2013 13:25) |
|
>получаем дубли всех точек перенесённых в 2, 3, 4
Не обязательно, в принципе можно сделать пропуск дублей по имени и без учёта категории, то есть глобально.
>координаты оказывались не равными, а отличающимися на очень небольшую величину
А что будет клинически плохого, если метки в базе меток чуть-чуть сдвинутся в пределах погрешности (это будут сантиметры)? Или в исходном файле постулируется существование нескольких разных меток с одинаковыми именами в разных местах?
|
|
|
|
(0011532)
|
|
Robbi
|
|
06-06-2013 13:35
|
|
если метки сдвинутся - это не имеет значения.
Одноименные объекты - часто встречаются, например в БД церквей России есть одноименные, но в разных местах, в БД АЗС и других объектов, где сам факт наличия точки с определенной иконкой важнее названия. |
|
|
|
|
То есть правильно ли я понял, что требуется следующее:
а) для каждой импортируемой метки ищем метку с таким же точно названием (среди всех категорий) в некотором радиусе;
б1) если не нашли ни одной - создаём новую;
иначе
б2) если нашли одну - обновляем существующую метку (мало ли описание поменялось, координату уточнили, иконку заменили и т.п.);
иначе
б3) если нашли более одной - значит обновлять будем аналогично б2, но ближайшую к импортируемой.
Так?
>сам факт наличия точки с определенной иконкой важнее названия
Если первое верно - тогда это непонятно, что значит важнее названия, если название метки - это один из атрибутов поиска дублей?
Если была АЗС и переименовалась, должен появиться дубль при импорте или нет? |
|
|
|
(0011534)
|
|
Robbi
|
|
06-06-2013 15:26
|
|
Да, за исключением того, что обновлять не надо, приоритет за данными уже находящимися в БД. Максимум что может иногда стоит обновить - описание.
Если точка переименовалась, то достоверного способа определить переименовалась ли или была создана новая в том же месте нет, кроме как хранить ещё и данные об источнике или ещё какую доп. информацию, поэтому надо добавлять переименованную метку.
Наличие точки с иконкой важнее названия точки в случае данных типа: азс, ограничение скорости, опасное место и т.д. Важно увидеть иконку. Поэтому все азс могут иметь одно название, но они гарантированно будут на большом расстоянии друг от друга, поэтому должны добавляться. Если между одноименными точками расстояние в пару метров - то скорее всего это одна и та же точка |
|
|
|
|
>Максимум что может иногда стоит обновить - описание
)))))))))))))
через раз его обновлять? )))
>все азс могут иметь одно название, но они гарантированно будут на большом расстоянии друг от друга
А как быть с двумя АЗС одной сети, которые находятся на разных сторонах шоссе друг напротив друга? |
|
|
|
|
>хранить ещё и данные об источнике
А если есть уникальный идентификатор в источнике - что мешает его запихнуть в метку? |
|
|
|
(0011537)
|
|
Robbi
|
|
06-06-2013 15:44
|
|
>>Максимум что может иногда стоит обновить - описание
>)))))))))))))
>через раз его обновлять? )))
Это стоило прочитать как иногда возможно появляется необходимость обновить описание какой-то метки, но крайне редко, поскольку в исходных kml чаще всего публикуется основная информация об объектах, крайне редко обновляемая.
Расстояние между азс одной сети на разных сторонах шоссе заведомо больше 2-3 метров. |
|
|
|
(0011538)
|
|
Robbi
|
|
06-06-2013 15:48
|
|
>>хранить ещё и данные об источнике
>А если есть уникальный идентификатор в источнике - что мешает его запихнуть в >метку?
Ну как вариант можно хранить имя исходного файла, например, но это сомнительный идентификатор источника. |
|
|
|
|
>основная информация об объектах, крайне редко обновляемая
Тогда мне непонятно, в чём проблема разрешить фиктивные обновления.
Кроме того, приоритет существующей информации над импортируемой ставит под вопрос саму идею импорта данных из некоего источника. Либо этому источнику доверяют, либо он недоверенный, и данные проходят аудит.
А так изменения в данные вносятся не в месте их возникновения - это всегда плохо.
>можно хранить имя исходного файла
Нонсенс. Идентификатор надо брать из источника, откуда появляются импортируемые данные.
Такое ощущение, что решается задача какого-то очень странного импорта непонятно чего, причём подробности тщательно скрываются ))). |
|
|
|
(0011540)
|
|
Robbi
|
|
06-06-2013 18:20
|
|
|
Да ничего не скрывается, уже называл, база данныг геокешинга, база данных церквей России, база данных музеев, база данных азс и прочее. Давно пора закрыть инцидент, код который я написал решает мою задачу на 100%. И проще не добавлять в программу эту функцию чем придумывать кому ещё она в таком виде может понадобиться |
|
|
|
(0011541)
|
|
vasketsov
|
06-06-2013 21:10
(edited on: 06-06-2013 21:15) |
|
>база данныг геокешинга, база данных церквей России, база данных музеев, база данных азс и прочее
Откуда это, как обновляется, официальная ли информация,...?
>код который я написал решает мою задачу на 100%
Это только так кажется (только не надо злиться и возражать). Весь мой опыт разработки ИС подсказывает, что этот код решает какую-то одну очень частную задачу, и в лучшем случае решает её только сейчас, так как приведённое решение неустойчиво к изменению выходных данных.
Даже простой вопрос, что будет при переходе АЗС от одной сети к другой, уже ставит в тупик алгоритм и приводит к дублям. Про демонтаж АЗС даже как-то заикаться неудобно )))
Но прежде всего непонятно даже, почему кажется, что все эти принципиально разные (в контексте импорта и синхронизации с внешним источником) данные могут импортироваться по ОДНОМУ алгоритму.
|
|
|
|
(0011542)
|
|
Robbi
|
|
06-06-2013 21:23
|
|
Да я и не злюсь. Не надо возражать-не буду.
Я не ставлю вопроса синхронизации, только импорта данных без очевидного дублирования. БД АЗС можно полностью удалить и импортировать заново, ничего не пострадает. одно лишнее действие ручками отменяет написание кучи кода для синхронизации. Я много кода написал чтобы эти БД с оф сайтов скачать, поэтому мудрить полноценную синхронизацию - это лишнее.
Для меня задача стоит так: С нескольких сайтов я периодически скачиваю kml, добавляю в сас в категорию неразобранное. на досуге просматриваю и перемещаю в категорию посетить интересное, меняя иконку. Посещенные лежат в третьей категории с третьей иконкой. Мне важно чтобы не портилось содержимое второй и третьей категории при обновлении первой и в первой не создавались дубли того, что уже есть во второй и третьей. Это всё немного упрощённо, конечно, описано, но оно работает =) Раз в таком виде лишь кажется, что код уже полгода решает успешно задачу, значит можно смело закрывать тикет, обсуждать-то нечего :) |
|
|
|
(0011543)
|
|
Robbi
|
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
|
|
|
|
|
>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
|
07-06-2013 10:10
(edited on: 07-06-2013 10:12) |
|
Хотя вообще говоря полноценная синхронизация со ссылкой на источник и не нужна здесь нигде. Даже когда берутся POI с форума (http://www.karabin.ru/waypoints), темы или сообщения имеют сквозную нумерацию, и даже сейчас их можно корректно импортировать по номеру темы или сообщения.
|
|
|
|
(0011547)
|
|
Robbi
|
07-06-2013 10:27
(edited on: 07-06-2013 10:28) |
|
Вы привязываетесь к безусловному использованию синхронизации во всех случаях исходя из частных, я же говорю именно о чуть более интеллектуальном импорте данных.
Официальной БД лукойла нет, насколько я знаю, только то, что на сайте. У меня она появилась благодаря моему скрипту.
Синхронизировать удобнее, конечно, но мне хватает раз в год скормить сайт скрипту, а потом в сас импортировать kml предварительно очистив необходимую категорию.
На сайтах типа лукойла стиль и объем данных для отображения меняется регулярно и привязываться к каким-то ID крайне сложно.
Я не отрицаю, что подобные "базы" могут быть криво устроены с точки зрения разработчика, с точки зрения потребителя они крайне полезны для получения более или менее актуальной информации. И для них синхронизация - глупость. только удаление старой версии и импорт новой. Сохранённые же в других категориях метки должны остаться неизменными. Если в том же месте появилась точка с другим именем - повод проверить почему.
Для геокешинга вообще публикуется kml со ссылкой на сервер, так, например, гугл планета земля импортирует ссылку и кеширует kml, периодически обновляя.
Использовать id для имени плохо. Я экспортирую все отобранные точки как kml для использования на навигаторе с openstreetmaps. И что я буду видеть при клике по точке? Номер, вместо краткого описания которое заложено в имени?
Вариант реализации, который могу предложить я: Сделать тип категории - автообновляемая с урл. С некоторой настраиваемой периодичностью САС будет обновлять и перезаписывать все точки этой категории. Опционально - не кэшировать в этой категории точки, если существует в радиусе N метров точка с идентичным именем. Также опционально - обновлять такие точки вместо игнорирования или дописывать новое описание в конец старого - типа версионность.
|
|
|
|
|
>Официальной БД лукойла нет, насколько я знаю, только то, что на сайте
Именно так. Это и есть официальная информация.
>привязываться к каким-то ID крайне сложно
регион + номер АЗС = уникальный ключ
регион - в категорию
номер - в имя метки
вуаля
по имени метки кстати их можно искать для навигации - что тоже дополнительный бонус, так как номера АЗС по маршруту обычно хорошо известны, они на чеках пишутся.
>Использовать id для имени плохо
Смысл использования - сравнение имени (то есть id).
Если будет внешний идентификатор - можно будет имя формировать как угодно.
То есть поиск модифицируется только в той части, использовать имя метки или использовать поле внешней ссылки.
>что я буду видеть при клике по точке?
Зависит от навигатора. |
|
|
|
|
>привязываетесь к безусловному использованию синхронизации во всех случаях исходя из частных
Нет.
Во-первых, я утверждаю, что даже сейчас можно импортировать перечисленные точки без дублей, крректно (с точки зрения саса) формируя имя точки.
Во-вторых, про отказ от импорта (и всегда только синхронизация) речь не идёт. Синхронизация по своей сути выполняется тогда, когда есть официальный источник данных с исчерпывающей информацией. В приведённых примерах есть такие источники, а есть и просто несинхронизируемые помойки типа karabin.ru/waypoints |
|
|
|
(0011550)
|
|
Robbi
|
|
07-06-2013 10:43
|
|
|
Ну на словах то всё красиво, я понимаю это, и уже давно просчитывал эту возможность и отказался от ней, это требует гораздо более тщательной подготовки данных исходных, и хорошо, если есть возможность kml сформировать самому добавив необходимые данные в необходимой форме. |
|
|
|
(0011551)
|
|
Robbi
|
|
07-06-2013 10:45
|
|
>несинхронизируемые помойки типа karabin.ru/waypoints
Зато именно в таких местах можно найти упоминания очень интересных объектов =) |
|