|
Notes |
|
|
(0009654)
|
|
Tolik
|
|
22-10-2012 04:37
|
|
И я бы очень этого хотел. И цвет трека чтобы менялся в зависимости от скорости или высоты. Но в метках (которые получаются после импорта) этой информации нет :(
То есть нужен либо новый способ отображения gpx без импорта (это было бы круто!), либо переписывать меткохранилище (давно пора). |
|
|
|
|
1. А в меткохранилище разве не ссылка на GPX-трек?
2. Что мешает брать по заданным координатам точку из GPX-трека (пускай для начала с extension'сами SAS), там же есть данные <sasx:speed_kmh>99.64</sasx:speed_kmh> и <time>2012-06-27T22:15:18Z</time> |
|
|
|
(0009657)
|
|
Tolik
|
|
22-10-2012 05:20
|
|
1. Нет, только координаты точек трека и атрибуты (имя, цвет и т.п.)
2. Мешает, например, отсутствие линка на оригинальный GPX-файл. Можно, конечно, и его добавить в комменты, и поиск координат по этому файлу организовать, но это было бы очень криво. |
|
|
|
|
|
В ближайшем будущем, увы, не планируется. |
|
|
|
|
После импорта никаких ссылок на источник не остаётся. Исключения возможны только в том случае, если в самом источнике были ссылки на внешние файлы, когда они ещё могут быть скопированы. Но никак не сам трек.
>новый способ отображения gpx без импорта
Есть подозрение, что это будет самым оптимальным решением. Так как для всего множества форматов импорта, поддерживаемых сасом, нельзя придумать оптимальный фиксированный формат хранения. Либо куча пустых полей, либо нет нужной информации, либо композиция полей в BLOB или CLOB со всеми вытекающими.
Мне пока совершенно неактуально. |
|
|
|
(0009670)
|
|
zed
|
|
22-10-2012 09:37
|
|
>нельзя придумать оптимальный фиксированный формат хранения
Вообще-то, есть такой формат: Google ProtoBuffer
И если память не изменяет, к примеру, в OSM его активно используют. |
|
|
|
|
Это по сути один большой и толстый (B)CLOB.
Опять же с отсутствием кучи полей для некоторых форматов.
А кроме того - в случае если данные поступают в поле из нескольких источников, и у каждого свой диапазон enum, и это поле надо сохранять, то этот протокол не сможет обеспечить сохранение данных as is. Либо рушить enum-ы, либо размножать поля, либо выдумывать конвертацию, и заведомо создавать себе проблемы при обратном экспорте в исходный формат.
Как и в большинстве "теорий" по построению моделей данных - здесь совершенно не уделяется внимание возможной изменяемости типов, изменению (де)композиции со временем, в общем, если предметная область меняется, то максимум что доступно без попаболи - это "можно добавлять к уже созданной структуре данных новые поля не боясь утратить совместимость с предыдущей версией: при парсинге старых записей новые поля просто будут игнорироваться", так этим свойством обладают почти все нормальные форматы кроме откровенно на всю голову бинарных. А сливание данных из нескольких разнотипных источников формально и есть изменение предметной области по отношению к ситуации с одним форматом. |
|
map.gif (38,178) 22-10-2012 03:42