|
Notes |
|
|
|
|
САС.Планета время не затирает, она его просто не хранит в базе меток и никак не обрабатывает. Мысли хранить в треках время и высоту точки есть, но реализовано будет оооочень нескоро. |
|
|
|
|
|
vdemidov, как можно сей процесс ускорить? И где можно посмотреть/узнать о дальнейших планах развития программы? |
|
|
|
(0019246)
|
|
vdemidov
|
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
|
|
19-08-2019 10:29
|
|
|
А есть какая-нибудь проект-документация на внутренние структуры данных? Я бы фичу с хранением меток времени сам бы реализовал, но плотный график не даёт возможности разбираться со структурами данных по коду. |
|
|
|
|
> А есть какая-нибудь проект-документация на внутренние структуры данных?
Нет. Будут вопросы - задавайте в соответствующем разделе форума или здесь, если относятся к этой фитче.
>Я бы фичу с хранением меток времени сам бы реализовал, но плотный график не даёт возможности разбираться со структурами данных по коду.
Тогда боюсь вы не справитесь. Там очень много работы, что бы обеспечить совместимость со старыми базами меток и разными экспортами-импортами меток. |
|
|
|
(0019258)
|
|
zed
|
|
19-08-2019 10:53
|
|
Там, по сути, надо изменять схему БД. И на сколько я это представляю, достаточно добавить одно json поле для хранения всякой мета-информации (для каждой точки). Ну и, соответственно, во всех местах, где у нас идёт работа с геометрией, предусмотреть наличие у точки не только координат, но и ещё этого доп поля. Вероятно, нужно будет изменить тип TDoublePoint и добавить туда абстрактную координату Z.
В общем, задача достаточно сложная. |
|
|
|
|
|
А почему только одной координаты Z? Если уж делать, то хотя бы время, высоту, скорость и направление хранить. Что-то одно хранить как-то бессмысленно, потому что чаще всего это будет или только две координаты, или уже полноценный трек со всеми параметрами для каждой точки. |
|
|
|
(0019261)
|
|
zed
|
|
19-08-2019 12:44
|
|
Под "абстрактной координатой" я подразумевал некий интерфейс/указатель/строку за которым можно спрятать неограниченное число неких параметров, а не просто одно значение.
Главное, чтобы это не сильно повлияло на производительность программы. Точек-то в треке может быть очень много. |
|
|
|
|
|
Ааа. Тогда нормально. Хранить просто индекс в массиве дополнительных данных. Не помню насколько сейчас с БД используется формат WKB, но он предусматривает вариант хранения 3-й координаты. Правда в парсере это никак не реализовано, но теоретически будет не сложно добавить. |
|
|
|
(0019263)
|
|
zed
|
|
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). |
|
|
|
|
Ну, логичным решением будет почти в таком виде добавлять в САС. То есть 2D, 3D, 4D. Вариант 2D c дополнительными данными ИМХО можно не рассматривать, так ка линию с высотами но без остальных данных я могу представить, а вото трек со скоростью или датами это уже странно.
Я за то что бы высоту выделить из дополнительных данных и не ограничиваться режимом (x, y, m), так как высота это нужная штука для корректного прехода координат между разными датумами, которая сейчас тупо игнорируется. А лучше бы таки рассматривать 3-х мерные координаты.
Но все это чисто гипотетически, так как введение линий с большим количеством координат, требует кучи копипасты всего кода для самих lonlat линий, кода работающего с проецированием и фильтрацией геометрий, кода спроецированных линий и тд. Или дженерики использовать. В любом случае дофига изменений в самых чуствительных местах программы. |
|
|
|
(0019265)
|
|
zed
|
|
19-08-2019 15:34
|
|
|
Т.е. наш текущий TDoublePoint нужно приводить в соответствие с 4D, где Z: Integer - высота, M: Integer - индекс метаданных и уже плясать от этого? В подсистеме меток добавить чтение/запись метаданных в БД и, соответственно, в импорте/экспорте gpx обращать внимание на эти поля. В остальном пока можно оставить как есть (игнорировать). |
|
|
|
|
>Т.е. наш текущий TDoublePoint нужно приводить в соответствие с 4D,
В том то и дело, что этого делать не хочется. Остается куча случаев, когда 2D более чем достаточно и расширение до 4D явный перебор. Перерасход памяти и процессора на инициализацию нулями и копирование. Вот и выходит, что нужно не расширять, а делать еще TDoublePoint3D и TDoublePoint4D. А все что с точками работает нужно или дженериками делать, или копипастить код.
А еще нужно будет делать новую базу меток с поддержкой этой всей кухни, а еще добавлять всякие предупреждения пользователю о потере данных, если он захочет сохранить метки с расширенными данными в sml или базу старого формата. В общем, мороки огромная куча. |
|
|
|
(0019267)
|
|
zed
|
|
19-08-2019 15:56
|
|
Дополнительные 8 байт погоды не сделают. Мы когда с Extended на Double перешли, как раз их и сэкономили. С дженериками быстрее точно не получится, а копипаста - тупиковый путь, как по мне.
В sml метаданные можно в отдельный файл сохранять MarksMeta.sml, а ORM должна автоматически подхватить новую схему и обновить БД. Так что тут сложности есть, но их не такая уж и куча. |
|
|
|
(0019268)
|
|
zed
|
|
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. |
|
|
|
|
|
Не, высота в integer это очень плохая идея. Хотя бы Single |
|
|
|
(0019270)
|
|
zed
|
19-08-2019 16:32
(edited on: 19-08-2019 16:49) |
|
Single по-моему будет работать не очень быстро, а Integer на самом деле достаточно большой, чтобы вместить высоты/глубины не то что на Земле, но и на Марсе, с точностью до сантиметра.
Но это надо на тестах смотреть, может действительно, подойдёт и Single.
|
|
|
|
|
> с точностью до сантиметра.
Не, плохая идея. Это будет высота в хз каких единицах. Представляешь как постороннему человеку будет разбираться что это за Z такое? Да и при любых операциях с ней, ее придется переводить в даблы или синглы с операцией деления. Проще сразу хранить с плавающей запятой. И точности там хватит за глаза. |
|
|
|
|
|
Ребят, я не все понял, о чем вы тут толкуете ;) Но если, вдруг, решитесь реализовывать - готов помочь, чем смогу. Тестировать, уж точно. :) |
|
|
|
|
> Ребят, я не все понял, о чем вы тут толкуете ;) Но если, вдруг, решитесь реализовывать - готов помочь, чем смогу. Тестировать, уж точно. :)
Это исключительно умозрительное обсуждение. В ближайшем будущем, очень вряд ли, что кто-то этим займется. Слишком много кода менять будет. Да еще и уменьшит скорость всего когда, работющего с векторными данными, или потребует кучу копипасты. В общем, разве что если готовы сами пару месяцев ковырятся. |
|
|
|
(0020266)
|
|
zed
|
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
|
|
31-01-2022 07:54
|
|
|
Обновил предыдущий комментарий. Начал думать над сохранением меты в БД и решил, что такой вариант структуры будет куда удобнее. Плюс, автоматически получилась экономия памяти, если каких-то мета-полей в треке не будет. |
|
|
|
|
Вот такая структура
TDoublePointsMeta = record
Elevation: array of Double;
TimeStamp: array of TDateTime;
end;
Плоха с той точки зрения, что она не совместима по ABI ни с чем. Только с точно такой же версией делфи, что и скомпилированная программа. Я пытался все такие вещи спрятать за интерфейсами что бы можно было добаить поддержку плагинов. Но раз уж не успел и теперь вряд ли добавлю, то сам смотри - стоит ли оно того. Просто предупреждаю заранее и обосновываю, почему считаю это не очень хорошим вариантом. |
|
|
|
(0020269)
|
|
zed
|
|
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;
Чутка добавится низкоуровневой возни с памятью... |
|
|
|
|
>Чутка добавится низкоуровневой возни с памятью...
Ну, хранить можно все так же в array of Double, прото наружу отдавать PArrayOfDouble и никакой отдельной возни с памятью. |
|
|
|
|
Я бы все-таки посоветовал сделать TDoublePointsMeta интерфейсом. Так в случае чего можно будет добавить туда полей и даже если плагины появятся их не придется перекомпилировать. Но учитывая очень отдаленную перспективу плагинов - делай как больше нравится.
Вообще идея вынести это в отдельную структуру зачетная.
Самая большая сложность будет при работе со спроецированными данными находить соответствие между спроецированными точками и исходными. Сейчас спроецированных точек может быть меньше исходных (если точки очень блихко), а в идеале спроецированные точки могут появляться на длинных отрезках (что бы прямые отображались дугами). И это крайне желательно прямо сейчас продумывать. |
|
|
|
(0020272)
|
|
zed
|
|
01-02-2022 09:19
|
|
Там спроецированных геометрий оно вроде касаться не должно.
По поводу интерфейса: предлагаешь хранить/передавать его отдельно от IDoublePoint? |
|
|
|
|
|
Хз. Лучше, наверное, в IDoublePoints запихать как ты сразу и собирался. Но можно и в геометрию впихнуть, просто потом морочится опять с мультилиниями придется. Смотри как тебе больше нравится. |
|
|
|
(0020275)
|
|
Mitek
|
02-02-2022 17:46
(edited on: 02-02-2022 18:06) |
|
>vdemidov, как можно сей процесс ускорить?
Ускорен оплатой хотелки ))
>линию с высотами но без остальных данных я могу представить, а вот трек со скоростью или датами это уже странно.
Линию трека можно отображать плоским высотным профилем, а прочие данные, такие как время трека, средняя скорость, потеря высоты, набор высоты, мин. высота, макс. высота, и т.д. выводить в виде текстовой информации в отдельном окошке, как это реализовано в Locus. Имея полную информацию о треке, такие данные легко посчитать.
|
|
|
|
(0020277)
|
|
zed
|
|
09-02-2022 10:02
|
|
|
У меня тут возник вопрос: допустим, пользователь импортировал трек, а потом решил некоторую точку трека переместить руками - что при этом делать с метаинформацией этой точки? Удалить или не трогать? |
|
|
|
|
|
ИМХО пока, только оставлять возможность сохранить как новую линию без метаинформации. |
|
|
|
(0020279)
|
|
Mitek
|
09-02-2022 14:14
(edited on: 09-02-2022 14:44) |
|
>ИМХО пока, только оставлять возможность сохранить как новую линию без метаинформации.
На мой взгляд не очень хорошая идея. Если трек будет редактироваться несколько раз - будет несколько копий. Запутаешься.
Думаю, что лучше оставлять метаинфу как есть.
Трек может быть создан в стороннем автопрокладчике типа Brouter и импортирован в САС для дальнейшего допиливания вручную и иметь высоты. Даты в таких треках нет.
Если в редактируемом треке есть высоты - выдавать предупреждение об изменении высот редактируемых точек. Когда будет реализовано - прописывать редактируемой точке высоту по данным strm. Пока не реализовано - 0.
Даты (при их наличии) пока предлагаю оставлять как есть для упрощения.
|
|
|
|
(0020280)
|
|
zed
|
|
09-02-2022 17:40
|
|
Вопрос не о треке в целом, а только о той точке, которую пользователь руками туда-сюда тягает. Я сделал так, что вот у этой конкретной точки, вся мета будет удаляться. Весь остальной трек останется как есть. Мне кажется такое поведение логичным. С удалением или вставкой точек там вообще вопросов нет, т.к. вся существующая информация сохраняется, так что никаких дублей плодиться не будет.
> прописывать редактируемой точке
Это будет отдельным инструментом, по отдельной кнопке и в отдельном окошке. В момент же редактирования трека или рисования линий, туда ничего дополнительного писаться не будет. По крайней мере пока. |
|