SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002503SAS.Планета[All Projects] Хотелкаpublic22-09-2014 16:4707-07-2022 08:48
ReporterVitas 
Assigned Tozed 
PrioritynormalSeveritytweakReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version140303 
Target Version220707Fixed in Version220707 
Summary0002503: Сохранение высоты и времени меток при импорте GPX трека
DescriptionСохранять не только координаты, но и время для каждой точки трека (при наличии). При импорте трека, содержащего временнЫе отметки, эта информация не должна теряться. Соответственно при экспорте трека, содержащего данные о вермени, эта информация тоже должна экспортироваться.

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

Старался найти освещение данного вопроса в планах, в уже существующих инцидентах, но почему-то (к большому удивлению!) обнаружились лишь темы на форуме (двухлетней давности), подтверждающие, что хранятся только координаты, без времени.
Tagsgpx, VIP
Attached Files

- Relationships
parent of 0003810resolvedzed Добавить поддержку gpx метаинформации в IDoublePoint и IDoublePointAggregator 
parent of 0003811resolvedzed Добавить поддержку gpx метаинформации в IEnumDoublePoint 
parent of 0003813resolvedzed Добавить поддержку метаданных геометрии в SML БД меток 
parent of 0003814resolvedzed Добавить поддержку метаданных геометрии в ORM БД меток 
has duplicate 0002001closedvdemidov Сохранение данных о скорости в метках треков GPS 
has duplicate 0003542closedvdemidov Полноценная поддержка GPX 
related to 0003812resolvedzed Добавить поддержку высоты точек трека при импорте/экспорте из kml 

-  Notes
(0014680)
vdemidov (manager)
08-10-2014 11:33

САС.Планета время не затирает, она его просто не хранит в базе меток и никак не обрабатывает. Мысли хранить в треках время и высоту точки есть, но реализовано будет оооочень нескоро.
(0019245)
aflexus (reporter)
15-08-2019 12:22

vdemidov, как можно сей процесс ускорить? И где можно посмотреть/узнать о дальнейших планах развития программы?
(0019246)
vdemidov (manager)
15-08-2019 12:39
edited on: 15-08-2019 12:49

> vdemidov, как можно сей процесс ускорить?
Взять и сделать самому. Ну, или найти кого-нибудь, кто сделает.

> И где можно посмотреть/узнать о дальнейших планах развития программы?
Ну, собственно здесь в багтрекере о планах и можно узнать. В каждой хотелке есть поле Target Version, которое указывает версию, в которой возможно будет реализована эта хотелка.
Удобно смотреть вот здесь http://www.sasgis.org/mantis/roadmap_page.php

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

(0019256)
RedRat (reporter)
19-08-2019 10:29

А есть какая-нибудь проект-документация на внутренние структуры данных? Я бы фичу с хранением меток времени сам бы реализовал, но плотный график не даёт возможности разбираться со структурами данных по коду.
(0019257)
vdemidov (manager)
19-08-2019 10:39

> А есть какая-нибудь проект-документация на внутренние структуры данных?
Нет. Будут вопросы - задавайте в соответствующем разделе форума или здесь, если относятся к этой фитче.

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

Тогда боюсь вы не справитесь. Там очень много работы, что бы обеспечить совместимость со старыми базами меток и разными экспортами-импортами меток.
(0019258)
zed (manager)
19-08-2019 10:53

Там, по сути, надо изменять схему БД. И на сколько я это представляю, достаточно добавить одно json поле для хранения всякой мета-информации (для каждой точки). Ну и, соответственно, во всех местах, где у нас идёт работа с геометрией, предусмотреть наличие у точки не только координат, но и ещё этого доп поля. Вероятно, нужно будет изменить тип TDoublePoint и добавить туда абстрактную координату Z.

В общем, задача достаточно сложная.
(0019260)
vdemidov (manager)
19-08-2019 12:36

А почему только одной координаты Z? Если уж делать, то хотя бы время, высоту, скорость и направление хранить. Что-то одно хранить как-то бессмысленно, потому что чаще всего это будет или только две координаты, или уже полноценный трек со всеми параметрами для каждой точки.
(0019261)
zed (manager)
19-08-2019 12:44

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

