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

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002503SAS.ПланетаХотелка / Feature requestpublic22-09-2014 16:4708-08-2024 07:33
ReporterVitas Assigned Tozed  
PrioritynormalSeveritytweakReproducibilityN/A
Status resolvedResolutionfixed 
Product Version140303 
Target Version220707Fixed in Version220707 
Summary0002503: Сохранение высоты и времени меток при импорте GPX трека
DescriptionСохранять не только координаты, но и время для каждой точки трека (при наличии). При импорте трека, содержащего временнЫе отметки, эта информация не должна теряться. Соответственно при экспорте трека, содержащего данные о вермени, эта информация тоже должна экспортироваться.

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

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

Relationships

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

Activities

vdemidov

08-10-2014 11:33

manager   ~0014680

САС.Планета время не затирает, она его просто не хранит в базе меток и никак не обрабатывает. Мысли хранить в треках время и высоту точки есть, но реализовано будет оооочень нескоро.

aflexus

15-08-2019 12:22

reporter   ~0019245

vdemidov, как можно сей процесс ускорить? И где можно посмотреть/узнать о дальнейших планах развития программы?

vdemidov

15-08-2019 12:39

manager   ~0019246

Last edited: 15-08-2019 12:49

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

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

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

RedRat

19-08-2019 10:29

reporter   ~0019256

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

vdemidov

19-08-2019 10:39

manager   ~0019257

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

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

Тогда боюсь вы не справитесь. Там очень много работы, что бы обеспечить совместимость со старыми базами меток и разными экспортами-импортами меток.

zed

19-08-2019 10:53

manager   ~0019258

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

В общем, задача достаточно сложная.

vdemidov

19-08-2019 12:36

manager   ~0019260

А почему только одной координаты Z? Если уж делать, то хотя бы время, высоту, скорость и направление хранить. Что-то одно хранить как-то бессмысленно, потому что чаще всего это будет или только две координаты, или уже полноценный трек со всеми параметрами для каждой точки.

zed

19-08-2019 12:44

manager   ~0019261

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

Главное, чтобы это не сильно повлияло на производительность программы. Точек-то в треке может быть очень много.

vdemidov

19-08-2019 13:02

manager   ~0019262

Ааа. Тогда нормально. Хранить просто индекс в массиве дополнительных данных. Не помню насколько сейчас с БД используется формат WKB, но он предусматривает вариант хранения 3-й координаты. Правда в парсере это никак не реализовано, но теоретически будет не сложно добавить.

zed

19-08-2019 13:10

manager   ~0019263

Точно, индекс. А в 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).

vdemidov

19-08-2019 15:15

manager   ~0019264

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


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

zed

19-08-2019 15:34

manager   ~0019265

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

vdemidov

19-08-2019 15:48

manager   ~0019266

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

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

zed

19-08-2019 15:56

manager   ~0019267

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

В sml метаданные можно в отдельный файл сохранять MarksMeta.sml, а ORM должна автоматически подхватить новую схему и обновить БД. Так что тут сложности есть, но их не такая уж и куча.

zed

19-08-2019 16:16

manager   ~0019268

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

  TGeoPoint = packed record
    X, Y: Double;
    case Integer of
      0: (E: UInt64);
      1: (Z, M: Cardinal);
  end;
Если E (exists) = 0, то доп данных нет. Высоты хранить относительные, индекс нумеровать с 1.

vdemidov

19-08-2019 16:20

manager   ~0019269

Не, высота в integer это очень плохая идея. Хотя бы Single

zed

19-08-2019 16:32

manager   ~0019270

Last edited: 19-08-2019 16:49

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

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

vdemidov

19-08-2019 18:50

manager   ~0019271

> с точностью до сантиметра.
Не, плохая идея. Это будет высота в хз каких единицах. Представляешь как постороннему человеку будет разбираться что это за Z такое? Да и при любых операциях с ней, ее придется переводить в даблы или синглы с операцией деления. Проще сразу хранить с плавающей запятой. И точности там хватит за глаза.

aflexus

25-08-2019 16:52

reporter   ~0019300

