0001076: Экспорт GPX

Notes
(0016194) GunSmoker (developer) 21-07-2015 06:12	Если никто не против, я хотел бы это в свободное время поковырять - может и удастся сделать.

(0016197) zed (manager) 21-07-2015 06:22	Пробуй конечно, и спрашивать нечего. Все будут только ЗА.

(0016200) vasketsov (manager) 21-07-2015 08:14	Разумеется, хуже не будет. От меня будет подсказка. При импорте GPX в SACS реализована привязка картинок к точкам в соответствии со значением тэгов GPX. Это лежит в TMarkPictureListSimple.FindImportPicture и реализация в TMarkPictureListSimple.FindImportPictureInternal в файле Src\MarksDB\u_MarkPictureListSimple. Алгоритм - нахождение в именах картинок значения тэга, а если нет - кусков значения тэга. Имеет смысл сделать обратную штуку, так как разных sym немного, то есть, по имени картинки (например, BigBlueFlag.jpg) определять символ для POI и пихать его в экспорт. Для реализации этого в SAS ничего не надо дополнительно доделывать (в отличие от импорта).

(0016226) GunSmoker (developer) 24-07-2015 15:42	А можно скинуть примеры таких GPX файлов с картинками? Я, видимо, не совсем понимаю, о чём тут речь. Ибо меня в основном интересует экспорт нарисованного трека для заливки в фитнес-трекер.

(0016230) vasketsov (manager) 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. А хуже всего, что может быть, что разные устройства поддерживают разный набор этих значений (скорее всего, новые поддерживают более расширенный). Наверное имеет смысл как-то обособить это в коде и потом сделать возможность получения перечня возможных значений из внешнего файла.

(0016261) vdemidov (manager) 03-08-2015 08:25	>Если никто не против, я хотел бы это в свободное время поковырять - может и удастся сделать. Я тут вчера заглянул в спецификацию GPX и вспомнил почему я все время откладывал реализацию этого экспорта. В GPX определены точки и мульти-линии, но не полигоны (тем более мультиполигоны с дырками). Поэтому при экспорте нужно или вообще не экспортировать полигонов, о чем заранее предупреждать пользователя, или экспортировать как простые линии, после чего быть готовым отвечать на кучу вопросов типа "А почему я экспортировал полигон в GPX, а после импорта назад в САС он стал просто линией?" Мне больше нравится первый подход, тем более что есть еще форматы поддерживающие только точки (WPT), только треки (GPX), только полигоны (нами же изобретенный hlg) и тд. Но ты как хочешь, любая реализация будет лучше вообще отсутствующей.

(0016262) zed (manager) 03-08-2015 08:34	>В GPX определены точки и мульти-линии, но не полигоны Вполне логично, ведь это GPS eXchange Format и очевидно, что при экспорте нужно игнорировать полигоны. Не надо их ни во что конвертировать.

(0016263) vdemidov (manager) 03-08-2015 08:46	Я ж написал, что мне такой вариант больше нравится, но без предупреждения пользователя это будет очень неожиданное поведение. Имхо каждый экспорт должен определять какие типы меток он поддерживает, а подсистема экспорта должна анализировать выбранные пользователем метки и выдавать соответствующее предупреждение. А то странно будет выглядеть когда пользователь выбрал полигон, нажал экспорт, выбрал формат GPX и получил пустой файл.

(0016267) GunSmoker (developer) 03-08-2015 09:34	Я сделал экспорт точек, линий и мульти-линий, полигоны игнорирую. Пока добавлю варнинг тогда. Точки экспортируются в waypoint-ы, мульти-линии - в треки с сегментами, а линии: если точек мало (<= 500) - то в route, если много (> 500) - то в track с одним сегментом. Пока хочу ещё потестировать и дать человеку с Garmin-ом.

(0016269) Garl (manager) 03-08-2015 13:29	у меня есть Гармин, готов заценить.