Главное, чтобы это не сильно повлияло на производительность программы. Точек-то в треке может быть очень много.
(0019262)
vdemidov (manager)
19-08-2019 13:02

Ааа. Тогда нормально. Хранить просто индекс в массиве дополнительных данных. Не помню насколько сейчас с БД используется формат WKB, но он предусматривает вариант хранения 3-й координаты. Правда в парсере это никак не реализовано, но теоретически будет не сложно добавить.
(0019263)
zed (manager)
19-08-2019 13:10

Точно, индекс. А в WKB можно даже 4 значения хранить:

> Coordinates for geometries may be 2D (x, y), 3D (x, y, z), 4D (x, y, z, m) with an m value that is part of a linear referencing system or 2D with an m value (x, y, m).
(0019264)
vdemidov (manager)
19-08-2019 15:15

Ну, логичным решением будет почти в таком виде добавлять в САС. То есть 2D, 3D, 4D. Вариант 2D c дополнительными данными ИМХО можно не рассматривать, так ка линию с высотами но без остальных данных я могу представить, а вото трек со скоростью или датами это уже странно.
Я за то что бы высоту выделить из дополнительных данных и не ограничиваться режимом (x, y, m), так как высота это нужная штука для корректного прехода координат между разными датумами, которая сейчас тупо игнорируется. А лучше бы таки рассматривать 3-х мерные координаты.


Но все это чисто гипотетически, так как введение линий с большим количеством координат, требует кучи копипасты всего кода для самих lonlat линий, кода работающего с проецированием и фильтрацией геометрий, кода спроецированных линий и тд. Или дженерики использовать. В любом случае дофига изменений в самых чуствительных местах программы.
(0019265)
zed (manager)
19-08-2019 15:34

Т.е. наш текущий TDoublePoint нужно приводить в соответствие с 4D, где Z: Integer - высота, M: Integer - индекс метаданных и уже плясать от этого? В подсистеме меток добавить чтение/запись метаданных в БД и, соответственно, в импорте/экспорте gpx обращать внимание на эти поля. В остальном пока можно оставить как есть (игнорировать).
(0019266)
vdemidov (manager)
19-08-2019 15:48

>Т.е. наш текущий TDoublePoint нужно приводить в соответствие с 4D,
В том то и дело, что этого делать не хочется. Остается куча случаев, когда 2D более чем достаточно и расширение до 4D явный перебор. Перерасход памяти и процессора на инициализацию нулями и копирование. Вот и выходит, что нужно не расширять, а делать еще TDoublePoint3D и TDoublePoint4D. А все что с точками работает нужно или дженериками делать, или копипастить код.

А еще нужно будет делать новую базу меток с поддержкой этой всей кухни, а еще добавлять всякие предупреждения пользователю о потере данных, если он захочет сохранить метки с расширенными данными в sml или базу старого формата. В общем, мороки огромная куча.
(0019267)
zed (manager)
19-08-2019 15:56

Дополнительные 8 байт погоды не сделают. Мы когда с Extended на Double перешли, как раз их и сэкономили. С дженериками быстрее точно не получится, а копипаста - тупиковый путь, как по мне.

В sml метаданные можно в отдельный файл сохранять MarksMeta.sml, а ORM должна автоматически подхватить новую схему и обновить БД. Так что тут сложности есть, но их не такая уж и куча.
(0019268)
zed (manager)
19-08-2019 16:16

Сделать вот такой тип:

  TGeoPoint = packed record
    X, Y: Double;
    case Integer of
      0: (E: UInt64);
      1: (Z, M: Cardinal);
  end;

Если E (exists) = 0, то доп данных нет. Высоты хранить относительные, индекс нумеровать с 1.
(0019269)
vdemidov (manager)
19-08-2019 16:20

Не, высота в integer это очень плохая идея. Хотя бы Single
(0019270)
zed (manager)
19-08-2019 16:32
edited on: 19-08-2019 16:49

Single по-моему будет работать не очень быстро, а Integer на самом деле достаточно большой, чтобы вместить высоты/глубины не то что на Земле, но и на Марсе, с точностью до сантиметра.

