SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000142SAS.Планета[All Projects] Хотелкаpublic07-10-2010 18:5410-10-2012 11:52
Reporteraneox 
Assigned Tovdemidov 
PrioritynormalSeverityfeatureReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformWindowsOSXPOS VersionSP3
Product Version100920.Alfa 
Target Version120808Fixed in Version120808 
Summary0000142: Новый принцип раскраски трека в зависимости от скорости
Description1. Выбираются фиксированные диапазоны, здесь их количество в общем-то не важно, любое разумное, нагляднее всего видимо 3-4 отрезка вида (0-40-80-120) или (0-40-60-90-120), важно, чтобы реперные точки определяли существенные изменения в режиме движения.
 2. Для каждой реперной точки указывается цвет (любой, просто RGB) сверху и снизу (в математических терминах 60+0 и 60-0 соответственно). Если эти цвета для одной точки совпадают - получим плавный переход между отрезками (палитрами), если не совпадают - будет контрастный переход. Если на концах одного отрезка цвета совпадают (например, 40+0 и 60-0, совпадение цветов имеет смысл проверять в алгоритме отдельно), то получится одноцветная заливка во всём диапазоне (может быть актуально для диапазона от 0+0 до 5-0, просто состояние покоя, либо актуально для загрузки большого количества треков). С точки зрения алгоритма это абсолютно без разницы, это просто произвольные константы в цветовом пространстве (кстати, и вовсе не обязательно RGB).
 3. Простейшая стандартная линейная интерполяция на нужном отрезке даст нужный цвет (независимо по каждому цветовому каналу, понятно что в конце надо "округлить" для возвращения в цветовое пространство). Если редкое попадание точно в границу отрезка (точно 60.) - берётся верхний предел (60+0) или нижний предел (60-0), как хочется. Актуально прежде всего для 0+0 (начало движения) и для конца верхнего диапазона (120-0), впрочем, на этот счёт есть и другие методы. Интерполяция более высокого порядка возможна, но пока что вопрос в её целесообразности открытый. Вот тут как раз важна доступная вычислительная мощность, чтобы когда загрузишь пару сотен треков, ничего не зависло и всё нормально скроллилось. А для тех, кто мечтает только о плавных переходах и дочитал до этих строк, предлагаю сравнить требуемые ресурсы для случая резкого перехода (определение скорости просто по case-у между несколькими кокретными цветами) и плавного (после case для границ отрезка натягивается ещё и интерполяция).
 4. Отдельная часть алгоритма касается верхнего предела и обработки скорости выше верхней реперной точки (например, выше 120). Основная предпосылка здесь, что уже отрисованные треки не должны перекрашиваться в другие цвета, как при появлении новых точек трека, так и при загрузке новых треков. В том числе если к автомобильным трекам кинуть самолётный. Проще всего использовать один конкретный цвет (например, от 120-0 или вообще отдельный). В принципе ничто не мешает сделать всяким отпетым извращенцам ещё диапазоны сверху, например, к приведённым выше ещё добавить что-нибудь типа (120-160-300-1100-1500) для всяких вертолётов и самолётов (а нижние диапазоны вообще да хоть убить совсем). Но выше MAX-0 всё равно один сплошной цвет.

 >значения скоростей и цвета очень хорошо задавать бы руками
 Безусловно всё руками должно быть. Даже в разных странах разные ограничения скоростного режима. Да и самолёты с моторками и байдарками по-разному передвигаются, и статистика по скоростям будет разная. Надо ли пытаться по загружаемому треку (запуская некий эвристический анализатор) понять, что это за трек, кто так ехал и на чём (и как следствие - выбор параметров алгоритма раскраски, в том числе несколько активных алгоритмов раскраски одновременно для разных треков) - вопрос открытый, и что куда более важно - отдельный. Но делать надо изначально нормально, с возможностью простой доработки без переписывания всего и вся.
Tagsпути, треки
Attached Files

- Relationships
related to 0000755confirmed Хинт с информацией о треке при наведении на него мышки 

-  Notes
(0000287)
vdemidov (manager)
08-10-2010 06:33

Давно уже цвет отображаемого GPS трека зависит от скорости. Цвет показывает как соотносится скорость в точке с максимальной скоростью
(0000292)
Garl (manager)
08-10-2010 09:36

а подгружать и отображать эти трэки после перезапуска программы можно?
(0000293)
aneox (reporter)
08-10-2010 11:46