Ребят, я не все понял, о чем вы тут толкуете ;) Но если, вдруг, решитесь реализовывать - готов помочь, чем смогу. Тестировать, уж точно. :)

vdemidov

27-08-2019 06:28

manager   ~0019301

> Ребят, я не все понял, о чем вы тут толкуете ;) Но если, вдруг, решитесь реализовывать - готов помочь, чем смогу. Тестировать, уж точно. :)
Это исключительно умозрительное обсуждение. В ближайшем будущем, очень вряд ли, что кто-то этим займется. Слишком много кода менять будет. Да еще и уменьшит скорость всего когда, работющего с векторными данными, или потребует кучу копипасты. В общем, разве что если готовы сами пару месяцев ковырятся.

zed

30-01-2022 13:05

manager   ~0020266

Last edited: 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). Совместимость не пострадает.

zed

31-01-2022 07:54

manager   ~0020267

Обновил предыдущий комментарий. Начал думать над сохранением меты в БД и решил, что такой вариант структуры будет куда удобнее. Плюс, автоматически получилась экономия памяти, если каких-то мета-полей в треке не будет.

vdemidov

31-01-2022 12:35

manager   ~0020268

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

zed

31-01-2022 12:58

manager   ~0020269

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

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

  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;
Чутка добавится низкоуровневой возни с памятью...

vdemidov

01-02-2022 06:02

manager   ~0020270

>Чутка добавится низкоуровневой возни с памятью...
Ну, хранить можно все так же в array of Double, прото наружу отдавать PArrayOfDouble и никакой отдельной возни с памятью.

vdemidov

01-02-2022 08:43

manager   ~0020271

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

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

Самая большая сложность будет при работе со спроецированными данными находить соответствие между спроецированными точками и исходными. Сейчас спроецированных точек может быть меньше исходных (если точки очень блихко), а в идеале спроецированные точки могут появляться на длинных отрезках (что бы прямые отображались дугами). И это крайне желательно прямо сейчас продумывать.

zed

01-02-2022 09:19

manager   ~0020272

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

По поводу интерфейса: предлагаешь хранить/передавать его отдельно от IDoublePoint?

vdemidov

01-02-2022 09:26

manager   ~0020273

Хз. Лучше, наверное, в IDoublePoints запихать как ты сразу и собирался. Но можно и в геометрию впихнуть, просто потом морочится опять с мультилиниями придется. Смотри как тебе больше нравится.

Mitek

02-02-2022 17:46

reporter   ~0020275

Last edited: 02-02-2022 18:06

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

zed

09-02-2022 10:02

manager   ~0020277

У меня тут возник вопрос: допустим, пользователь импортировал трек, а потом решил некоторую точку трека переместить руками - что при этом делать с метаинформацией этой точки? Удалить или не трогать?

vdemidov

09-02-2022 13:08

manager   ~0020278

ИМХО пока, только оставлять возможность сохранить как новую линию без метаинформации.

Mitek

09-02-2022 14:14

reporter   ~0020279

Last edited: 09-02-2022 14:44

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

zed

09-02-2022 17:40

manager   ~0020280

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

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

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 => 45xxxx
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
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
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 45xxxx => 41xxxx
30-01-2022 13:17 zed Summary Сохранение временнЫх меток в треке => Сохранение высоты и времени меток при импорте GPX трека
31-01-2022 07:51 zed Note Edited: 0020266
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
02-02-2022 18:06 Mitek Note Edited: 0020275
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
09-02-2022 17:40 zed Note Added: 0020280
13-02-2022 08:10 zed Relationship added parent of 0003814
15-02-2022 11:41 zed Status assigned => resolved
15-02-2022 11:41 zed Fixed in Version => 41xxxx
15-02-2022 11:41 zed Resolution open => fixed
07-07-2022 08:47 zed Target Version 41xxxx => 220707
07-07-2022 08:48 zed Fixed in Version 41xxxx => 220707
08-08-2024 07:33 zed Relationship added related to 0000755
08-08-2025 13:24 zed Category Хотелка => Хотелка / Feature request