(0016275) zed (manager) 03-08-2015 14:47	GunSmoker По-моему, было бы достаточно проверить работу на GoogleEarth или ещё какой-нибудь программе и засылать пулл-реквест. А уже потом, всем миром, можно было бы искать баги. Тем более, вот я сегодня поковырял немного экспорт и тебе придётся мерджить свой код с учётом этих исправлений. И кто знает, какие ещё внезапные изменения в основной ветке, могут сломать твой практически рабочий код. Поэтому, реквесты лучше не откладывать в долгий ящик.

(0016289) vasketsov (manager) 03-08-2015 21:31	>если точек мало (<= 500) - то в route Почему в rte?

(0016292) GunSmoker (developer) 03-08-2015 21:47	> Почему в rte? В смысле? А почему нет? rte/route - это логично для экспорта пути, который мы натыкали мышкой по карте, разве нет? trk/track - это всё же "фитнес", запись с датчиков. В SAS такое может появиться без импорта такого трека? Мы же не можем нарисовать зиллион точек на карте? Кроме того, trk без метки времени у каждой точки не воспринимается, например, Google Earth и Strava.

(0016293) GunSmoker (developer) 03-08-2015 23:33	> SACS Что такое SACS?

(0016294) GunSmoker (developer) 03-08-2015 23:55	https://bitbucket.org/sas_team/sas.planet.src/pull-requests/352/2781-1076/diff

(0016295) GunSmoker (developer) 04-08-2015 00:01	Что делать с всевозможными type и sym - непонятно, т.к. любой софт туда может писать произвольные данные. Делать несколько вариантов экспорта? Типа, "Garmin GPX", "ещё-кто-то GPX"?

(0016301) vdemidov (manager) 04-08-2015 06:08	>Что делать с всевозможными type и sym - непонятно, т.к. любой софт туда может писать произвольные данные. Так может просто писать свои названия картинок? А при импорте пытаться их читать.

(0016305) zed (manager) 04-08-2015 07:49	А вот и засада с rte: текущий парсер gpx их похоже не воспринимает и в SAS эти треки не залетают. Хотя в GoogleEarth они отображаются. Вот тут http://www.gpslib.ru/tracks/info/9043 отличный трек для тестов. Если импортировать этот трек в SAS, то получается 159 путей, а если потом его экспортировать в gpx и вновь импортировать, уже остаётся всего 57 путей. Остальное - роуты и их нету. GunSmoker Похоже, тебе ещё и парсер gpx придётся для SAS (до)писать ;)

(0016307) vasketsov (manager) 04-08-2015 10:26	>любой софт туда может писать произвольные данные Данные там должны соответствовать прибору. >ещё-кто-то GPX Разные приборы могут иметь разный набор картинок. Возможно, его получится вытащить в виде списка, но не уверен. А пока даже проверить некогда. >просто писать свои названия картинок? Если будет некий алгоритм типа: а) попытаться найти правильное имя картинки по полному; б) если не вышло, то записать полное и если это будет соответствовать формату gpx (в смысле значения тега) и приборы не будут крэшиться при загрузке таких треков - то почему бы и нет. >засада с rte Потому что rte - это роутиниг. Это вообще не надо. Я поэтому и спросил, на кой rte вообще. Юзай trk. >парсер gpx придётся для SAS (до)писать Там лишь надо включить rte, чтобы оно заработало. Там же, где включается wpt.

(0016308) vasketsov (manager) 04-08-2015 10:27	>Что такое SACS? https://bitbucket.org/vasketsov/vsasas

(0016311) GunSmoker (developer) 04-08-2015 11:21	> Так может просто писать свои названия картинок? А при импорте пытаться их читать. Можно просто добавить своё расширение GPX, записывать "1.png" в него. При импорте, соответственно, учитывать. > и если это будет соответствовать формату gpx (в смысле значения тега) и приборы не будут крэшиться при загрузке таких треков Скорее всего, лучше писать дефолтное значение. > А вот и засада с rte: текущий парсер gpx их похоже не воспринимает и в SAS эти треки не залетают. То, что там при импорте косяки - вопрос другой. > Потому что rte - это роутиниг. > Это вообще не надо. Почему? У меня use-case такой: я в SAS рисую ручкой путь на карте, тыкая мышкой, потом экспортирую это в GPX, импортирую в фитнес-трекер и использую для навигации на смарте. Соответственно, для этого use-case больше всего подходит rte. Чего-то подумалось, что проще было сделать экспорт в TCX, благо он более стандартизирован.