сейчас в планете 2 цвета трека, я предлагаю 4
(0000295)
vdemidov (manager)
08-10-2010 12:38

Сейчас не два цвета, а 100 градаций от синего к красному в зависимости от соотношения скорости в точке к максимальной скорости.
(0000298)
aneox (reporter)
08-10-2010 14:59

сейчас градация 2 цветов, а я прошу о 4, пока можно сделать без сохранения, раз уж там всю систему меток переделывать
(0000300)
vdemidov (manager)
12-10-2010 08:20

Приведите пример формулы определения цвета. Например есть данные о средней скорости, максимальной, и текущей скорости. Напишите как вы представляете алгоритм выбора цвета для отрисовки участка трека, потому что я не представляю.
(0000308)
Ledmyc (reporter)
12-10-2010 15:18
edited on: 12-10-2010 15:24

Я думаю, что как-то так:

если ТЕК >= 10 то
    если ТЕК > СРЕД то
        Ц = округлить (255*(ТЕК-СРЕД)/(МАКС-СРЕД))
        цветRGB (Ц, 255-Ц, 0)
    иначе
        Ц = округлить (255*(ТЕК-СРЕД)/(10-СРЕД))
        цветRGB (0, 255-Ц, Ц)
    конец_если
иначе
    цветRGB (0, 0, 0)
конец_если

Хотя получается не очень хороший переход цвета при переходе через 10 км/ч. Ещё хуже, когда средняя скорость ниже 10 км/ч.

(0000309)
vdemidov (manager)
12-10-2010 16:48

Вот и придумывайте как лучше сделать, не забывая, что люди не только на машинах ездят, но и ходят пешком, а так же летают на самолетах.
(0000314)
Ledmyc (reporter)
12-10-2010 19:30
edited on: 12-10-2010 20:04

Значит, нужно не фиксировать границу чёрного цвета, а делать аналогичный переход из синего в чёрный после 1/5 (или любой другой части) от средней скорости.

Если aneox меня поддержит, то, например, так:

НИЖ = СРЕД/5 — можно и не 5, а что-то другое
если ТЕК > СРЕД то
    Ц = округлить (255*(ТЕК-СРЕД)/(МАКС-СРЕД))
    цветRGB (Ц, 255-Ц, 0)
иначе если ТЕК > НИЖ то
    Ц = округлить (255*(ТЕК-СРЕД)/(НИЖ-СРЕД))
    цветRGB (0, 255-Ц, Ц)
иначе
    Ц = округлить (255*ТЕК/НИЖ)
    цветRGB (0, 0, Ц)
конец_если

(0000315)
aneox (reporter)
13-10-2010 05:03

ну нужно попробовать реализовать это на практике, позадовать разные параметры скоростей и посмотреть переходы на прямой линии, попробую, но щяс времени в обрез
(0000317)
vdemidov (manager)
13-10-2010 05:16

Ну последний вариант формулы уже на что-то похож, но нужно проверять переходы в крайних точках что бы функция цвета была непрерывной.
(0000332)
aneox (reporter)
13-10-2010 20:17

когда текущая равна или почти равна средней, переход очень резкий и


в строке
Ц = округлить (255*ТЕК/НИЖ)

когда средний очень мал то ниж = 0, а на ноль не делит
(0000333)
aneox (reporter)
13-10-2010 20:22
edited on: 13-10-2010 20:22

если тек <= сред то глюки страшные с цветом, буду разбираться, выше среднего отображает красиво

(0000334)
Ledmyc (reporter)
13-10-2010 21:48
edited on: 13-10-2010 22:29

>если тек <= сред то глюки страшные с цветом
Возможно, используете беззнаковый числовой тип данных. Тогда достаточно поменять местами операнды обеих разностей: Ц = округлить (255*(СРЕД-ТЕК)/(СРЕД-НИЖ))

>когда средний очень мал то ниж = 0
Вы используете целочисленный тип данных вместо вещественного (где «доделиться» до нуля практически невозможно). Я прав?

Набросал слегка в Excel'е: http://narod.ru/disk/26079151000/SpeedColor.xls.html

(0000341)
vdemidov (manager)
14-10-2010 06:17

Не. Слишком резкие переходы. Функция цвета должна быть непрерывной. То есть, если у нас ТЕК = НИЖ - delta и если ТЕК = НИЖ + delta, цвет должен получаться почти одинаковый. То же самое для точки ТЕК = СРЕД. Так что думайте пока.
(0000345)
gpsMax (manager)
14-10-2010 10:27

А можно поставить более нейтральный и информативный заголовок?
(0000346)
Ledmyc (reporter)
14-10-2010 10:58

>Не. Слишком резкие переходы.
Это потому что и скорость так резко не может меняться. Немножко переделал xls-файл: скорость теперь задаётся функцией, можно менять коэффициенты и шаг времени.

http://narod.ru/disk/26087402000/SpeedColor.xls.html
(0000347)
vdemidov (manager)
14-10-2010 11:33

Выпишите отдельно окончательный алгоритм вычисления RGB для заданных текущей, средней и максимальной скорости и можно реализовывать.
(0000348)
Ledmyc (reporter)
14-10-2010 12:04

Так он же выписан (я ничего не менял):
http://sasgis.org/mantis/view.php?id=142#c314
Единственная рекомендация: округлять лучше не просто отбрасывая дробную часть, а именно до ближайшего целого.
(0000352)
aneox (reporter)
14-10-2010 17:56

и не забудьте что нужно брать не просто среднюю скорость а среднюю скорость в движении
(0001024)
John68 (reporter)
19-02-2011 20:22

Хотел бы поделиться своими соображениями по этому вопросу.
Сейчас в программе реализован алгоритм раскраски трека в зависимости от скорости движения ПРИ ЗАПИСИ этого трека, т.е. во время движения. Функция бесспорно нужная! НО стоит сохранить трек в базе, как вся полезность этого алгоритма попросту теряется. Так как при импорте этого же или любого другого трека, например с навигатора, скажем, для анализа пройденного пути или выявления проблемных мест на маршруте, программа предлагает выбрать самому из предложенной палитры и он отображается ОДНИМ единым цветом.
На мой взгляд, было бы гораздо полезнее для пользователей SAS.Planet все это с точностью до наоборот. То есть, записываемый во время движения трек сделать сплошным цветом (ведь он просто фиксирует пройденный путь), а вот при импорте трека из базы сделать его в цвете. Тогда уже можно будет, как уже писалось выше:"можно заранее установить скорость передвижения на участке, иметь представление о скоростных и опасных участках..."
И второе. Думаю, было бы гораздо логичнее, если минимальная скорость была красной (традиционный цвет опасности),а max - зеленой.
(0001026)
vdemidov (manager)
19-02-2011 21:33

Увы, сейчас для меток-путей не предусмотрено наличие сохраненной скорости в каждой из точек. Так что пока раскраска возможна только для активного трека.
(0001034)
Vinil_37 (reporter)
21-02-2011 20:18

А можно сделать цвет низхкой скорости не чёрый, а то он совсем какой-то незаметный на спутниковых снимках.
(0001036)
vasketsov (manager)
22-02-2011 09:43

>придется создать новый формат файлов трэков
А это ещё зачем? Это вопрос не данных, а исключительно их отображения, лишь бы в треке была информация о скорости.
>гораздо логичнее, если минимальная скорость была красной (традиционный цвет опасности),а max - зеленой
Вообще-то "тише едешь - дальше будешь", а никак не наоборот. Чем выше скорость, тем по вашей логике больше опасность. Так что максимальная красная как раз логично.
(0001037)
aneox (reporter)
22-02-2011 09:54

>А это ещё зачем? Это вопрос не данных, а исключительно их отображения, лишь бы в треке была информация о скорости.

Я имел ввиду для последующей загрузки из файла такого трека. Либо оставить plt но к нему какойнить *.cplt приделать, типо как *.map для озика
(0001040)
vasketsov (manager)
22-02-2011 10:39

>к нему какойнить *.cplt приделать
зачем? что там будет?
палитра и вообще отображение и всякая раскраска - вопрос предпочтений пользователя, который смотрит на трек, а вовсе не настройка трека и даже не вопрос предпочтений автора трека. даже на сколько частей делить диапазон скоростей, и то дискуссионно. в конце концов ведь и дальтоники есть, и люди с прочими нарушениями зрения. Кроме того, в зависимости от монитора, освещения, режима, могут быть разные оптимальные настройки отображения для конкретного момента времени, и требовать перезагрузки трека в программу для изменения его отображения совершенно некошерно.
Так что треку, что бы под этим не понималось, должно быть глубоко фиолетово, что его кто-то где-то как-то собрался раскрашивать.
(0001042)
aneox (reporter)
22-02-2011 10:45

