SASGIS

Веб-картография и навигация
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее

My View | View Issues | Change Log | Roadmap | Search
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002777SAS.Планета[All Projects] Багpublic31-07-2015 14:0930-12-2021 08:59
Reporterzed 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version141212 
Target Version26xxxxFixed in Version 
Summary0002777: Путь из одной точки не отображается ни на одном зуме
DescriptionПопадаются треки состоящие из одной точки. Они валидны с точки зрения gpx формата, но в SAS абсолютно бесполезны в качестве пути.
Additional InformationПример трека:


<trk>

    <name>ACTIVE LOG (3)</name>

    <trkseg>

        <trkpt lat="45.03707" lon="41.97465">

            <time>2010-04-24T18:05:40Z</time>

            <ele>578.84567912015</ele>

        </trkpt>

    </trkseg>

</trk>
Tagsgpx, import, импорт, пути, путь, трек, треки
Attached Files

- Relationships
related to 0002786resolvedvdemidov При экспорте в KML пути должны содержать 2 и более точек 

-  Notes
(0016264)
vdemidov (manager)
03-08-2015 08:53

 Согласен, что это неправильно, вот только не знаю на каком уровне исправлять:
Можно исправить импорт GPX (тогда любой новый импорт может вернуть проблему).
Можно исправить экспорт в KML что бы он проверял количество точек в пути.
Можно добавить проверку валидности геометрий при сохранении в базу меток (путь минимум из 2-х точек, полигон минимум из 3-х точек)

Но правильнее всего сделать все три исправления. То есть, добавить гарантию, что в базе меток должны быть валидные геометрии и не допускать добавления невалидных.
(0016265)
zed (manager)
03-08-2015 08:55

 По-моему, нужно исправлять в первую очередь именно импорт GPX.
(0016266)
vdemidov (manager)
03-08-2015 08:59

 Согласен.
(0016268)
zed (manager)
03-08-2015 12:49

 Для этого достаточно в TXmlVectorObjects.InternalMakeTrackObject добавить проверку на FDoublePointsAggregator.Count > 1 вместо проверки на ноль?
(0016270)
vdemidov (manager)
03-08-2015 13:30

 Судя по всему да, но я не уверен.
(0016277)
zed (manager)
03-08-2015 16:11

 А можно ещё пофиксить фабрику TGeometryLonLatFactory.CreateLonLatLine чтобы она не создавала из невалидных данных невалидную геометрию.
(0016278)
vdemidov (manager)
03-08-2015 16:18

 Нельзя. Тогда ты не сможешь новый трек начать рисовать.
(0016291)
vasketsov (manager)
03-08-2015 21:39

 >в базе меток должны быть валидные геометрии
С точки зрения базы меток, линия в одну точку - валидна?
Если НЕТ, то при импорте валидного GPX точка должна дублироваться.
Если ДА, то при экспорте в KML точка должна дублироваться.

Не должно быть потери данных.
Одна точка в треке в gpx может быть просто следствием деления трека на сегменты, что может происходить чисто технически, это никак не является основанием для игнорирования подобных треков из одной точки или замены их на обычные точки (POI).
(0016299)
vdemidov (manager)
04-08-2015 06:05

 > С точки зрения базы меток, линия в одну точку - валидна?
ИМХО не валидна.
(0016303)
zed (manager)
04-08-2015 06:51

 > это никак не является основанием для игнорирования подобных треков
А по-моему, является. Во-первых, он никак не отображается визуально, а во-вторых он не несёт никакой смысловой нагрузки, что в SAS, что ещё в какой программе. И точно так же будет бесполезен трек, если эту точку продублировать. Пусть он станет валиден с точки зрения программы и kml, но он останется бесполезным мусором для конечного пользователя.
(0016304)
zed (manager)
04-08-2015 07:05

 Подскажи лучше, правильно ли я нашёл место, где нужно добавить проверку? И нужно ли там очищать массив точек (по-моему нужно) или просто делать Exit?
(0016306)
vasketsov (manager)
04-08-2015 10:15

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

Ограниченность понимания и реализации БД меток в сасе никак не отменяет того факта, что при импорте валидного gpx и обратном экспорте желательно получать тот же самый gpx; рассуждения о том, чего хочет пользователь, нужны ли ему эти данные, какие атрибуты навешаны на точки в треке (тэги) - это всё не более чем фантазии, которые могут ничего общего с реальностью не иметь.

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

>будет бесполезен трек, если эту точку продублировать
Будет в треке информация о том, что в данное время в данной точке был прибор.
Может быть информация о причине разрыва трека (данные по спутникам).
А вообще если бы сас импортировал все атрибуты точек трека, такого вопроса бы у вас просто не возникло.

>ИМХО не валидна
Ок.
А линия из двух точек, если вторая совпадает с первой?

