|
Notes |
|
|
|
|
Если никто не против, я хотел бы это в свободное время поковырять - может и удастся сделать. |
|
|
|
(0016197)
|
|
zed
|
|
21-07-2015 06:22
|
|
|
Пробуй конечно, и спрашивать нечего. Все будут только ЗА. |
|
|
|
|
Разумеется, хуже не будет.
От меня будет подсказка.
При импорте GPX в SACS реализована привязка картинок к точкам в соответствии со значением тэгов GPX. Это лежит в TMarkPictureListSimple.FindImportPicture и реализация в TMarkPictureListSimple.FindImportPictureInternal в файле Src\MarksDB\u_MarkPictureListSimple. Алгоритм - нахождение в именах картинок значения тэга, а если нет - кусков значения тэга.
Имеет смысл сделать обратную штуку, так как разных sym немного, то есть, по имени картинки (например, BigBlueFlag.jpg) определять символ для POI и пихать его в экспорт. Для реализации этого в SAS ничего не надо дополнительно доделывать (в отличие от импорта). |
|
|
|
|
|
А можно скинуть примеры таких GPX файлов с картинками? Я, видимо, не совсем понимаю, о чём тут речь. Ибо меня в основном интересует экспорт нарисованного трека для заливки в фитнес-трекер. |
|
|
|
(0016230)
|
|
vasketsov
|
27-07-2015 08:06
(edited on: 27-07-2015 08:08) |
|
>скинуть примеры таких GPX файлов с картинками?
Откуда мне их взять-то?
Да и не зачем, Вы сами можете их сделать, достаточно поставить в гармине точку (в приборе), там будет возможность указать для неё картинку - вот именно об этих картинках и речь.
А вообще вот примерчики нашлись по GPX sym blue flag:
http://cycleseven.org/gps-waypoints-routes-and-tracks-the-difference
На всякий случай ссылка на описание формата:
http://www.topografix.com/gpx/1/1/
Хотя, я не знаю, где найти перечень возможных значений тэга sym.
А хуже всего, что может быть, что разные устройства поддерживают разный набор этих значений (скорее всего, новые поддерживают более расширенный). Наверное имеет смысл как-то обособить это в коде и потом сделать возможность получения перечня возможных значений из внешнего файла.
|
|
|
|
|
>Если никто не против, я хотел бы это в свободное время поковырять - может и удастся сделать.
Я тут вчера заглянул в спецификацию GPX и вспомнил почему я все время откладывал реализацию этого экспорта. В GPX определены точки и мульти-линии, но не полигоны (тем более мультиполигоны с дырками). Поэтому при экспорте нужно или вообще не экспортировать полигонов, о чем заранее предупреждать пользователя, или экспортировать как простые линии, после чего быть готовым отвечать на кучу вопросов типа "А почему я экспортировал полигон в GPX, а после импорта назад в САС он стал просто линией?"
Мне больше нравится первый подход, тем более что есть еще форматы поддерживающие только точки (WPT), только треки (GPX), только полигоны (нами же изобретенный hlg) и тд. Но ты как хочешь, любая реализация будет лучше вообще отсутствующей. |
|
|
|
(0016262)
|
|
zed
|
|
03-08-2015 08:34
|
|
>В GPX определены точки и мульти-линии, но не полигоны
Вполне логично, ведь это GPS eXchange Format и очевидно, что при экспорте нужно игнорировать полигоны. Не надо их ни во что конвертировать. |
|
|
|
|
Я ж написал, что мне такой вариант больше нравится, но без предупреждения пользователя это будет очень неожиданное поведение.
Имхо каждый экспорт должен определять какие типы меток он поддерживает, а подсистема экспорта должна анализировать выбранные пользователем метки и выдавать соответствующее предупреждение.
А то странно будет выглядеть когда пользователь выбрал полигон, нажал экспорт, выбрал формат GPX и получил пустой файл. |
|
|
|
|
Я сделал экспорт точек, линий и мульти-линий, полигоны игнорирую. Пока добавлю варнинг тогда.
Точки экспортируются в waypoint-ы, мульти-линии - в треки с сегментами, а линии: если точек мало (<= 500) - то в route, если много (> 500) - то в track с одним сегментом.
Пока хочу ещё потестировать и дать человеку с Garmin-ом. |
|
|
|
(0016269)
|
|
Garl
|
|
03-08-2015 13:29
|
|
|
у меня есть Гармин, готов заценить. |
|
|
|
(0016275)
|
|
zed
|
|
03-08-2015 14:47
|
|
GunSmoker
По-моему, было бы достаточно проверить работу на GoogleEarth или ещё какой-нибудь программе и засылать пулл-реквест. А уже потом, всем миром, можно было бы искать баги.
Тем более, вот я сегодня поковырял немного экспорт и тебе придётся мерджить свой код с учётом этих исправлений. И кто знает, какие ещё внезапные изменения в основной ветке, могут сломать твой практически рабочий код. Поэтому, реквесты лучше не откладывать в долгий ящик. |
|
|
|
|
>если точек мало (<= 500) - то в route
Почему в rte? |
|
|
|
|
> Почему в rte?
В смысле? А почему нет? rte/route - это логично для экспорта пути, который мы натыкали мышкой по карте, разве нет?
trk/track - это всё же "фитнес", запись с датчиков. В SAS такое может появиться без импорта такого трека? Мы же не можем нарисовать зиллион точек на карте? Кроме того, trk без метки времени у каждой точки не воспринимается, например, Google Earth и Strava. |
|
|
|
|
|
|
|
|
|
https://bitbucket.org/sas_team/sas.planet.src/pull-requests/352/2781-1076/diff |
|
|
|
|
|
Что делать с всевозможными type и sym - непонятно, т.к. любой софт туда может писать произвольные данные. Делать несколько вариантов экспорта? Типа, "Garmin GPX", "ещё-кто-то GPX"? |
|
|
|
|
>Что делать с всевозможными type и sym - непонятно, т.к. любой софт туда может писать произвольные данные.
Так может просто писать свои названия картинок? А при импорте пытаться их читать. |
|
|
|
(0016305)
|
|
zed
|
|
04-08-2015 07:49
|
|
А вот и засада с rte: текущий парсер gpx их похоже не воспринимает и в SAS эти треки не залетают. Хотя в GoogleEarth они отображаются.
Вот тут http://www.gpslib.ru/tracks/info/9043 отличный трек для тестов. Если импортировать этот трек в SAS, то получается 159 путей, а если потом его экспортировать в gpx и вновь импортировать, уже остаётся всего 57 путей. Остальное - роуты и их нету.
GunSmoker
Похоже, тебе ещё и парсер gpx придётся для SAS (до)писать ;) |
|
|
|
|
>любой софт туда может писать произвольные данные
Данные там должны соответствовать прибору.
>ещё-кто-то GPX
Разные приборы могут иметь разный набор картинок.
Возможно, его получится вытащить в виде списка, но не уверен.
А пока даже проверить некогда.
>просто писать свои названия картинок?
Если будет некий алгоритм типа:
а) попытаться найти правильное имя картинки по полному;
б) если не вышло, то записать полное
и если это будет соответствовать формату gpx (в смысле значения тега)
и приборы не будут крэшиться при загрузке таких треков
- то почему бы и нет.
>засада с rte
Потому что rte - это роутиниг.
Это вообще не надо.
Я поэтому и спросил, на кой rte вообще.
Юзай trk.
>парсер gpx придётся для SAS (до)писать
Там лишь надо включить rte, чтобы оно заработало. Там же, где включается wpt. |
|
|
|
|
>Что такое SACS?
https://bitbucket.org/vasketsov/vsasas |
|
|
|
|
> Так может просто писать свои названия картинок? А при импорте пытаться их читать.
Можно просто добавить своё расширение GPX, записывать "1.png" в него. При импорте, соответственно, учитывать.
> и если это будет соответствовать формату gpx (в смысле значения тега)
и приборы не будут крэшиться при загрузке таких треков
Скорее всего, лучше писать дефолтное значение.
> А вот и засада с rte: текущий парсер gpx их похоже не воспринимает и в SAS эти треки не залетают.
То, что там при импорте косяки - вопрос другой.
> Потому что rte - это роутиниг.
> Это вообще не надо.
Почему?
У меня use-case такой: я в SAS рисую ручкой путь на карте, тыкая мышкой, потом экспортирую это в GPX, импортирую в фитнес-трекер и использую для навигации на смарте.
Соответственно, для этого use-case больше всего подходит rte.
Чего-то подумалось, что проще было сделать экспорт в TCX, благо он более стандартизирован. |
|
|
|
|
> Если импортировать этот трек в SAS, то получается 159 путей, а если потом его экспортировать в gpx и вновь импортировать, уже остаётся всего 57 путей. Остальное - роуты и их нету.
trkpt требует как минимум наличия времени прохождения точки. Большинство пишут так же ele (высоту). Оба этих параметра теряются при импорте. Метки не хранят эту информацию. Соответственно, просто так трек по линии создать невозможно. Я обошёл это введением "фальшивой скорости движения". Т.е. как бы мы двигались примерно 5 км/ч по треку - вот по этому расставляется фальшивое время прохождения трека.
А rte - это тупо маршрут. Никаких танцев с бубном там не надо.
Опять же, вопрос импорта rte - это другой вопрос. |
|
|
|
|
> Что такое SACS?
> https://bitbucket.org/vasketsov/vsasas
Т.е. это частная сборка? А с SAS.Планетой она как соотносится? В смысле, копируются ли из SACS в SAS какие-то возможности или наоборот? |
|
|
|
|
|
Это форк, который живет отдельной жизнью. Кое что из SACS я выдергиваю в основную репу. |
|
|
|
(0016319)
|
|
zed
|
|
04-08-2015 11:50
|
|
>Метки не хранят эту информацию.
Немного оффтопа: может есть дельное предложение, как эту ситуацию исправить? Я сейчас ковыряю новую БД для меток (SQLite2/MongoDB/СУБД) и могу, например, добавить текстовое поле в схему, куда можно будет писать json со всякой доп. инфой. Поиск по этой инфе, конечно, не заработает, но по крайней мере можно будет сохранить и достать из базы всё что нужно. В общем, я открыт для новых идей (только не пишите идеи в этот тикет, чтобы не оффтопить ещё больше). |
|
|
|
|
Наоборот - только если товарищи сочтут нужным.
Из саса - всё копируется (если нельзя скопировать, то выполняется альтернативная реализация).
На момент начала работы zed над операциями над полигонами и vdemidov надо дырками всё что было в сасе, в sacs есть (точнее - по ревизию 8712). Как только закончит vdemidov дырки - перенесу остальное.
О причинах создания sacs лучше в личку, нечего тут засирать тему. |
|
|
|
|
|
В формате WKB предусмотрен вариант хранения Z координаты и так называемой M координаты (это может быть например время). Но все равно требуется дофига изменений что бы это поддерживать в САС. |
|
|
|
|
Я всё же замечу, что текущий импорт GPX импортирует некоторую доп. информацию в Descr меток примерно следующим образом:
описание
cmt: коммент
number: 1
time: 2015.08.04...
Само собой, лучше бы это было отдельными свойствами в БД меток. |
|
|
|
|
>записывать "1.png" в него
Только лучше без ".png", только "1".
>лучше писать дефолтное значение
А какое дефолтное? Синий флаг?
>проще было сделать экспорт в TCX
Это что вообще? Если проще - лучше в виде отдельной темы сделать.
>rte - это тупо маршрут
Вот именно.
И когда я испортировал маршрут из навигатора, там получалось только начальная и конечная точки. То есть, аналогично можно предположить, что после импорта навигатор сам должен построить маршрут между точками, исходя из настроек, и это может быть НЕ прямая.
В сасе отсутствует такой тип данных, как маршрут, маршрут можно только построить сторонними средствами для пары точек линии, но сохранится он как обычная линия.
>требует как минимум наличия времени прохождения точки
Это обязательный атрибут?
То, что теряется при импорте - это проблемы реализации импорта.
>можно будет писать json со всякой доп. инфой
>Поиск по этой инфе, конечно, не заработает
Зачем тогда json?
>сохранить и достать из базы всё что нужно
Да и проблема-то в другом, в массиве координат нет места для высот, скоростей и времён. Или ты хочешь иметь рядом массив для времён, высот, скоростей, температур и т.п.? |
|
|
|
|
>требуется дофига изменений что бы это поддерживать в САС
+1
>отдельными свойствами в БД меток
Не поможет.
Для треков время надо хранить для каждой точки.
Без серьёзного изменения структур и логики хранения есть только один вариант - заюзать неиспользуемые биты в качестве короткого INTа для ссылки на другой массив, где и будут времена, скорости и т.п. Вот такой вот костыль. |
|
|
|
(0016325)
|
|
zed
|
|
04-08-2015 12:13
|
|
>Да и проблема-то в другом, в массиве координат
Я понял, просто не к месту решил вспомнить, что БД меток это не нечто неизменное, а готовая ко всему сущность :) Естественно, речь не об sml. |
|
|
|
|
> А какое дефолтное? Синий флаг?
Я так понимаю, какое мы выберем.
> Вот именно.
> И когда я испортировал маршрут из навигатора, там получалось только начальная и конечная точки. То есть, аналогично можно предположить, что после импорта навигатор сам должен построить маршрут между точками, исходя из настроек, и это может быть НЕ прямая.
Не, подожди. Вопрос же не в импорте, а в экспорте. Вот ты когда в SAS маршрут рисуешь - ты разве тыкаешь в Москву и сразу в Химки? Нет, наверное, ты тыкаешь по дорогам, поворотам и т.д. В итоге получается красивый путь с небольшим количеством точек, каждая из которых имеет просто координаты. Это один-к-одному ложится на определение rte. |
|
|
|
|
|
Кстати, мульти-линию в UI нарисовать вручную можно? Я вижу только точки, линии и полигоны. |
|
|
|
|
|
Может импортировать любой trk в мульти-линию (пусть и состоящую только из одной линии, если в trk один сегмент), а rte - в линию? Тогда и экспорт: линии - всегда в rte, мульти-линии - всегда в trk? |
|
|
|
(0016330)
|
|
zed
|
|
04-08-2015 12:24
|
|
>мульти-линию в UI нарисовать вручную можно
Нет. |
|
|
|
|
>разве тыкаешь в Москву и сразу в Химки?
Да. А потом выбираю в тубларке построение маршрута - и он строится. Не устраивает - отменяю изменения, меняю точки или провайдера автороутинга.
А вообще я в сасе маршруты строил всего-лишь несколько раз. Это просто неудобно (для экспорта в прибор), в навигаторе удобнее.
>один-к-одному ложится на определение rte
Я не говорю, что не может возникнуть идеи экспортировать начало и конец маршрута как rte, но я говорю о том, что вся логика экспорта и импорта в сасе исходит из того, что импортируется и экспортируется линия как есть, а не данные для построения маршрута (средствами саса или прибора соответственно).
Для работы с маршрутами сас заточен мягко говоря никак. Как подтверждение тому - отсутствующий экспорт в gpx и rte.
Как вопрос для подумать - экспортировать в rte надо всю линию, которая возможно уже сама получена как результат построения маршрута, или только её края, края сегментов, чтобы строить маршрут уже внутри прибора?
Имеет ли смысл экспортировать в rte всю линию, полученную импортом из прибора, если в линии есть "выстрелы" и прочие ошибки, или требуется процедура некоторого сглаживания, чтобы не портить маршрут и не заезжать на соседние улицы?
>мульти-линию в UI нарисовать вручную можно
Можно объединить несколько, а потом править руками.
>какое мы выберем
А смысл тогда выбирать, если всё, что залетит в прибор, будет с тем же синим флагом? Тогда уж по умолчанию пусто должно быть. |
|
|
|
|
>линии - всегда в rte, мульти-линии - всегда в trk?
Такое возможно, но в сасе нет никакой специальной логики, зависящей от числа сегментов в линии, никакой смысловой нагрузки на это не накладывается. Да и простая линия легко может стать мультилинией (при операциях).
Если уж так хочется экспорт именно в rte, то имеет смысл сделать его отдельно или как опцию для экспорта в GPX, чтобы в том числе возможно делить мультилинии по сегментам (если они были ранее собраны вместе). |
|
|
|
|
>>мульти-линию в UI нарисовать вручную можно
>Нет.
Там не хватает только кнопки вставки разрыва на тулбаре. Пока никто не просил. :) |
|
|
|
|
>Для треков время надо хранить для каждой точки.
>Без серьёзного изменения структур и логики хранения есть только один вариант - заюзать неиспользуемые биты в качестве короткого INTа для ссылки на другой массив, где и будут времена, скорости и т.п. Вот такой вот костыль.
Мне тут мысль пришла, а что если сделать отдельную сущность - Базу треков, которая будет ориентирована на хранение именно трека (позиция, время, скорость, высота, направление) и позволит только импортировать, экспортировать и удалять треки (без редактирования). Ну и само собой отображать. |
|
|
|
|
Вижу в коде
GarminSymNames: array[0..138] of String = (
этого достаточно.
Надо найти произвольный элемент в этом массиве, каждое слово которого есть в имени картинки у экспортируемой точки. Если нашлось - подставить найденное. Если нет - оставить sym пустым. В принципе, можно для точности искать самое длинное среди всех найденных, но наверное это не принципиально, в крайнем случае это решится изменением порядка элементов в массиве. |
|
|
|
|
> Да. А потом выбираю в тубларке построение маршрута - и он строится. Не устраивает - отменяю изменения, меняю точки или провайдера автороутинга.
Почему-то у меня эта функция не работает вообще, не могу проверить что при этом происходит с линией. Ошибок нет, исключений нет, просто втихую ничего не происходит.
> Я не говорю, что не может возникнуть идеи экспортировать начало и конец маршрута как rte
В rte экспортируется не только начало и конец, но и все промежуточные точки.
> Для работы с маршрутами сас заточен мягко говоря никак. Как подтверждение тому - отсутствующий экспорт в gpx и rte.
Я собственно и пилю экспорт в GPX по этой причине. Мне в SAS удобнее строить маршрут, т.к. есть большой выбор карт, по которым можно посмотреть, в какую жопу я собрался залезть.
> Можно объединить несколько, а потом править руками.
Можно пальцем ткнуть, где это? Я не вижу.
Текущее поведение мне кажется более логичным. Вот мы взяли маршрут в навигаторе - старт/стоп и одна точка посередине (стоянка), импортировали в SAS, получили одну линию из двух прямых. Хотим - оставим как есть, хотим - построим точный маршрут. В любом случае, мы экспортируем из SAS, получаем rte, копируем его в навигатор - бум, получили что-то полезное.
А если экспортировать как trk, перенесём мы потом эти три точки в виде трека в навигатор - и что мы с ними будем делать? |
|
|
|
|
> Мне тут мысль пришла, а что если сделать отдельную сущность - Базу треков, которая будет ориентирована на хранение именно трека (позиция, время, скорость, высота, направление) и позволит только импортировать, экспортировать и удалять треки (без редактирования). Ну и само собой отображать.
Звучит логично. |
|
|
|
|
> Почему-то у меня эта функция не работает вообще, не могу проверить что при этом происходит с линией. Ошибок нет, исключений нет, просто втихую ничего не происходит.
Там в последнее время была жива прокладка только с помощью yournavigation, но похоже и она умерла. |
|
|
|
|
>у меня эта функция не работает вообще
Не все провайдеры рабочие, ткнись в другого, там наверное давно порядок не наводили.
>если сделать отдельную сущность - Базу треков
>позволит только импортировать, экспортировать и удалять треки
Нет ничего проще: папка с кучкой файлов поддерживаемого формата. Просилось ещё сто лет назад. Зато универсальней некуда. Или в базе в блоб их утаптывать.
Но правда всё это никак вопросы экспорта не отменяет.
>Можно пальцем ткнуть, где это? Я не вижу
Объединение меток в одной группе. Неужели нет этого? Вроде было. В sacs это по ПКМ на метке есть. Вроде бы и в основной было. Может zed выпилил, когда операции с геометриями делал? Я не в курсе просто. В крайнем случае наверняка можно импортировать KML, где руками объединить куски в одну метку.
>перенесём мы потом эти три точки в виде трека в навигатор - и что мы с ними будем делать?
Ну, например, включать или отключать видимость на карте, сигнал о приближении к ним и т.п.
Это кстати причина того, что полигоны тоже надо экспортировать, как trk (они будут замкнутые).
Поэтому и надо выбирать, в rte или в trk гнать линии. Просто потом оно по-разному используется в приборе. |
|
|
|
(0016345)
|
|
zed
|
|
04-08-2015 13:32
|
|
> сделать отдельную сущность - Базу треков
Да ну нафиг, с отдельной сущностью. Куда лучше - придумать механизм навешивания дополнительных свойств точкам геометрии. |
|
|
|
|
> Поэтому и надо выбирать, в rte или в trk гнать линии.
Как-нибудь это указывать в свойствах линии, не? |
|
|
|
|
> Ну, например, включать или отключать видимость на карте, сигнал о приближении к ним и т.п.
А смысл в этом, если это не трек, а маршрут? Будет показано строго две прямые линии, соединяющие Москву с Химками и остановкой посередине. |
|
|
|
|
https://bitbucket.org/sas_team/sas.planet.src/pull-requests/353/pr-352/diff
Готовый exe для теста: https://www.dropbox.com/s/hbhcotv66qcyb0i/SASPlanet.zip?dl=1 - понимает преобразования значков вида 'FlagBlue.png' -> 'Flag, Blue', 'flag-blue.png' -> 'Flag, Blue', 'flag blue.png' -> 'Flag, Blue'. |
|
|
|
|
>Будет показано строго две прямые линии
Зачем прямые?
Можно же не бездумно экспортировать всякую ерунду типа отрезка на пол-области, а например острова обвести, границы леса, полян, оврагов и прочее - и в GPX в прибор, а там включать или отключать их видимость. Это получается как отдельный слой в приборе.
>Как-нибудь это указывать в свойствах линии, не?
Возможно. Поддержу любую разумную идею, вплоть до атрибутов и (куска) имени категории или самой метки.
Идея про число точек меньше 500 разумной мне не кажется. Если исходить из реального построения маршрута, то три-четыре, ну пять - это максимум для rte, плюс замкнутые делать всегда как trk. Но опять же, это сильно дискуссионно. Идеальным решением был бы некий атрибут или тип (подтип), но его нет. |
|
|
|
|
|
Разумеется, 500 точек - это временное решение, т.к. у меня хранятся и импортированные треки и вручную отрисованные маршруты. |
|
|
|
|
>> сделать отдельную сущность - Базу треков
>Да ну нафиг, с отдельной сущностью. Куда лучше - придумать механизм навешивания дополнительных свойств точкам геометрии.
Ну, не знаю. Как по мне так навешивание дополнительных свойств точкам слишком уж усложняет всю работу с метками, хотя реально такое нужно только для треков.
Тем более в программе уже есть работа с треками, хотя и в самом зачаточном состоянии (TGPSTrackPoint и тд). |
|
|
|
|
> Как по мне так навешивание дополнительных свойств точкам слишком уж усложняет всю работу с метками, хотя реально такое нужно только для треков.
Можно и для маршрутов. Угловые точки можно бы именовать ("стоянка"), писать примечания (типа "налево"). |
|
|
|
|
>Можно и для маршрутов. Угловые точки можно бы именовать ("стоянка"), писать примечания (типа "налево").
Можно, но я скорее всего заброшу весь этот проект раньше чем что-то похожее будет реализовано. А вот поддержка работы с однородными треками мне бы самому, вероятно, пригодилась бы. |
|
|
|
(0016406)
|
|
zed
|
|
26-08-2015 21:27
|
|
>Разумеется, 500 точек - это временное решение
Боюсь, как бы это временное решение не стало постоянным. И лично мне эта идея с маршрутами не нравится, потому как банальный импорт трека в SAS и экспорт его опять в gpx, выдаёт некую новую сущность, которой в треке изначально небыло. И что самое плохое, что нету конфига, чтобы можно было это поведение изменить. |
|
|
|
|
|
Ну, переделай, если считаешь, что так будет правильнее. Я не вижу значительных преимуществ у того или иного решения этой проблемы. |
|
|
|
(0016408)
|
|
zed
|
|
29-08-2015 08:10
|
|
>Ну, переделай
Что именно? Вообще удалить создание маршрутов и наплевать на мнение GunSmoker-а? Представляю себе его реакцию.
Нужно прийти к какому-то компромиссу. |
|
|
|
|
>Нужно прийти к какому-то компромиссу.
Ну, значит пусть остается как есть. Или бери и городи настройки (отдельный конфиг, который экспорту будет передаваться на старте программы и использоваться в процессе экспорта. |
|
|
|
(0016410)
|
|
zed
|
|
29-08-2015 09:23
|
|
|
Интересное у тебя понятие компромисса. По-моему, городить настройки как-раз не моя задача, а того, кто делает экспорт и хочет вкорячить неведомый тег. И тот же человек должен позаботиться, чтобы и импорт сгенерированных gpx нормально работал, а не как сейчас. Или не заморачиваться с маршрутами вовсе, если нет желания доводить до ума всё остальное. |
|
|
|
|
|
Скажем так. Меня экспорт и в таком виде вполне устраивает. Того кто делал экспорт тоже. Поэтому я точно переделывать не собираюсь. Но меня точно так же устроит и экспорт всего в треки. Поэтому я и предложил тебе переделать, если не нравится. Или добавить настройки, если не хочешь обидеть GunSmoker-а. |
|