фиолетово то да, но где же тогда будут храниться данные о скорости в конкретной точки трека
(0001043)
vasketsov (manager)
22-02-2011 11:21

в самом треке и будут храниться, там кроме координат ещё и высоты, глубины, скорости и много чего другого можно хранить. берём трек, открывает его где-нить типа GPSMapEdit и смотрим, что там есть.
а вообще, забавная идея хранить скорости рядом с треком, предлагаете полностью дублировать точки трека в файле со скоростями?
(0001044)
aneox (reporter)
22-02-2011 11:30

я просто особо в этом не силен. Ну раз стандартный формат файла трека может хранить в себе данные о скорости, в чем же тогда загвоздка у нашего многоуважаемого автора планеты с загрузкой цветных треков. Я полагал что формат не позволяет.
(0001046)
vasketsov (manager)
22-02-2011 11:45

1. В треке может быть информация о скоростях, а может её и не быть.
2. На gpslib.ru есть раскраска треков цветами и соответствующая аналитика, можно поглядеть для ознакомления. А можно и свой трек туда запулить и поглядеть как раскрасится. Там есть несколько моих треков из разных источников, можно найти по логину, они точно не "огрублённые", вся инфа типа скорости там есть.
(0001049)
vasketsov (manager)
22-02-2011 12:18

>цветRGB (0, 255-Ц, Ц)
Подобные формулы имеют как минимум два существенных недостатка.
1. При всей плавности перехода между цветами, переходы через 20, 60, 90, 110 км/ч должны выделяться, например, переходом в другую цветовую гамму. Потому как это важные признаки, фактически это изменение режима движения, качества покрытия, загруженности дороги и т.п. А наглядность отображения (предоставления информации) всё же важнее некой плавности градиентного перехода, которая сама по себе не является самоцелью. Не нужно стараться загнать весь диапазон скоростей в один градиентный переход в рамках какой-то конкретной палитры. В идеале глядя на трек, глаз должен сразу получать информацию о существенных изменениях в режиме движения, а не выискивать, где почти-что-сильно-красный сменился на чуть-менее-сильно-красный.
2. Этот недостаток ещё более критичен. Если все скорости на треке увеличить или уменьшить в одинаковое число раз, раскраска его не изменится. Это делает невозможным а) визуальный анализ множества треков одновременно и б) анализ трека без дополнительной информации о исходных параметрах-скоростях.
(0001052)
gpsMax (manager)
23-02-2011 01:33

> переходы через 20, 60, 90, 110 км/ч должны выделяться

Во-первых, не должны они резко выделяться, о чём говорилось выше. Плавное перетекание цветов смотрится куда лучше. Во-вторых, значения скоростей и цвета очень хорошо задавать бы руками.
(0001066)
vasketsov (manager)
23-02-2011 13:52

>не должны они резко выделяться, о чём говорилось выше
Обоснование было? Вы вообще в курсе, зачем используется высококонтрастный интерфейс? Ничего никому не должно, это всё исключительно предпочтения пользователя. Вы не поверите, но это даже от вычислительной мощности, от монитора, от освещения, от времени суток, от используемой подложки (сервиса снимков или карт) зависит, и много ещё от чего. Никогда не задумывались, тесты у окулистов проходят рано утром, утром при дневном свете или вечером перед сном, и почему? В общем, не надо за пользователя додумывать то, что пользователь знает всяко лучше. Тем более если алгоритм не зависит от подобных ненужных допущений.

Кроме того, у меня возникает мысль, что Вы либо не внимательны, либо не понимаете, как стыкуются палитры в случае перехода от одной к другой. Иначе бы слово "резко" в процитированном мной ответе не присутствовало. Впрочем, не только Вы не понимаете, судя по этой теме.