Но это надо на тестах смотреть, может действительно, подойдёт и Single.

(0019271)
vdemidov (manager)
19-08-2019 18:50

> с точностью до сантиметра.
Не, плохая идея. Это будет высота в хз каких единицах. Представляешь как постороннему человеку будет разбираться что это за Z такое? Да и при любых операциях с ней, ее придется переводить в даблы или синглы с операцией деления. Проще сразу хранить с плавающей запятой. И точности там хватит за глаза.
(0019300)
aflexus (reporter)
25-08-2019 16:52

Ребят, я не все понял, о чем вы тут толкуете ;) Но если, вдруг, решитесь реализовывать - готов помочь, чем смогу. Тестировать, уж точно. :)
(0019301)
vdemidov (manager)
27-08-2019 06:28

> Ребят, я не все понял, о чем вы тут толкуете ;) Но если, вдруг, решитесь реализовывать - готов помочь, чем смогу. Тестировать, уж точно. :)
Это исключительно умозрительное обсуждение. В ближайшем будущем, очень вряд ли, что кто-то этим займется. Слишком много кода менять будет. Да еще и уменьшит скорость всего когда, работющего с векторными данными, или потребует кучу копипасты. В общем, разве что если готовы сами пару месяцев ковырятся.
(0020266)
zed (manager)
30-01-2022 13:05
edited on: 31-01-2022 07:51

Кажется придумал как можно решить задачу без дженериков и копипасты:

1) Добавить следующие типы

  TDoublePointsMeta = record
    Elevation: array of Double;
    TimeStamp: array of TDateTime;
  end;
  PDoublePointsMeta = ^TDoublePointsMeta;


2) Модифицировать IDoublePoints и обязать его хранить метаинформацию наряду с геометрией. Предусмотреть случай, что меты вообще может не быть (проверять на значение nil)

  IDoublePoints = interface
    function GetCount: Integer;
    property Count: Integer read GetCount;

    function GetPoints: PDoublePointArray;
    property Points: PDoublePointArray read GetPoints;

    function GetMeta: PDoublePointsMeta;
    property Meta: PDoublePointsMeta read GetMeta; // can be nil
  end;


3) Далее, всюду где мы работаем с геометрией (добавляем/удаляем точки) не забываем актуализировать и мету. На первый взгляд всё редактирование сосредоточено внутри IDoublePointsAggregator так что код будет хорошо локализован.

4) У IGeometryLonLatSingleLine добавить пропертю для доступа к мете, остальные геометрии можно не трогать, для них она не актуальна.

5) Для записи в БД мету сериализовать в json, можно сжать zlib-ом, и сохранить в отдельную табличку (файл, для случая с sml). Совместимость не пострадает.

(0020267)
zed (manager)
31-01-2022 07:54

Обновил предыдущий комментарий. Начал думать над сохранением меты в БД и решил, что такой вариант структуры будет куда удобнее. Плюс, автоматически получилась экономия памяти, если каких-то мета-полей в треке не будет.
(0020268)
vdemidov (manager)
31-01-2022 12:35

Вот такая структура
  TDoublePointsMeta = record
    Elevation: array of Double;
    TimeStamp: array of TDateTime;
  end;
Плоха с той точки зрения, что она не совместима по ABI ни с чем. Только с точно такой же версией делфи, что и скомпилированная программа. Я пытался все такие вещи спрятать за интерфейсами что бы можно было добаить поддержку плагинов. Но раз уж не успел и теперь вряд ли добавлю, то сам смотри - стоит ли оно того. Просто предупреждаю заранее и обосновываю, почему считаю это не очень хорошим вариантом.
(0020269)
zed (manager)
31-01-2022 12:58

А, ну да, как же я про плагины забыл.

Тогда вот так:

  TArrayOfDouble = array [0..0] of Double;
  PArrayOfDouble = ^TArrayOfDouble;

  TArrayOfDateTime = array [0..0] of TDateTime;
  PArrayOfDateTime = ^TArrayOfDateTime;

  TDoublePointsMeta = packed record
    Elevation: PArrayOfDouble;
    TimeStamp: PArrayOfDateTime;
  end;
  PDoublePointsMeta = ^TDoublePointsMeta;

