Anonymous | Login | Signup for a new account | 21-11-24 10:01 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002503 | SAS.Планета | [All Projects] Хотелка | public | 22-09-2014 16:47 | 08-08-2024 07:33 | ||||
Reporter | Vitas | ||||||||
Assigned To | zed | ||||||||
Priority | normal | Severity | tweak | Reproducibility | N/A | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 140303 | ||||||||
Target Version | 220707 | Fixed in Version | 220707 | ||||||
Summary | 0002503: Сохранение высоты и времени меток при импорте GPX трека | ||||||||
Description | Сохранять не только координаты, но и время для каждой точки трека (при наличии). При импорте трека, содержащего временнЫе отметки, эта информация не должна теряться. Соответственно при экспорте трека, содержащего данные о вермени, эта информация тоже должна экспортироваться. SASPlanet очень удобно использовать как библиотеку треков, но при этом она не должна "затирать" такое важное свойство трека, как время. В данный момент время никак не обрабатывается, но пусть оно хотя бы не пропадает. Старался найти освещение данного вопроса в планах, в уже существующих инцидентах, но почему-то (к большому удивлению!) обнаружились лишь темы на форуме (двухлетней давности), подтверждающие, что хранятся только координаты, без времени. | ||||||||
Tags | gpx, VIP | ||||||||
Attached Files | |||||||||
Relationships | |||||||||||||||||||||||||||||||||||||||||
|
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 |
Сделать вот такой тип:
Если 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) Добавить следующие типы
2) Модифицировать IDoublePoints и обязать его хранить метаинформацию наряду с геометрией. Предусмотреть случай, что меты вообще может не быть (проверять на значение nil)
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 |
А, ну да, как же я про плагины забыл. Тогда вот так:
Чутка добавится низкоуровневой возни с памятью... |
(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 (3867x), samsomus (4x), Mitek (55x), aflexus (39x), vdemidov (57x), zed (45x), ingener (6x), Tolik (8x), RedRat (8x), omen98 (1x), rass (2x), RiverMap (1x) |
Total Views | 4093 |
Last View | 21-11-2024 10:01 |
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 |
08-08-2024 07:33 | zed | Relationship added | related to 0000755 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |