HPC.ru lite - Все форумы
Форум: PocketGPS Pro и MacCentre PocketGPS
Тема: несколько пожеланий в будущую версию
Страницы: 1 2 3 4 [5]

[Ответить]
adanilov [29.11.2005 11:06] :
Не знаю о чем она радовалась, но когда я ехал, сказала – «поворот налево»…..
Антон Губарьков [29.11.2005 11:51] :
Графы имеют рёбра разной длины, соотетственно для объективности оценки пробки необходимо разбивать дугу на несколько частей (в Вашей второй цитате, насколько я понял, это и предлагается) ? Но, позвольте, именно это сейчас и сделано : на практически прямом участке ни с того ни с сего - подсказка "возьмите левее" , потому что все рёбра разбиты вот на такие участки, о конечной цели которых можно только догадываться (просто, видимо, так программисту удобней реализовать "чисто математическую" модель и построить алгоритм прокладки маршрута с учётом "веса" рёбер ? Иного смысла я в этом не вижу).
Скорость - по сути сильно (мягко говоря ) связана со временем, но алгоритм обработки пробки при учитывании именно скорости намного "приземлённей", т.е. ближе к логике конечного потребителя - водителя, который пользуется системой сопровождения, а не "системой расчёта траектории по математической модели". Соответственно, алгоритм должен быть таким, чтобы конечная цель - грамотное "ведение" по маршруту - была реализована с минимальными заморочками по поиску обходных путей "особенностей" алгоритма прокладки маршрута (а по сути - безграмотным подходом к задаче в целом) для правильной выдачи подсказок. То, как это сделано сейчас - именно поиск таких путей, усложняющий как саму программу, так и пользование ей.
Если бы программисты (или руководители) это изначально понимали, ПГПС не была бы на сегодня такой, простите, убогой (речь именно о сопровождении, т.е. о её главной функции. В остальном же, в "бантиках", она совсем не плоха).

Я не математик как Вы, и не теоретик, а системотехник. Так вот, когда речь идёт о проектировании компьютерной системы и собственно постановке задачи, математическая модель будущей системы делается не "чиста теоретически", а с учётом необходимых и конкретных требований к системе со стороны пользователя. Алгоритм системы строится не на научных теоретических изысканиях, а на основании логики построения системы в том виде, в котором она должна работать. Ибо если задача "теоретически" решена безукоризненно в плане реализации её математической модели, а не самой задачи, то далеко не факт, что конечным продуктом сможет кто-то воспользоваться

Уважаемый Чайни.
Вы много написали правильных слов, но я хотел бы сделать один комментарий.
Я купил эту программу (как пользователь, а не математик) для одной цели - быстрее (или другими словами за меньшее время) добраться из пункта А в пункт Б.
Мне до лампы скорость на маршруте. Мне важно, чтобы общее время в пути было минимально. Я думаю, что большинство пользователей со мной согласится.

Поэтому время - это главное.
Далее, если сходить сюда http://update.digimap.ru/pgpsp/readme.html, то в пп. 2 можно увидеть:

. mskmoXXXX.lmg* -- база данных, содержащая информацию о времени перемещения по участкам улично-дорожной сети Москвы и Московской области;

Так что разработчики карты, похоже, используют именно этот подход.
Alligator. [29.11.2005 16:27] :
Не знаю о чем она радовалась, но когда я ехал, сказала – «поворот налево»…..

поставь галочку "только развилки"
без этой галочки подсказки выдаются крайне бестолково - по крутизне изгиба
с этой галочкой (при ползунке установленном на большое количество промежуточных точек) будет подсказка "правее" при съезде с ТТК на мост ...

хотя безусловно, качество генерации подсказок оставляет желать лучшего и это неоднократно обсуждалось ...
Чайни [30.11.2005 02:10] :
Уважаемый Антон, там не только слова
Но, по порядку...

Тогда давайте как пользователи говорить А то не поймёшь - Вы рассуждаете то как математик, то как пользователь
И как пользователь, и как программист скажу, что цель-то одинаковая должна быть у обоих (пользователя и программиста) Иначе - это будет ПГПС в нынешнем её виде

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

...поэтому это не наше с Вами дело (мы же говорим как пользователи ?)
См. выше

Опять-таки, организация хранения данных и их внутреннее преобразование - не забота пользователей.
Но как программист скажу, что задача преобразования времени движения в скорость движения для любого выпускника школы - не большая проблема

Они используют такой подход, который им удобней. Программисты должны уметь преобразовывать данные для того, чтобы программа не зависела от того, какой пяткой картографы занесут в файл исходные данные. Конечный продукт, как Вы правильно заметили - для потребителя, а не для картографов и не для математиков.

Ну и ещё... в целом о проблеме. Передавать с КПК в СМИлинк данные о времени прохождения улицы можно только после прохождения этой несчастной улицы !
Не видите подвоха ?
Антон Губарьков [30.11.2005 07:56] Своевременность подсказок:
Заметил, что положение на карте и соответственно подсказки по маршруту выдаются с задержкой около 1 сек. ( в лучшем случае).
похоже, это связано с работой самого gps приемника, но от этого не легче. пропустить поворот очень просто.

Для улучшения ситуации предлагаю использовать расширенный фильтр Кальмана для оценки текущих координат, скорости и ускорения. Подробности здесь: http://www.cs.unc.edu/~welch/kalman/

Кратко: это позволит не зависеть от временных проблем с gps приемом, увеличить точность и частоту определения координат и самое главное позволит выдавать подсказки вовремя, а не привязывать их к очередному обновлению координат из gps приемника. А если ещё и учитывать проложенный маршрут в prediction model фильтра в качестве control input - это будет просто замечательно.

Очень хотелось бы услышать мнение разработчиков по этому вопросу. Кстати, некоторые функции фильтра уже написаны и доступны на http://sourceforge.net/projects/opencvlibrary/
adanilov [01.12.2005 19:03] :
Есть еще пожелание:
Сделать возможность поиска объектов не только в радиусе 10 – 2400 м, но и во всей базе. А то иногда знаешь название учреждения , а адрес не знаешь – тяжеловато найти….
[Ответить]
[< Назад]