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

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

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

- Relationships
has duplicate 0002001closedvdemidov Сохранение данных о скорости в метках треков GPS 
has duplicate 0003542closedvdemidov Полноценная поддержка GPX 

-  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

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

- Users who viewed this issue
User List Anonymous (1578x), aflexus (38x), RedRat (8x), vdemidov (34x), omen98 (1x), rass (2x), Tolik (7x), zed (18x), RiverMap (1x)
Total Views 1687
Last View 04-08-2020 02:35

- 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



Copyright © 2007 - 2020 SAS.Planet Team