Чутка добавится низкоуровневой возни с памятью...
(0020270)
vdemidov (manager)
01-02-2022 06:02

>Чутка добавится низкоуровневой возни с памятью...
Ну, хранить можно все так же в array of Double, прото наружу отдавать PArrayOfDouble и никакой отдельной возни с памятью.
(0020271)
vdemidov (manager)
01-02-2022 08:43

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

Вообще идея вынести это в отдельную структуру зачетная.

Самая большая сложность будет при работе со спроецированными данными находить соответствие между спроецированными точками и исходными. Сейчас спроецированных точек может быть меньше исходных (если точки очень блихко), а в идеале спроецированные точки могут появляться на длинных отрезках (что бы прямые отображались дугами). И это крайне желательно прямо сейчас продумывать.
(0020272)
zed (manager)
01-02-2022 09:19

Там спроецированных геометрий оно вроде касаться не должно.

По поводу интерфейса: предлагаешь хранить/передавать его отдельно от IDoublePoint?
(0020273)
vdemidov (manager)
01-02-2022 09:26

Хз. Лучше, наверное, в IDoublePoints запихать как ты сразу и собирался. Но можно и в геометрию впихнуть, просто потом морочится опять с мультилиниями придется. Смотри как тебе больше нравится.
(0020275)
Mitek (reporter)
02-02-2022 17:46
edited on: 02-02-2022 18:06

>vdemidov, как можно сей процесс ускорить?
Ускорен оплатой хотелки ))
>линию с высотами но без остальных данных я могу представить, а вот трек со скоростью или датами это уже странно.
Линию трека можно отображать плоским высотным профилем, а прочие данные, такие как время трека, средняя скорость, потеря высоты, набор высоты, мин. высота, макс. высота, и т.д. выводить в виде текстовой информации в отдельном окошке, как это реализовано в Locus. Имея полную информацию о треке, такие данные легко посчитать.

(0020277)
zed (manager)
09-02-2022 10:02

У меня тут возник вопрос: допустим, пользователь импортировал трек, а потом решил некоторую точку трека переместить руками - что при этом делать с метаинформацией этой точки? Удалить или не трогать?
(0020278)
vdemidov (manager)
09-02-2022 13:08

ИМХО пока, только оставлять возможность сохранить как новую линию без метаинформации.
(0020279)
Mitek (reporter)
09-02-2022 14:14
edited on: 09-02-2022 14:44

>ИМХО пока, только оставлять возможность сохранить как новую линию без метаинформации.
На мой взгляд не очень хорошая идея. Если трек будет редактироваться несколько раз - будет несколько копий. Запутаешься.
Думаю, что лучше оставлять метаинфу как есть.
Трек может быть создан в стороннем автопрокладчике типа Brouter и импортирован в САС для дальнейшего допиливания вручную и иметь высоты. Даты в таких треках нет.
Если в редактируемом треке есть высоты - выдавать предупреждение об изменении высот редактируемых точек. Когда будет реализовано - прописывать редактируемой точке высоту по данным strm. Пока не реализовано - 0.
Даты (при их наличии) пока предлагаю оставлять как есть для упрощения.

(0020280)
zed (manager)
09-02-2022 17:40

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

> прописывать редактируемой точке
Это будет отдельным инструментом, по отдельной кнопке и в отдельном окошке. В момент же редактирования трека или рисования линий, туда ничего дополнительного писаться не будет. По крайней мере пока.

- Users who viewed this issue
User List Anonymous (3016x), Mitek (55x), aflexus (39x), vdemidov (57x), zed (45x), ingener (6x), Tolik (8x), RedRat (8x), omen98 (1x), rass (2x), RiverMap (1x)
Total Views 3238
Last View 28-03-2024 21:41

