|
Notes |
|
|
|
|
Давно уже цвет отображаемого GPS трека зависит от скорости. Цвет показывает как соотносится скорость в точке с максимальной скоростью |
|
|
|
(0000292)
|
|
Garl
|
|
08-10-2010 09:36
|
|
|
а подгружать и отображать эти трэки после перезапуска программы можно? |
|
|
|
(0000293)
|
|
aneox
|
|
08-10-2010 11:46
|
|
|
сейчас в планете 2 цвета трека, я предлагаю 4 |
|
|
|
|
|
Сейчас не два цвета, а 100 градаций от синего к красному в зависимости от соотношения скорости в точке к максимальной скорости. |
|
|
|
(0000298)
|
|
aneox
|
|
08-10-2010 14:59
|
|
|
сейчас градация 2 цветов, а я прошу о 4, пока можно сделать без сохранения, раз уж там всю систему меток переделывать |
|
|
|
|
|
Приведите пример формулы определения цвета. Например есть данные о средней скорости, максимальной, и текущей скорости. Напишите как вы представляете алгоритм выбора цвета для отрисовки участка трека, потому что я не представляю. |
|
|
|
(0000308)
|
|
Ledmyc
|
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 км/ч.
|
|
|
|
|
|
Вот и придумывайте как лучше сделать, не забывая, что люди не только на машинах ездят, но и ходят пешком, а так же летают на самолетах. |
|
|
|
(0000314)
|
|
Ledmyc
|
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
|
|
13-10-2010 05:03
|
|
|
ну нужно попробовать реализовать это на практике, позадовать разные параметры скоростей и посмотреть переходы на прямой линии, попробую, но щяс времени в обрез |
|
|
|
|
|
Ну последний вариант формулы уже на что-то похож, но нужно проверять переходы в крайних точках что бы функция цвета была непрерывной. |
|
|
|
(0000332)
|
|
aneox
|
|
13-10-2010 20:17
|
|
когда текущая равна или почти равна средней, переход очень резкий и
в строке
Ц = округлить (255*ТЕК/НИЖ)
когда средний очень мал то ниж = 0, а на ноль не делит |
|
|
|
(0000333)
|
|
aneox
|
|
13-10-2010 20:22
|
|
если тек <= сред то глюки страшные с цветом, буду разбираться, выше среднего отображает красиво
|
|
|
|
(0000334)
|
|
Ledmyc
|
13-10-2010 21:48
(edited on: 13-10-2010 22:29) |
|
>если тек <= сред то глюки страшные с цветом
Возможно, используете беззнаковый числовой тип данных. Тогда достаточно поменять местами операнды обеих разностей: Ц = округлить (255*(СРЕД-ТЕК)/(СРЕД-НИЖ))
>когда средний очень мал то ниж = 0
Вы используете целочисленный тип данных вместо вещественного (где «доделиться» до нуля практически невозможно). Я прав?
Набросал слегка в Excel'е: http://narod.ru/disk/26079151000/SpeedColor.xls.html
|
|
|
|
|
|
Не. Слишком резкие переходы. Функция цвета должна быть непрерывной. То есть, если у нас ТЕК = НИЖ - delta и если ТЕК = НИЖ + delta, цвет должен получаться почти одинаковый. То же самое для точки ТЕК = СРЕД. Так что думайте пока. |
|
|
|
(0000345)
|
|
gpsMax
|
|
14-10-2010 10:27
|
|
|
А можно поставить более нейтральный и информативный заголовок? |
|
|
|
(0000346)
|
|
Ledmyc
|
|
14-10-2010 10:58
|
|
>Не. Слишком резкие переходы.
Это потому что и скорость так резко не может меняться. Немножко переделал xls-файл: скорость теперь задаётся функцией, можно менять коэффициенты и шаг времени.
http://narod.ru/disk/26087402000/SpeedColor.xls.html |
|
|
|
|
|
Выпишите отдельно окончательный алгоритм вычисления RGB для заданных текущей, средней и максимальной скорости и можно реализовывать. |
|
|
|
(0000348)
|
|
Ledmyc
|
|
14-10-2010 12:04
|
|
Так он же выписан (я ничего не менял):
http://sasgis.org/mantis/view.php?id=142#c314
Единственная рекомендация: округлять лучше не просто отбрасывая дробную часть, а именно до ближайшего целого. |
|
|
|
(0000352)
|
|
aneox
|
|
14-10-2010 17:56
|
|
|
и не забудьте что нужно брать не просто среднюю скорость а среднюю скорость в движении |
|
|
|
(0001024)
|
|
John68
|
|
19-02-2011 20:22
|
|
Хотел бы поделиться своими соображениями по этому вопросу.
Сейчас в программе реализован алгоритм раскраски трека в зависимости от скорости движения ПРИ ЗАПИСИ этого трека, т.е. во время движения. Функция бесспорно нужная! НО стоит сохранить трек в базе, как вся полезность этого алгоритма попросту теряется. Так как при импорте этого же или любого другого трека, например с навигатора, скажем, для анализа пройденного пути или выявления проблемных мест на маршруте, программа предлагает выбрать самому из предложенной палитры и он отображается ОДНИМ единым цветом.
На мой взгляд, было бы гораздо полезнее для пользователей SAS.Planet все это с точностью до наоборот. То есть, записываемый во время движения трек сделать сплошным цветом (ведь он просто фиксирует пройденный путь), а вот при импорте трека из базы сделать его в цвете. Тогда уже можно будет, как уже писалось выше:"можно заранее установить скорость передвижения на участке, иметь представление о скоростных и опасных участках..."
И второе. Думаю, было бы гораздо логичнее, если минимальная скорость была красной (традиционный цвет опасности),а max - зеленой. |
|
|
|
|
|
Увы, сейчас для меток-путей не предусмотрено наличие сохраненной скорости в каждой из точек. Так что пока раскраска возможна только для активного трека. |
|
|
|
|
|
А можно сделать цвет низхкой скорости не чёрый, а то он совсем какой-то незаметный на спутниковых снимках. |
|
|
|
|
>придется создать новый формат файлов трэков
А это ещё зачем? Это вопрос не данных, а исключительно их отображения, лишь бы в треке была информация о скорости.
>гораздо логичнее, если минимальная скорость была красной (традиционный цвет опасности),а max - зеленой
Вообще-то "тише едешь - дальше будешь", а никак не наоборот. Чем выше скорость, тем по вашей логике больше опасность. Так что максимальная красная как раз логично. |
|
|
|
(0001037)
|
|
aneox
|
|
22-02-2011 09:54
|
|
>А это ещё зачем? Это вопрос не данных, а исключительно их отображения, лишь бы в треке была информация о скорости.
Я имел ввиду для последующей загрузки из файла такого трека. Либо оставить plt но к нему какойнить *.cplt приделать, типо как *.map для озика |
|
|
|
|
>к нему какойнить *.cplt приделать
зачем? что там будет?
палитра и вообще отображение и всякая раскраска - вопрос предпочтений пользователя, который смотрит на трек, а вовсе не настройка трека и даже не вопрос предпочтений автора трека. даже на сколько частей делить диапазон скоростей, и то дискуссионно. в конце концов ведь и дальтоники есть, и люди с прочими нарушениями зрения. Кроме того, в зависимости от монитора, освещения, режима, могут быть разные оптимальные настройки отображения для конкретного момента времени, и требовать перезагрузки трека в программу для изменения его отображения совершенно некошерно.
Так что треку, что бы под этим не понималось, должно быть глубоко фиолетово, что его кто-то где-то как-то собрался раскрашивать. |
|
|
|
(0001042)
|
|
aneox
|
|
22-02-2011 10:45
|
|
|
фиолетово то да, но где же тогда будут храниться данные о скорости в конкретной точки трека |
|
|
|
|
в самом треке и будут храниться, там кроме координат ещё и высоты, глубины, скорости и много чего другого можно хранить. берём трек, открывает его где-нить типа GPSMapEdit и смотрим, что там есть.
а вообще, забавная идея хранить скорости рядом с треком, предлагаете полностью дублировать точки трека в файле со скоростями? |
|
|
|
(0001044)
|
|
aneox
|
|
22-02-2011 11:30
|
|
|
я просто особо в этом не силен. Ну раз стандартный формат файла трека может хранить в себе данные о скорости, в чем же тогда загвоздка у нашего многоуважаемого автора планеты с загрузкой цветных треков. Я полагал что формат не позволяет. |
|
|
|
|
1. В треке может быть информация о скоростях, а может её и не быть.
2. На gpslib.ru есть раскраска треков цветами и соответствующая аналитика, можно поглядеть для ознакомления. А можно и свой трек туда запулить и поглядеть как раскрасится. Там есть несколько моих треков из разных источников, можно найти по логину, они точно не "огрублённые", вся инфа типа скорости там есть. |
|
|
|
|
>цветRGB (0, 255-Ц, Ц)
Подобные формулы имеют как минимум два существенных недостатка.
1. При всей плавности перехода между цветами, переходы через 20, 60, 90, 110 км/ч должны выделяться, например, переходом в другую цветовую гамму. Потому как это важные признаки, фактически это изменение режима движения, качества покрытия, загруженности дороги и т.п. А наглядность отображения (предоставления информации) всё же важнее некой плавности градиентного перехода, которая сама по себе не является самоцелью. Не нужно стараться загнать весь диапазон скоростей в один градиентный переход в рамках какой-то конкретной палитры. В идеале глядя на трек, глаз должен сразу получать информацию о существенных изменениях в режиме движения, а не выискивать, где почти-что-сильно-красный сменился на чуть-менее-сильно-красный.
2. Этот недостаток ещё более критичен. Если все скорости на треке увеличить или уменьшить в одинаковое число раз, раскраска его не изменится. Это делает невозможным а) визуальный анализ множества треков одновременно и б) анализ трека без дополнительной информации о исходных параметрах-скоростях. |
|
|
|
(0001052)
|
|
gpsMax
|
|
23-02-2011 01:33
|
|
> переходы через 20, 60, 90, 110 км/ч должны выделяться
Во-первых, не должны они резко выделяться, о чём говорилось выше. Плавное перетекание цветов смотрится куда лучше. Во-вторых, значения скоростей и цвета очень хорошо задавать бы руками. |
|
|
|
|
>не должны они резко выделяться, о чём говорилось выше
Обоснование было? Вы вообще в курсе, зачем используется высококонтрастный интерфейс? Ничего никому не должно, это всё исключительно предпочтения пользователя. Вы не поверите, но это даже от вычислительной мощности, от монитора, от освещения, от времени суток, от используемой подложки (сервиса снимков или карт) зависит, и много ещё от чего. Никогда не задумывались, тесты у окулистов проходят рано утром, утром при дневном свете или вечером перед сном, и почему? В общем, не надо за пользователя додумывать то, что пользователь знает всяко лучше. Тем более если алгоритм не зависит от подобных ненужных допущений.
Кроме того, у меня возникает мысль, что Вы либо не внимательны, либо не понимаете, как стыкуются палитры в случае перехода от одной к другой. Иначе бы слово "резко" в процитированном мной ответе не присутствовало. Впрочем, не только Вы не понимаете, судя по этой теме.
Объясняю алгоритм популярно:
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 всё равно один сплошной цвет.
>значения скоростей и цвета очень хорошо задавать бы руками
Безусловно всё руками должно быть. Даже в разных странах разные ограничения скоростного режима. Да и самолёты с моторками и байдарками по-разному передвигаются, и статистика по скоростям будет разная. Надо ли пытаться по загружаемому треку (запуская некий эвристический анализатор) понять, что это за трек, кто так ехал и на чём (и как следствие - выбор параметров алгоритма раскраски, в том числе несколько активных алгоритмов раскраски одновременно для разных треков) - вопрос открытый, и что куда более важно - отдельный. Но делать надо изначально нормально, с возможностью простой доработки без переписывания всего и вся. |
|
|
|
|
|
vasketsov отличная идея. Мне нравится. Привязка к средней или максимальной скорости мне изначально не нравилась. Потому и не спешил реализовывать. А вот такой набор скоростей с парами цветов уже гораздо интереснее и достаточно просто задать в конфиге. |
|
|
|
|
|
Сделал. Вот только не знаю какие настройки дефолтными взять. |
|