Объясняю алгоритм популярно:
1. Выбираются фиксированные диапазоны, здесь их количество в общем-то не важно, любое разумное, нагляднее всего видимо 3-4 отрезка вида (0-40-80-120) или (0-40-60-90-120), важно, чтобы реперные точки определяли существенные изменения в режиме движения.
2. Для каждой реперной точки указывается цвет (любой, просто RGB) сверху и снизу (в математических терминах 60+0 и 60-0 соответственно). Если эти цвета для одной точки совпадают - получим плавный переход между отрезками (палитрами), если не совпадают - будет контрастный переход. Если на концах одного отрезка цвета совпадают (например, 40+0 и 60-0, совпадение цветов имеет смысл проверять в алгоритме отдельно), то получится одноцветная заливка во всём диапазоне (может быть актуально для диапазона от 0+0 до 5-0, просто состояние покоя, либо актуально для загрузки большого количества треков). С точки зрения алгоритма это абсолютно без разницы, это просто произвольные константы в цветовом пространстве (кстати, и вовсе не обязательно RGB).
3. Простейшая стандартная линейная интерполяция на нужном отрезке даст нужный цвет (независимо по каждому цветовому каналу, понятно что в конце надо "округлить" для возвращения в цветовое пространство). Если редкое попадание точно в границу отрезка (точно 60.) - берётся верхний предел (60+0) или нижний предел (60-0), как хочется. Актуально прежде всего для 0+0 (начало движения) и для конца верхнего диапазона (120-0), впрочем, на этот счёт есть и другие методы. Интерполяция более высокого порядка возможна, но пока что вопрос в её целесообразности открытый. Вот тут как раз важна доступная вычислительная мощность, чтобы когда загрузишь пару сотен треков, ничего не зависло и всё нормально скроллилось. А для тех, кто мечтает только о плавных переходах и дочитал до этих строк, предлагаю сравнить требуемые ресурсы для случая резкого перехода (определение скорости просто по case-у между несколькими кокретными цветами) и плавного (после case для границ отрезка натягивается ещё и интерполяция).
4. Отдельная часть алгоритма касается верхнего предела и обработки скорости выше верхней реперной точки (например, выше 120). Основная предпосылка здесь, что уже отрисованные треки не должны перекрашиваться в другие цвета, как при появлении новых точек трека, так и при загрузке новых треков. В том числе если к автомобильным трекам кинуть самолётный. Проще всего использовать один конкретный цвет (например, от 120-0 или вообще отдельный). В принципе ничто не мешает сделать всяким отпетым извращенцам ещё диапазоны сверху, например, к приведённым выше ещё добавить что-нибудь типа (120-160-300-1100-1500) для всяких вертолётов и самолётов (а нижние диапазоны вообще да хоть убить совсем). Но выше MAX-0 всё равно один сплошной цвет.

>значения скоростей и цвета очень хорошо задавать бы руками
Безусловно всё руками должно быть. Даже в разных странах разные ограничения скоростного режима. Да и самолёты с моторками и байдарками по-разному передвигаются, и статистика по скоростям будет разная. Надо ли пытаться по загружаемому треку (запуская некий эвристический анализатор) понять, что это за трек, кто так ехал и на чём (и как следствие - выбор параметров алгоритма раскраски, в том числе несколько активных алгоритмов раскраски одновременно для разных треков) - вопрос открытый, и что куда более важно - отдельный. Но делать надо изначально нормально, с возможностью простой доработки без переписывания всего и вся.
(0001069)
vdemidov (manager)
23-02-2011 14:10

vasketsov отличная идея. Мне нравится. Привязка к средней или максимальной скорости мне изначально не нравилась. Потому и не спешил реализовывать. А вот такой набор скоростей с парами цветов уже гораздо интереснее и достаточно просто задать в конфиге.
(0002587)
vdemidov (manager)
19-05-2011 05:14

Сделал. Вот только не знаю какие настройки дефолтными взять.

- Users who viewed this issue
User List Anonymous (4200x), vdemidov (1x), hrucker (1x)
Total Views 4202
Last View 18-04-2024 20:27