>нужно ли там очищать массив точек
Потеря данных - самое страшное, что может быть.
Так что надо просто проверить, если при создании линии одна точка, то оставить её для следующего возможного сегмента (в который она и уйдёт), а если следующий не сегмент линии (линия кончилась), то тогда добавить кусок из двух таких точек.
(0016309)
zed (manager)
04-08-2015 10:38

 >То, что он не отображается в сасе - вообще не аргумент.
Ну, он и в GoogleEarth не отображается точно так же. Сколько ещё программ надо протестировать, чтобы оно стало аргументом? :)

> что полилиния, составленная из кучки сегментов
Это да, но тут несколько иной случай - полилиния из одного сегмента с одной точкой: http://www.gpslib.ru/tracks/info/9043

C одной стороны, я согласен, что по возможности нужно импортировать всё, что только можно. С другой стороны, без возможности увидеть на карте эту точку или просмотреть какие-либо дополнительные сведения о ней, будешь только тыкаться на эту точку и видеть пустоту. И спрашивать себя: "Что это за фигня?".
(0016313)
vasketsov (manager)
04-08-2015 11:31

 >в GoogleEarth не отображается точно так же
Очевидно, из-за того, что в KML это невалидно?

>Сколько ещё программ надо протестировать
Ровно одну: валидатор GPX.

>несколько иной случай
А как ты предлагаешь различать эти случаи при импорте?
Я потому и предлагаю притягивать такие точки к существующим секциям, а если только одна, то сохранять с дублем (чтобы инфа не пропадала, раз уж в сасе нужен дубль для линии).

>полилиния из одного сегмента с одной точкой
Если валидный с точки зрения GPX объект предлагается вообще не импортировать, то тогда говорить о реализации импорта GPX не приходится.

>без возможности увидеть на карте эту точку
Видимость метки - не главное.
Главное - информация (атрибуты).
Кроме того, в принципе возможно даже найти невидимую метку по имени и перейти к ней, можно объединить несколько невидимых меток в одну, и тогда такая кучка "недолиний" станет видимой.

>просмотреть какие-либо дополнительные сведения о ней
Можно в менеджере меток.

Вообще говоря, аналогичная проблема может быть и для других форматов. Так что это не проблема формата, это исключительно вопрос отношения к информации. А информации там может быть много, это и данные со спутников, и температуры, и высоты-глубины, и скорость и время и прочее. Представь себе, что это всё есть в GPX и ты при импорте это просто похерил, просто потому что там одна точка, а не две, и есть проблемы с тем, чтобы её увидеть ;).

А невалидный LineString надо лечить по месту, так как для экспорта совершенно неважно, насколько наше понимание о валидности данных внутри БД саса соответствует валидности стороннего формата KML. То есть, если на вход LineString приходит одна точка, то стопудово надо её дублировать в экспорте и экспортировать с именем, категорией и прочими данными метки.
(0016314)
vdemidov (manager)
04-08-2015 11:35

 >А линия из двух точек, если вторая совпадает с первой?
Формально сейчас с точки зрения базы вполне валидна, как и линия из одной точки. Проблема в том, что их нельзя увидеть ни на одном зуме и соответственно нельзя даже начать редактировать. Поэтому и стоит вопрос или предусматривать при рендеренге особую обработку таких случаев или запрещать метки с такой геометрией в базе.

А пока такие пути это именно источник вопросов "Что это за фигня?".
(0016315)
zed (manager)
04-08-2015 11:37

 >Очевидно, из-за того, что в KML это невалидно?
Нет, GE понимает gpx напрямую, без конвертирования. И тем не менее, не отображает.

>Я потому и предлагаю притягивать
Ок, согласен на такой вариант. Сделаешь? Там по-моему будет одинаково что для SAS, что для SACS.
(0016327)
vasketsov (manager)
04-08-2015 12:22

 >Сделаешь?
Разумеется. Когда решим всё окончательно.

>предусматривать при рендеренге особую обработку таких случаев
Хм, а разве нужна особая обработка для такого случая? Там же просто bounds по размеру отсекутся, ничего и не будет показано, разве нет?
А начать редактирование по идее можно и из окна управления метками.

Меня вот интересует следующий вопрос: в полигонах есть дырки, граница дырки полигона это полилиния (всегда размерность границы это размерность фигуры минус 1 либо пусто), соответственно, если дырка в полигоне представляет собой выколотую точку, то чем же является тогда граница дырки, если не одиночной линией в одну точку? Рендерить это тоже надо, с учётом того, что под полигоном с выколотой точкой может быть другой, который и должен просвечиваться в этой точке.
(0016334)
vdemidov (manager)
04-08-2015 12:55

 > Хм, а разве нужна особая обработка для такого случая? Там же просто bounds по размеру отсекутся, ничего и не будет показано, разве нет?
В том то и дело, что оно на всех зумах отсечется и никогда на карте не отобразится.
> А начать редактирование по идее можно и из окна управления метками.
Сейчас нельзя. Там сейчас вызывается изменение свойств метки.