(0016316) GunSmoker (developer) 04-08-2015 11:38	> Если импортировать этот трек в SAS, то получается 159 путей, а если потом его экспортировать в gpx и вновь импортировать, уже остаётся всего 57 путей. Остальное - роуты и их нету. trkpt требует как минимум наличия времени прохождения точки. Большинство пишут так же ele (высоту). Оба этих параметра теряются при импорте. Метки не хранят эту информацию. Соответственно, просто так трек по линии создать невозможно. Я обошёл это введением "фальшивой скорости движения". Т.е. как бы мы двигались примерно 5 км/ч по треку - вот по этому расставляется фальшивое время прохождения трека. А rte - это тупо маршрут. Никаких танцев с бубном там не надо. Опять же, вопрос импорта rte - это другой вопрос.

(0016317) GunSmoker (developer) 04-08-2015 11:43	> Что такое SACS? > https://bitbucket.org/vasketsov/vsasas Т.е. это частная сборка? А с SAS.Планетой она как соотносится? В смысле, копируются ли из SACS в SAS какие-то возможности или наоборот?

(0016318) vdemidov (manager) 04-08-2015 11:48	Это форк, который живет отдельной жизнью. Кое что из SACS я выдергиваю в основную репу.

(0016319) zed (manager) 04-08-2015 11:50	>Метки не хранят эту информацию. Немного оффтопа: может есть дельное предложение, как эту ситуацию исправить? Я сейчас ковыряю новую БД для меток (SQLite2/MongoDB/СУБД) и могу, например, добавить текстовое поле в схему, куда можно будет писать json со всякой доп. инфой. Поиск по этой инфе, конечно, не заработает, но по крайней мере можно будет сохранить и достать из базы всё что нужно. В общем, я открыт для новых идей (только не пишите идеи в этот тикет, чтобы не оффтопить ещё больше).

(0016320) vasketsov (manager) 04-08-2015 11:52	Наоборот - только если товарищи сочтут нужным. Из саса - всё копируется (если нельзя скопировать, то выполняется альтернативная реализация). На момент начала работы zed над операциями над полигонами и vdemidov надо дырками всё что было в сасе, в sacs есть (точнее - по ревизию 8712). Как только закончит vdemidov дырки - перенесу остальное. О причинах создания sacs лучше в личку, нечего тут засирать тему.

(0016321) vdemidov (manager) 04-08-2015 11:54	В формате WKB предусмотрен вариант хранения Z координаты и так называемой M координаты (это может быть например время). Но все равно требуется дофига изменений что бы это поддерживать в САС.

(0016322) GunSmoker (developer) 04-08-2015 11:55	Я всё же замечу, что текущий импорт GPX импортирует некоторую доп. информацию в Descr меток примерно следующим образом: описание cmt: коммент number: 1 time: 2015.08.04... Само собой, лучше бы это было отдельными свойствами в БД меток.

(0016323) vasketsov (manager) 04-08-2015 12:08	>записывать "1.png" в него Только лучше без ".png", только "1". >лучше писать дефолтное значение А какое дефолтное? Синий флаг? >проще было сделать экспорт в TCX Это что вообще? Если проще - лучше в виде отдельной темы сделать. >rte - это тупо маршрут Вот именно. И когда я испортировал маршрут из навигатора, там получалось только начальная и конечная точки. То есть, аналогично можно предположить, что после импорта навигатор сам должен построить маршрут между точками, исходя из настроек, и это может быть НЕ прямая. В сасе отсутствует такой тип данных, как маршрут, маршрут можно только построить сторонними средствами для пары точек линии, но сохранится он как обычная линия. >требует как минимум наличия времени прохождения точки Это обязательный атрибут? То, что теряется при импорте - это проблемы реализации импорта. >можно будет писать json со всякой доп. инфой >Поиск по этой инфе, конечно, не заработает Зачем тогда json? >сохранить и достать из базы всё что нужно Да и проблема-то в другом, в массиве координат нет места для высот, скоростей и времён. Или ты хочешь иметь рядом массив для времён, высот, скоростей, температур и т.п.?

