|
Notes |
|
|
|
Согласен, что это неправильно, вот только не знаю на каком уровне исправлять:
Можно исправить импорт GPX (тогда любой новый импорт может вернуть проблему).
Можно исправить экспорт в KML что бы он проверял количество точек в пути.
Можно добавить проверку валидности геометрий при сохранении в базу меток (путь минимум из 2-х точек, полигон минимум из 3-х точек)
Но правильнее всего сделать все три исправления. То есть, добавить гарантию, что в базе меток должны быть валидные геометрии и не допускать добавления невалидных. |
|
|
|
(0016265)
|
|
zed
|
|
03-08-2015 08:55
|
|
|
По-моему, нужно исправлять в первую очередь именно импорт GPX. |
|
|
|
|
|
|
|
(0016268)
|
|
zed
|
|
03-08-2015 12:49
|
|
|
|
|
|
|
Судя по всему да, но я не уверен. |
|
|
|
(0016277)
|
|
zed
|
|
03-08-2015 16:11
|
|
|
А можно ещё пофиксить фабрику TGeometryLonLatFactory.CreateLonLatLine чтобы она не создавала из невалидных данных невалидную геометрию. |
|
|
|
|
|
Нельзя. Тогда ты не сможешь новый трек начать рисовать. |
|
|
|
|
>в базе меток должны быть валидные геометрии
С точки зрения базы меток, линия в одну точку - валидна?
Если НЕТ, то при импорте валидного GPX точка должна дублироваться.
Если ДА, то при экспорте в KML точка должна дублироваться.
Не должно быть потери данных.
Одна точка в треке в gpx может быть просто следствием деления трека на сегменты, что может происходить чисто технически, это никак не является основанием для игнорирования подобных треков из одной точки или замены их на обычные точки (POI). |
|
|
|
|
> С точки зрения базы меток, линия в одну точку - валидна?
ИМХО не валидна. |
|
|
|
(0016303)
|
|
zed
|
|
04-08-2015 06:51
|
|
> это никак не является основанием для игнорирования подобных треков
А по-моему, является. Во-первых, он никак не отображается визуально, а во-вторых он не несёт никакой смысловой нагрузки, что в SAS, что ещё в какой программе. И точно так же будет бесполезен трек, если эту точку продублировать. Пусть он станет валиден с точки зрения программы и kml, но он останется бесполезным мусором для конечного пользователя. |
|
|
|
(0016304)
|
|
zed
|
|
04-08-2015 07:05
|
|
|
Подскажи лучше, правильно ли я нашёл место, где нужно добавить проверку? И нужно ли там очищать массив точек (по-моему нужно) или просто делать Exit? |
|
|
|
|
>Во-первых, он никак не отображается визуально
То, что он не отображается в сасе - вообще не аргумент.
Таких кусков может быть очень много, и вместе они дадут вполне себе кусок полилинии.
Ограниченность понимания и реализации БД меток в сасе никак не отменяет того факта, что при импорте валидного gpx и обратном экспорте желательно получать тот же самый gpx; рассуждения о том, чего хочет пользователь, нужны ли ему эти данные, какие атрибуты навешаны на точки в треке (тэги) - это всё не более чем фантазии, которые могут ничего общего с реальностью не иметь.
Реальность - она в том, что полилиния, составленная из кучки сегментов, каждый из которых валиден, является валидной линией и должна корректно отображаться, и формат gpx допускает создание числа сегментов равным числу точек в треке.
>будет бесполезен трек, если эту точку продублировать
Будет в треке информация о том, что в данное время в данной точке был прибор.
Может быть информация о причине разрыва трека (данные по спутникам).
А вообще если бы сас импортировал все атрибуты точек трека, такого вопроса бы у вас просто не возникло.
>ИМХО не валидна
Ок.
А линия из двух точек, если вторая совпадает с первой?
>нужно ли там очищать массив точек
Потеря данных - самое страшное, что может быть.
Так что надо просто проверить, если при создании линии одна точка, то оставить её для следующего возможного сегмента (в который она и уйдёт), а если следующий не сегмент линии (линия кончилась), то тогда добавить кусок из двух таких точек. |
|
|
|
(0016309)
|
|
zed
|
|
04-08-2015 10:38
|
|
>То, что он не отображается в сасе - вообще не аргумент.
Ну, он и в GoogleEarth не отображается точно так же. Сколько ещё программ надо протестировать, чтобы оно стало аргументом? :)
> что полилиния, составленная из кучки сегментов
Это да, но тут несколько иной случай - полилиния из одного сегмента с одной точкой: http://www.gpslib.ru/tracks/info/9043
C одной стороны, я согласен, что по возможности нужно импортировать всё, что только можно. С другой стороны, без возможности увидеть на карте эту точку или просмотреть какие-либо дополнительные сведения о ней, будешь только тыкаться на эту точку и видеть пустоту. И спрашивать себя: "Что это за фигня?". |
|
|
|
|
>в GoogleEarth не отображается точно так же
Очевидно, из-за того, что в KML это невалидно?
>Сколько ещё программ надо протестировать
Ровно одну: валидатор GPX.
>несколько иной случай
А как ты предлагаешь различать эти случаи при импорте?
Я потому и предлагаю притягивать такие точки к существующим секциям, а если только одна, то сохранять с дублем (чтобы инфа не пропадала, раз уж в сасе нужен дубль для линии).
>полилиния из одного сегмента с одной точкой
Если валидный с точки зрения GPX объект предлагается вообще не импортировать, то тогда говорить о реализации импорта GPX не приходится.
>без возможности увидеть на карте эту точку
Видимость метки - не главное.
Главное - информация (атрибуты).
Кроме того, в принципе возможно даже найти невидимую метку по имени и перейти к ней, можно объединить несколько невидимых меток в одну, и тогда такая кучка "недолиний" станет видимой.
>просмотреть какие-либо дополнительные сведения о ней
Можно в менеджере меток.
Вообще говоря, аналогичная проблема может быть и для других форматов. Так что это не проблема формата, это исключительно вопрос отношения к информации. А информации там может быть много, это и данные со спутников, и температуры, и высоты-глубины, и скорость и время и прочее. Представь себе, что это всё есть в GPX и ты при импорте это просто похерил, просто потому что там одна точка, а не две, и есть проблемы с тем, чтобы её увидеть ;).
А невалидный LineString надо лечить по месту, так как для экспорта совершенно неважно, насколько наше понимание о валидности данных внутри БД саса соответствует валидности стороннего формата KML. То есть, если на вход LineString приходит одна точка, то стопудово надо её дублировать в экспорте и экспортировать с именем, категорией и прочими данными метки. |
|
|
|
|
>А линия из двух точек, если вторая совпадает с первой?
Формально сейчас с точки зрения базы вполне валидна, как и линия из одной точки. Проблема в том, что их нельзя увидеть ни на одном зуме и соответственно нельзя даже начать редактировать. Поэтому и стоит вопрос или предусматривать при рендеренге особую обработку таких случаев или запрещать метки с такой геометрией в базе.
А пока такие пути это именно источник вопросов "Что это за фигня?". |
|
|
|
(0016315)
|
|
zed
|
|
04-08-2015 11:37
|
|
>Очевидно, из-за того, что в KML это невалидно?
Нет, GE понимает gpx напрямую, без конвертирования. И тем не менее, не отображает.
>Я потому и предлагаю притягивать
Ок, согласен на такой вариант. Сделаешь? Там по-моему будет одинаково что для SAS, что для SACS. |
|
|
|
|
>Сделаешь?
Разумеется. Когда решим всё окончательно.
>предусматривать при рендеренге особую обработку таких случаев
Хм, а разве нужна особая обработка для такого случая? Там же просто bounds по размеру отсекутся, ничего и не будет показано, разве нет?
А начать редактирование по идее можно и из окна управления метками.
Меня вот интересует следующий вопрос: в полигонах есть дырки, граница дырки полигона это полилиния (всегда размерность границы это размерность фигуры минус 1 либо пусто), соответственно, если дырка в полигоне представляет собой выколотую точку, то чем же является тогда граница дырки, если не одиночной линией в одну точку? Рендерить это тоже надо, с учётом того, что под полигоном с выколотой точкой может быть другой, который и должен просвечиваться в этой точке. |
|
|
|
|
> Хм, а разве нужна особая обработка для такого случая? Там же просто bounds по размеру отсекутся, ничего и не будет показано, разве нет?
В том то и дело, что оно на всех зумах отсечется и никогда на карте не отобразится.
> А начать редактирование по идее можно и из окна управления метками.
Сейчас нельзя. Там сейчас вызывается изменение свойств метки.
>всегда размерность границы это размерность фигуры минус 1 либо пусто
Что-то ты фигню написал. Размерность полигона 2 и размерность дырки тоже 2. Трехмерные полигоны мы по сути не рассматриваем. |
|
|
|
(0016338)
|
|
vasketsov
|
04-08-2015 13:08
(edited on: 04-08-2015 13:10) |
|
>Что-то ты фигню написал
:))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Размерность точки - 0.
Размерность линии - 1.
Размерность полигона - 2.
>Размерность полигона 2 и размерность дырки тоже 2
Только если дырка является полигоном.
А вообще я писал про ГРАНИЦУ геометрического примитива.
Что ты будешь делать в случае, если дырка в полигоне является одной выколотой точкой?
>Сейчас
Ну, это же не проблема? ;) Значит, технических проблем редактировать такие линии нет.
|
|
|
|
|
|
Я рассматриваю дырки только в виде полигонов. Все остальное игнорируем. |
|
|
|
|
> Ну, это же не проблема? ;) Значит, технических проблем редактировать такие линии нет.
Ну, пока только проблема начать редактировать. |
|
|
|
|
Дырка в виде выколотой точки и так полигоном будет, так как её граница - это полилиния в виде одной точки или пары совпадающих точек.
Вопрос только в том, ты будешь для границы использовать одну точку или две одинаковых. |
|
|
|
|
>Вопрос только в том, ты будешь для границы использовать одну точку или две одинаковых.
Минимум 3. Полигон считается валидным после 3-х точек. Причем похоже нужно добавлять требование для путей и полигонов что бы MBR был не пустым. |
|