>всегда размерность границы это размерность фигуры минус 1 либо пусто
Что-то ты фигню написал. Размерность полигона 2 и размерность дырки тоже 2. Трехмерные полигоны мы по сути не рассматриваем.
(0016338)
vasketsov (manager)
04-08-2015 13:08
edited on: 04-08-2015 13:10

 >Что-то ты фигню написал
:))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Размерность точки - 0.
Размерность линии - 1.
Размерность полигона - 2.

>Размерность полигона 2 и размерность дырки тоже 2
Только если дырка является полигоном.
А вообще я писал про ГРАНИЦУ геометрического примитива.

Что ты будешь делать в случае, если дырка в полигоне является одной выколотой точкой?

>Сейчас
Ну, это же не проблема? ;) Значит, технических проблем редактировать такие линии нет.
(0016341)
vdemidov (manager)
04-08-2015 13:25

 Я рассматриваю дырки только в виде полигонов. Все остальное игнорируем.
(0016342)
vdemidov (manager)
04-08-2015 13:25

 > Ну, это же не проблема? ;) Значит, технических проблем редактировать такие линии нет.
Ну, пока только проблема начать редактировать.
(0016344)
vasketsov (manager)
04-08-2015 13:32

 Дырка в виде выколотой точки и так полигоном будет, так как её граница - это полилиния в виде одной точки или пары совпадающих точек.
Вопрос только в том, ты будешь для границы использовать одну точку или две одинаковых.
(0016353)
vdemidov (manager)
05-08-2015 08:37

 >Вопрос только в том, ты будешь для границы использовать одну точку или две одинаковых.
Минимум 3. Полигон считается валидным после 3-х точек. Причем похоже нужно добавлять требование для путей и полигонов что бы MBR был не пустым.

- Users who viewed this issue
User List Anonymous (3820x), ingener (1x), vdemidov (52x), QDeathNick (2x), Papazol (1x), zed (32x), netsky (1x), bk99 (1x), vasketsov (18x), GunSmoker (2x)
Total Views 3930
Last View 19-04-2024 14:52

- Issue History
Date Modified Username Field Change
31-07-2015 14:09 zed New Issue
31-07-2015 14:14 zed Tag Attached: gpx
31-07-2015 14:14 zed Tag Attached: import
31-07-2015 14:14 zed Tag Attached: импорт
31-07-2015 14:14 zed Tag Attached: пути
31-07-2015 14:14 zed Tag Attached: путь
31-07-2015 14:14 zed Tag Attached: трек
31-07-2015 14:14 zed Tag Attached: треки
03-08-2015 08:53 vdemidov Note Added: 0016264
03-08-2015 08:53 vdemidov Status new => confirmed
03-08-2015 08:53 vdemidov Target Version => 150915
03-08-2015 08:55 zed Note Added: 0016265
03-08-2015 08:59 vdemidov Note Added: 0016266
03-08-2015 12:49 zed Note Added: 0016268
03-08-2015 13:30 vdemidov Note Added: 0016270
03-08-2015 16:11 zed Note Added: 0016277
03-08-2015 16:18 vdemidov Note Added: 0016278
03-08-2015 21:39 vasketsov Note Added: 0016291
04-08-2015 06:05 vdemidov Note Added: 0016299
04-08-2015 06:51 zed Note Added: 0016303
04-08-2015 07:05 zed Note Added: 0016304
04-08-2015 10:15 vasketsov Note Added: 0016306
04-08-2015 10:38 zed Note Added: 0016309
04-08-2015 11:31 vasketsov Note Added: 0016313
04-08-2015 11:35 vdemidov Note Added: 0016314
04-08-2015 11:37 zed Note Added: 0016315
04-08-2015 12:22 vasketsov Note Added: 0016327
04-08-2015 12:55 vdemidov Note Added: 0016334
04-08-2015 13:08 vasketsov Note Added: 0016338
04-08-2015 13:10 vasketsov Note Edited: 0016338 View Revisions
04-08-2015 13:25 vdemidov Note Added: 0016341
04-08-2015 13:25 vdemidov Note Added: 0016342
04-08-2015 13:32 vasketsov Note Added: 0016344
05-08-2015 08:37 vdemidov Note Added: 0016353
12-08-2015 18:23 vdemidov Issue cloned: 0002786
12-08-2015 18:23 vdemidov Relationship added related to 0002786
16-09-2015 14:52 vdemidov Target Version 150915 => 151010
04-10-2015 15:24 vdemidov Summary Невалидный путь при импорте gpx трека из одной точки => Путь из одной точки не отображается ни на одном зуме
04-10-2015 15:24 vdemidov Description Updated View Revisions
04-10-2015 15:28 vdemidov Target Version 151010 => 151111
06-11-2015 08:23 vdemidov Target Version 151111 => 191221
23-07-2019 17:04 vdemidov Target Version 191221 => 211230
30-12-2021 08:59 zed Target Version 211230 => 26xxxx

My View | View Issues | Change Log | Roadmap | Search
  

Copyright © 2007 - 2024 SAS.Planet Team