- Issue History
Date Modified Username Field Change
07-10-2010 18:54 aneox New Issue
08-10-2010 06:33 vdemidov Note Added: 0000287
08-10-2010 06:33 vdemidov Status new => resolved
08-10-2010 06:33 vdemidov Resolution open => no change required
08-10-2010 06:33 vdemidov Assigned To => vdemidov
08-10-2010 09:36 Garl Note Added: 0000292
08-10-2010 11:46 aneox Note Added: 0000293
08-10-2010 11:46 aneox Status resolved => feedback
08-10-2010 11:46 aneox Resolution no change required => reopened
08-10-2010 12:38 vdemidov Note Added: 0000295
08-10-2010 12:38 vdemidov Status feedback => resolved
08-10-2010 12:38 vdemidov Resolution reopened => no change required
08-10-2010 14:59 aneox Note Added: 0000298
08-10-2010 14:59 aneox Status resolved => feedback
08-10-2010 14:59 aneox Resolution no change required => reopened
12-10-2010 08:20 vdemidov Note Added: 0000300
12-10-2010 15:18 Ledmyc Note Added: 0000308
12-10-2010 15:24 Ledmyc Note Edited: 0000308 View Revisions
12-10-2010 16:48 vdemidov Note Added: 0000309
12-10-2010 19:30 Ledmyc Note Added: 0000314
12-10-2010 20:04 Ledmyc Note Edited: 0000314 View Revisions
13-10-2010 05:03 aneox Note Added: 0000315
13-10-2010 05:03 aneox Status feedback => assigned
13-10-2010 05:16 vdemidov Note Added: 0000317
13-10-2010 05:16 vdemidov Assigned To vdemidov =>
13-10-2010 05:16 vdemidov Status assigned => feedback
13-10-2010 20:17 aneox Note Added: 0000332
13-10-2010 20:17 aneox Status feedback => new
13-10-2010 20:22 aneox Note Added: 0000333
13-10-2010 20:22 aneox Note Edited: 0000333 View Revisions
13-10-2010 21:48 Ledmyc Note Added: 0000334
13-10-2010 22:29 Ledmyc Note Edited: 0000334 View Revisions
14-10-2010 06:17 vdemidov Note Added: 0000341
14-10-2010 06:17 vdemidov Assigned To => vdemidov
14-10-2010 06:17 vdemidov Status new => feedback
14-10-2010 10:27 gpsMax Note Added: 0000345
14-10-2010 10:29 vdemidov Summary Новый тип трэков, ни в одной программе не встречал, если это реализовать то будет новая супер фишка планеты. => Новый принцип раскраски трека в зависимости от скорости
14-10-2010 10:58 Ledmyc Note Added: 0000346
14-10-2010 11:33 vdemidov Note Added: 0000347
14-10-2010 12:04 Ledmyc Note Added: 0000348
14-10-2010 12:25 vdemidov Assigned To vdemidov =>
14-10-2010 12:25 vdemidov Status feedback => acknowledged
14-10-2010 12:25 vdemidov Target Version => 110311.Alfa
14-10-2010 17:56 aneox Note Added: 0000352
13-12-2010 12:42 vdemidov Target Version 110311.Alfa => 24xxxx
19-02-2011 20:22 John68 Note Added: 0001024
19-02-2011 21:33 vdemidov Note Added: 0001026
21-02-2011 20:18 Vinil_37 Note Added: 0001034
22-02-2011 09:43 vasketsov Note Added: 0001036
22-02-2011 09:54 aneox Note Added: 0001037
22-02-2011 10:39 vasketsov Note Added: 0001040
22-02-2011 10:45 aneox Note Added: 0001042
22-02-2011 11:21 vasketsov Note Added: 0001043
22-02-2011 11:30 aneox Note Added: 0001044
22-02-2011 11:45 vasketsov Note Added: 0001046
22-02-2011 12:18 vasketsov Note Added: 0001049
23-02-2011 01:33 gpsMax Note Added: 0001052
23-02-2011 13:52 vasketsov Note Added: 0001066
23-02-2011 14:10 vdemidov Note Added: 0001069
11-04-2011 07:09 vdemidov Status acknowledged => confirmed
16-05-2011 05:15 vdemidov Assigned To => vdemidov
16-05-2011 05:15 vdemidov Status confirmed => assigned
16-05-2011 05:16 vdemidov Description Updated View Revisions
16-05-2011 08:25 vdemidov Target Version 24xxxx => 120808
16-05-2011 14:01 gpsMax Tag Attached: пути
16-05-2011 14:01 gpsMax Tag Attached: треки
19-05-2011 05:14 vdemidov Note Added: 0002587
19-05-2011 05:14 vdemidov Status assigned => resolved
19-05-2011 05:14 vdemidov Fixed in Version => 120808
19-05-2011 05:14 vdemidov Resolution reopened => fixed
26-05-2011 07:52 gpsMax Relationship added related to 0000755
10-10-2012 11:52 Tolik Status resolved => closed



Copyright © 2007 - 2024 SAS.Planet Team