(0016324) vasketsov (manager) 04-08-2015 12:12	>требуется дофига изменений что бы это поддерживать в САС +1 >отдельными свойствами в БД меток Не поможет. Для треков время надо хранить для каждой точки. Без серьёзного изменения структур и логики хранения есть только один вариант - заюзать неиспользуемые биты в качестве короткого INTа для ссылки на другой массив, где и будут времена, скорости и т.п. Вот такой вот костыль.

(0016325) zed (manager) 04-08-2015 12:13	>Да и проблема-то в другом, в массиве координат Я понял, просто не к месту решил вспомнить, что БД меток это не нечто неизменное, а готовая ко всему сущность :) Естественно, речь не об sml.

(0016326) GunSmoker (developer) 04-08-2015 12:20	> А какое дефолтное? Синий флаг? Я так понимаю, какое мы выберем. > Вот именно. > И когда я испортировал маршрут из навигатора, там получалось только начальная и конечная точки. То есть, аналогично можно предположить, что после импорта навигатор сам должен построить маршрут между точками, исходя из настроек, и это может быть НЕ прямая. Не, подожди. Вопрос же не в импорте, а в экспорте. Вот ты когда в SAS маршрут рисуешь - ты разве тыкаешь в Москву и сразу в Химки? Нет, наверное, ты тыкаешь по дорогам, поворотам и т.д. В итоге получается красивый путь с небольшим количеством точек, каждая из которых имеет просто координаты. Это один-к-одному ложится на определение rte.

(0016328) GunSmoker (developer) 04-08-2015 12:22	Кстати, мульти-линию в UI нарисовать вручную можно? Я вижу только точки, линии и полигоны.

(0016329) GunSmoker (developer) 04-08-2015 12:24	Может импортировать любой trk в мульти-линию (пусть и состоящую только из одной линии, если в trk один сегмент), а rte - в линию? Тогда и экспорт: линии - всегда в rte, мульти-линии - всегда в trk?

(0016330) zed (manager) 04-08-2015 12:24	>мульти-линию в UI нарисовать вручную можно Нет.

(0016331) vasketsov (manager) 04-08-2015 12:43	>разве тыкаешь в Москву и сразу в Химки? Да. А потом выбираю в тубларке построение маршрута - и он строится. Не устраивает - отменяю изменения, меняю точки или провайдера автороутинга. А вообще я в сасе маршруты строил всего-лишь несколько раз. Это просто неудобно (для экспорта в прибор), в навигаторе удобнее. >один-к-одному ложится на определение rte Я не говорю, что не может возникнуть идеи экспортировать начало и конец маршрута как rte, но я говорю о том, что вся логика экспорта и импорта в сасе исходит из того, что импортируется и экспортируется линия как есть, а не данные для построения маршрута (средствами саса или прибора соответственно). Для работы с маршрутами сас заточен мягко говоря никак. Как подтверждение тому - отсутствующий экспорт в gpx и rte. Как вопрос для подумать - экспортировать в rte надо всю линию, которая возможно уже сама получена как результат построения маршрута, или только её края, края сегментов, чтобы строить маршрут уже внутри прибора? Имеет ли смысл экспортировать в rte всю линию, полученную импортом из прибора, если в линии есть "выстрелы" и прочие ошибки, или требуется процедура некоторого сглаживания, чтобы не портить маршрут и не заезжать на соседние улицы? >мульти-линию в UI нарисовать вручную можно Можно объединить несколько, а потом править руками. >какое мы выберем А смысл тогда выбирать, если всё, что залетит в прибор, будет с тем же синим флагом? Тогда уж по умолчанию пусто должно быть.

(0016332) vasketsov (manager) 04-08-2015 12:48	>линии - всегда в rte, мульти-линии - всегда в trk? Такое возможно, но в сасе нет никакой специальной логики, зависящей от числа сегментов в линии, никакой смысловой нагрузки на это не накладывается. Да и простая линия легко может стать мультилинией (при операциях). Если уж так хочется экспорт именно в rte, то имеет смысл сделать его отдельно или как опцию для экспорта в GPX, чтобы в том числе возможно делить мультилинии по сегментам (если они были ранее собраны вместе).