- Issue History
Date Modified Username Field Change
22-09-2014 16:47 Vitas New Issue
08-10-2014 11:33 vdemidov Note Added: 0014680
10-10-2014 10:35 vdemidov Severity feature => tweak
10-10-2014 10:35 vdemidov Status new => confirmed
10-10-2014 10:35 vdemidov Product Version => 140303
10-10-2014 10:35 vdemidov Target Version => 40xxxx
24-10-2014 13:33 vdemidov Relationship added has duplicate 0002001
15-08-2019 12:04 vdemidov Relationship added has duplicate 0003542
15-08-2019 12:22 aflexus Note Added: 0019245
15-08-2019 12:39 vdemidov Note Added: 0019246
15-08-2019 12:49 vdemidov Note Edited: 0019246 View Revisions
19-08-2019 10:29 RedRat Note Added: 0019256
19-08-2019 10:39 vdemidov Note Added: 0019257
19-08-2019 10:53 zed Note Added: 0019258
19-08-2019 12:36 vdemidov Note Added: 0019260
19-08-2019 12:44 zed Note Added: 0019261
19-08-2019 13:02 vdemidov Note Added: 0019262
19-08-2019 13:10 zed Note Added: 0019263
19-08-2019 15:15 vdemidov Note Added: 0019264
19-08-2019 15:34 zed Note Added: 0019265
19-08-2019 15:48 vdemidov Note Added: 0019266
19-08-2019 15:56 zed Note Added: 0019267
19-08-2019 16:16 zed Note Added: 0019268
19-08-2019 16:20 vdemidov Note Added: 0019269
19-08-2019 16:32 zed Note Added: 0019270
19-08-2019 16:49 zed Note Edited: 0019270 View Revisions
19-08-2019 18:50 vdemidov Note Added: 0019271
25-08-2019 16:52 aflexus Note Added: 0019300
27-08-2019 06:28 vdemidov Note Added: 0019301
30-01-2022 13:05 zed Note Added: 0020266
30-01-2022 13:16 zed Tag Attached: gpx
30-01-2022 13:16 zed Tag Attached: VIP
30-01-2022 13:17 zed Target Version 40xxxx => 24xxxx
30-01-2022 13:17 zed Summary Сохранение временнЫх меток в треке => Сохранение высоты и времени меток при импорте GPX трека
31-01-2022 07:51 zed Note Edited: 0020266 View Revisions
31-01-2022 07:54 zed Note Added: 0020267
31-01-2022 12:35 vdemidov Note Added: 0020268
31-01-2022 12:58 zed Note Added: 0020269
01-02-2022 06:02 vdemidov Note Added: 0020270
01-02-2022 08:43 vdemidov Note Added: 0020271
01-02-2022 09:19 zed Note Added: 0020272
01-02-2022 09:26 vdemidov Note Added: 0020273
01-02-2022 19:04 zed Relationship added parent of 0003810
01-02-2022 19:06 zed Assigned To => zed
01-02-2022 19:06 zed Status confirmed => assigned
01-02-2022 19:20 zed Relationship added parent of 0003811
02-02-2022 17:46 Mitek Note Added: 0020275
02-02-2022 17:48 Mitek Note Edited: 0020275 View Revisions
02-02-2022 18:06 Mitek Note Edited: 0020275 View Revisions
04-02-2022 12:04 zed Relationship added related to 0003812
05-02-2022 12:05 zed Relationship added parent of 0003813
09-02-2022 10:02 zed Note Added: 0020277
09-02-2022 13:08 vdemidov Note Added: 0020278
09-02-2022 14:14 Mitek Note Added: 0020279
09-02-2022 14:44 Mitek Note Edited: 0020279 View Revisions
09-02-2022 17:40 zed Note Added: 0020280
13-02-2022 08:10 zed Relationship added parent of 0003814
13-02-2022 11:25 zed Note Added: 0020283
15-02-2022 11:41 zed Status assigned => resolved
15-02-2022 11:41 zed Fixed in Version => 24xxxx
15-02-2022 11:41 zed Resolution open => fixed
15-02-2022 11:41 zed Note Deleted: 0020283
07-07-2022 08:47 zed Target Version 24xxxx => 220707
07-07-2022 08:48 zed Fixed in Version 24xxxx => 220707



Copyright © 2007 - 2024 SAS.Planet Team