(0016333) vdemidov (manager) 04-08-2015 12:50	>>мульти-линию в UI нарисовать вручную можно >Нет. Там не хватает только кнопки вставки разрыва на тулбаре. Пока никто не просил. :)

(0016335) vdemidov (manager) 04-08-2015 13:03	>Для треков время надо хранить для каждой точки. >Без серьёзного изменения структур и логики хранения есть только один вариант - заюзать неиспользуемые биты в качестве короткого INTа для ссылки на другой массив, где и будут времена, скорости и т.п. Вот такой вот костыль. Мне тут мысль пришла, а что если сделать отдельную сущность - Базу треков, которая будет ориентирована на хранение именно трека (позиция, время, скорость, высота, направление) и позволит только импортировать, экспортировать и удалять треки (без редактирования). Ну и само собой отображать.

(0016336) vasketsov (manager) 04-08-2015 13:04	Вижу в коде GarminSymNames: array[0..138] of String = ( этого достаточно. Надо найти произвольный элемент в этом массиве, каждое слово которого есть в имени картинки у экспортируемой точки. Если нашлось - подставить найденное. Если нет - оставить sym пустым. В принципе, можно для точности искать самое длинное среди всех найденных, но наверное это не принципиально, в крайнем случае это решится изменением порядка элементов в массиве.

(0016337) GunSmoker (developer) 04-08-2015 13:08	> Да. А потом выбираю в тубларке построение маршрута - и он строится. Не устраивает - отменяю изменения, меняю точки или провайдера автороутинга. Почему-то у меня эта функция не работает вообще, не могу проверить что при этом происходит с линией. Ошибок нет, исключений нет, просто втихую ничего не происходит. > Я не говорю, что не может возникнуть идеи экспортировать начало и конец маршрута как rte В rte экспортируется не только начало и конец, но и все промежуточные точки. > Для работы с маршрутами сас заточен мягко говоря никак. Как подтверждение тому - отсутствующий экспорт в gpx и rte. Я собственно и пилю экспорт в GPX по этой причине. Мне в SAS удобнее строить маршрут, т.к. есть большой выбор карт, по которым можно посмотреть, в какую жопу я собрался залезть. > Можно объединить несколько, а потом править руками. Можно пальцем ткнуть, где это? Я не вижу. Текущее поведение мне кажется более логичным. Вот мы взяли маршрут в навигаторе - старт/стоп и одна точка посередине (стоянка), импортировали в SAS, получили одну линию из двух прямых. Хотим - оставим как есть, хотим - построим точный маршрут. В любом случае, мы экспортируем из SAS, получаем rte, копируем его в навигатор - бум, получили что-то полезное. А если экспортировать как trk, перенесём мы потом эти три точки в виде трека в навигатор - и что мы с ними будем делать?

(0016339) GunSmoker (developer) 04-08-2015 13:09	> Мне тут мысль пришла, а что если сделать отдельную сущность - Базу треков, которая будет ориентирована на хранение именно трека (позиция, время, скорость, высота, направление) и позволит только импортировать, экспортировать и удалять треки (без редактирования). Ну и само собой отображать. Звучит логично.

(0016340) vdemidov (manager) 04-08-2015 13:13	> Почему-то у меня эта функция не работает вообще, не могу проверить что при этом происходит с линией. Ошибок нет, исключений нет, просто втихую ничего не происходит. Там в последнее время была жива прокладка только с помощью yournavigation, но похоже и она умерла.

(0016343) vasketsov (manager) 04-08-2015 13:27	>у меня эта функция не работает вообще Не все провайдеры рабочие, ткнись в другого, там наверное давно порядок не наводили. >если сделать отдельную сущность - Базу треков >позволит только импортировать, экспортировать и удалять треки Нет ничего проще: папка с кучкой файлов поддерживаемого формата. Просилось ещё сто лет назад. Зато универсальней некуда. Или в базе в блоб их утаптывать. Но правда всё это никак вопросы экспорта не отменяет. >Можно пальцем ткнуть, где это? Я не вижу Объединение меток в одной группе. Неужели нет этого? Вроде было. В sacs это по ПКМ на метке есть. Вроде бы и в основной было. Может zed выпилил, когда операции с геометриями делал? Я не в курсе просто. В крайнем случае наверняка можно импортировать KML, где руками объединить куски в одну метку. >перенесём мы потом эти три точки в виде трека в навигатор - и что мы с ними будем делать? Ну, например, включать или отключать видимость на карте, сигнал о приближении к ним и т.п. Это кстати причина того, что полигоны тоже надо экспортировать, как trk (они будут замкнутые). Поэтому и надо выбирать, в rte или в trk гнать линии. Просто потом оно по-разному используется в приборе.

(0016345) zed (manager) 04-08-2015 13:32	> сделать отдельную сущность - Базу треков Да ну нафиг, с отдельной сущностью. Куда лучше - придумать механизм навешивания дополнительных свойств точкам геометрии.

(0016346) GunSmoker (developer) 04-08-2015 13:57	> Поэтому и надо выбирать, в rte или в trk гнать линии. Как-нибудь это указывать в свойствах линии, не?

(0016347) GunSmoker (developer) 04-08-2015 14:14	> Ну, например, включать или отключать видимость на карте, сигнал о приближении к ним и т.п. А смысл в этом, если это не трек, а маршрут? Будет показано строго две прямые линии, соединяющие Москву с Химками и остановкой посередине.

(0016348) GunSmoker (developer) 04-08-2015 14:54	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'.

(0016349) vasketsov (manager) 04-08-2015 16:26	>Будет показано строго две прямые линии Зачем прямые? Можно же не бездумно экспортировать всякую ерунду типа отрезка на пол-области, а например острова обвести, границы леса, полян, оврагов и прочее - и в GPX в прибор, а там включать или отключать их видимость. Это получается как отдельный слой в приборе. >Как-нибудь это указывать в свойствах линии, не? Возможно. Поддержу любую разумную идею, вплоть до атрибутов и (куска) имени категории или самой метки. Идея про число точек меньше 500 разумной мне не кажется. Если исходить из реального построения маршрута, то три-четыре, ну пять - это максимум для rte, плюс замкнутые делать всегда как trk. Но опять же, это сильно дискуссионно. Идеальным решением был бы некий атрибут или тип (подтип), но его нет.

(0016350) GunSmoker (developer) 04-08-2015 17:12	Разумеется, 500 точек - это временное решение, т.к. у меня хранятся и импортированные треки и вручную отрисованные маршруты.

(0016351) vdemidov (manager) 05-08-2015 08:32	>> сделать отдельную сущность - Базу треков >Да ну нафиг, с отдельной сущностью. Куда лучше - придумать механизм навешивания дополнительных свойств точкам геометрии. Ну, не знаю. Как по мне так навешивание дополнительных свойств точкам слишком уж усложняет всю работу с метками, хотя реально такое нужно только для треков. Тем более в программе уже есть работа с треками, хотя и в самом зачаточном состоянии (TGPSTrackPoint и тд).

(0016354) GunSmoker (developer) 05-08-2015 10:19	> Как по мне так навешивание дополнительных свойств точкам слишком уж усложняет всю работу с метками, хотя реально такое нужно только для треков. Можно и для маршрутов. Угловые точки можно бы именовать ("стоянка"), писать примечания (типа "налево").

(0016355) vdemidov (manager) 05-08-2015 10:52	>Можно и для маршрутов. Угловые точки можно бы именовать ("стоянка"), писать примечания (типа "налево"). Можно, но я скорее всего заброшу весь этот проект раньше чем что-то похожее будет реализовано. А вот поддержка работы с однородными треками мне бы самому, вероятно, пригодилась бы.

(0016406) zed (manager) 26-08-2015 21:27	>Разумеется, 500 точек - это временное решение Боюсь, как бы это временное решение не стало постоянным. И лично мне эта идея с маршрутами не нравится, потому как банальный импорт трека в SAS и экспорт его опять в gpx, выдаёт некую новую сущность, которой в треке изначально небыло. И что самое плохое, что нету конфига, чтобы можно было это поведение изменить.

(0016407) vdemidov (manager) 27-08-2015 07:24	Ну, переделай, если считаешь, что так будет правильнее. Я не вижу значительных преимуществ у того или иного решения этой проблемы.

(0016408) zed (manager) 29-08-2015 08:10	>Ну, переделай Что именно? Вообще удалить создание маршрутов и наплевать на мнение GunSmoker-а? Представляю себе его реакцию. Нужно прийти к какому-то компромиссу.

(0016409) vdemidov (manager) 29-08-2015 09:12	>Нужно прийти к какому-то компромиссу. Ну, значит пусть остается как есть. Или бери и городи настройки (отдельный конфиг, который экспорту будет передаваться на старте программы и использоваться в процессе экспорта.

(0016410) zed (manager) 29-08-2015 09:23	Интересное у тебя понятие компромисса. По-моему, городить настройки как-раз не моя задача, а того, кто делает экспорт и хочет вкорячить неведомый тег. И тот же человек должен позаботиться, чтобы и импорт сгенерированных gpx нормально работал, а не как сейчас. Или не заморачиваться с маршрутами вовсе, если нет желания доводить до ума всё остальное.

(0016411) vdemidov (manager) 29-08-2015 09:30	Скажем так. Меня экспорт и в таком виде вполне устраивает. Того кто делал экспорт тоже. Поэтому я точно переделывать не собираюсь. Но меня точно так же устроит и экспорт всего в треки. Поэтому я и предложил тебе переделать, если не нравится. Или добавить настройки, если не хочешь обидеть GunSmoker-а.

Users who viewed this issue
User List	Anonymous (9445x), caddis (1x), Tolik (3x), drakula133666 (1x), WWasily (2x), bk99 (1x), onuff (1x), Oldest_Yeti (1x), netsky (5x), Nebelyng (2x), ingener (14x), vdemidov (80x), Garl (20x), zed (61x), GunSmoker (63x), phiggins (2x), echo (2x), gma (2x), vasketsov (37x)
Total Views	9743
Last View	24-11-2024 14:17

Issue History
Date Modified	Username	Field	Change
22-12-2011 06:43	Tolik	New Issue
22-12-2011 06:46	Tolik	Relationship added	related to 0000516
22-12-2011 06:48	Tolik	Status	new => acknowledged
22-12-2011 06:48	Tolik	Description Updated	View Revisions
22-12-2011 06:54	Tolik	Priority	normal => low
22-12-2011 06:54	Tolik	Severity	minor => feature
23-12-2011 22:03	gpsMax	Tag Attached: gpx
23-12-2011 22:03	gpsMax	Tag Attached: экспорт
23-01-2012 11:06	vdemidov	Product Version	=> 110418
23-01-2012 11:06	vdemidov	Target Version	=> 24xxxx
23-01-2012 11:06	vdemidov	Status	acknowledged => confirmed
10-10-2012 16:37	Tolik	Relationship added	has duplicate 0001622
27-08-2013 09:36	vdemidov	Relationship added	parent of 0002120
29-08-2013 09:20	vdemidov	Tag Attached: метки
18-03-2014 06:36	vdemidov	Relationship added	has duplicate 0002373
10-04-2014 12:05	zed	Relationship added	has duplicate 0002406
28-01-2015 07:16	zed	Relationship added	has duplicate 0002609
21-07-2015 06:12	GunSmoker	Note Added: 0016194
21-07-2015 06:22	zed	Note Added: 0016197
21-07-2015 06:28	GunSmoker	Assigned To	=> GunSmoker
21-07-2015 06:28	GunSmoker	Status	confirmed => assigned
21-07-2015 08:14	vasketsov	Note Added: 0016200
24-07-2015 15:42	GunSmoker	Note Added: 0016226
27-07-2015 08:06	vasketsov	Note Added: 0016230
27-07-2015 08:08	vasketsov	Note Edited: 0016230	View Revisions
03-08-2015 08:25	vdemidov	Note Added: 0016261
03-08-2015 08:34	zed	Note Added: 0016262
03-08-2015 08:46	vdemidov	Note Added: 0016263
03-08-2015 09:34	GunSmoker	Note Added: 0016267
03-08-2015 13:29	Garl	Note Added: 0016269
03-08-2015 14:47	zed	Note Added: 0016275
03-08-2015 21:31	vasketsov	Note Added: 0016289
03-08-2015 21:47	GunSmoker	Note Added: 0016292
03-08-2015 23:33	GunSmoker	Note Added: 0016293
03-08-2015 23:55	GunSmoker	Note Added: 0016294
04-08-2015 00:01	GunSmoker	Note Added: 0016295
04-08-2015 06:08	vdemidov	Note Added: 0016301
04-08-2015 07:49	zed	Note Added: 0016305
04-08-2015 10:26	vasketsov	Note Added: 0016307
04-08-2015 10:27	vasketsov	Note Added: 0016308
04-08-2015 11:21	GunSmoker	Note Added: 0016311
04-08-2015 11:38	GunSmoker	Note Added: 0016316
04-08-2015 11:43	GunSmoker	Note Added: 0016317
04-08-2015 11:48	vdemidov	Note Added: 0016318
04-08-2015 11:50	zed	Note Added: 0016319
04-08-2015 11:52	vasketsov	Note Added: 0016320
04-08-2015 11:54	vdemidov	Note Added: 0016321
04-08-2015 11:55	GunSmoker	Note Added: 0016322
04-08-2015 12:08	vasketsov	Note Added: 0016323
04-08-2015 12:12	vasketsov	Note Added: 0016324
04-08-2015 12:13	zed	Note Added: 0016325
04-08-2015 12:20	GunSmoker	Note Added: 0016326
04-08-2015 12:22	GunSmoker	Note Added: 0016328
04-08-2015 12:24	GunSmoker	Note Added: 0016329
04-08-2015 12:24	zed	Note Added: 0016330
04-08-2015 12:43	vasketsov	Note Added: 0016331
04-08-2015 12:48	vasketsov	Note Added: 0016332
04-08-2015 12:50	vdemidov	Note Added: 0016333
04-08-2015 13:03	vdemidov	Note Added: 0016335
04-08-2015 13:04	vasketsov	Note Added: 0016336
04-08-2015 13:08	GunSmoker	Note Added: 0016337
04-08-2015 13:09	GunSmoker	Note Added: 0016339
04-08-2015 13:13	vdemidov	Note Added: 0016340
04-08-2015 13:27	vasketsov	Note Added: 0016343
04-08-2015 13:32	zed	Note Added: 0016345
04-08-2015 13:57	GunSmoker	Note Added: 0016346
04-08-2015 14:14	GunSmoker	Note Added: 0016347
04-08-2015 14:54	GunSmoker	Note Added: 0016348
04-08-2015 16:26	vasketsov	Note Added: 0016349
04-08-2015 17:12	GunSmoker	Note Added: 0016350
05-08-2015 08:32	vdemidov	Note Added: 0016351
05-08-2015 10:19	GunSmoker	Note Added: 0016354
05-08-2015 10:52	vdemidov	Note Added: 0016355
26-08-2015 07:14	vdemidov	Target Version	24xxxx => 150915
26-08-2015 07:15	vdemidov	Status	assigned => resolved
26-08-2015 07:15	vdemidov	Fixed in Version	=> 150915
26-08-2015 07:15	vdemidov	Resolution	open => fixed
26-08-2015 21:27	zed	Note Added: 0016406
27-08-2015 07:24	vdemidov	Note Added: 0016407
29-08-2015 08:10	zed	Note Added: 0016408
29-08-2015 09:12	vdemidov	Note Added: 0016409
29-08-2015 09:23	zed	Note Added: 0016410
29-08-2015 09:30	vdemidov	Note Added: 0016411
01-09-2015 13:13	GunSmoker	Relationship added	related to 0002807
18-05-2017 18:54	zed	Relationship added	related to 0003227

SASGIS