HPC.ru lite - Все форумы
Форум: PocketGPS Pro и MacCentre PocketGPS
Тема: подсказки :-(
Страницы: 1 2 3 [4] 5 6 7 8 9
VctOs [07.10.2005 17:23] :
Logout писал(а):
В Европе улицы не прямее московских. Однако я не согласен, что ориентироваться надо по дугам. Скажите, зачем мне слышать все время левее или правее, если я еду по садовому кольцу?
Именно это я и имел ввиду, когда писал об относительности понятия прямо. Почти это, потому что речь шла о МКАД. Боюсь что в Москве найдутся автолюбители, слишком буквально понимающие указание "ехать прямо". Нужно что-то типа "следуйте по главной дороге".
Logout писал(а):
Кстати! Вырисовывается еще один трабл: садовое кольцо как известно состоит из многих улиц, переходящих одна в другую. Пока мне не приходит в голову как это можно обойти.
Особенно в тех местах, в которых есть развилки из который Садовое выходит коричневой дугой.
Logout писал(а):
Потому что при выдаче подсказки он опирается на точку выхода из перекрестка. Из-за того, что точка выхода будет лежать на другом уровне - угол будет неправильный.
Угол по-моему будет неправильным не из-за того, что точки входа и точка выхода лежат на разных уровнях, а потому что используемая модель траектории (отрезок прямой) существенно неадекватна исходной траектории (дуга).
Logout писал(а):
Кстати, Вы так на мое предложение (сентябрьское) и не отреагировали. А было бы интересно знать мнение.
С первого взгляда мне понравилось. Вторым взглядом я взглянуть не написав код не умею.
Logout писал(а):
А было бы интересно знать мнение.
Не понимаю, в чем может быть смысл именно моего мнения?
Критерий истины это практика и ничего кроме.
Все остальное - это досужие домыслы.
Понятно, что нужно искать некий набор правил. Понятно, что особых случаев по мере реализации всплывет немало, поэтому набор правил должен быть модифицируемым, а качество модификаций должно оцениваться автоматизированными методами тестирования. Непонятно какую часть особых случаев можно будет учесть алгоритмически и какая часть проблем будет решаема только методом переработки данных. Нет уверенности относительно незыбленности текущего способа представления данных в графе. Непонятно, достаточно ли входной информации, если не достаточно - какой именно информации не хватает для создания эффективного набора эвристик.
Очень кажется, что стоит отложить текучку хотя бы на месяц-два и за это время можно будет достичь результата выше текущего уровня. Это из серии "в чужих руках работа всегда хорошо спорится".
Понятно, что рано или поздно эту технологию если не в ядро, то в одну из надстроек мне придется добавлять. Очевидно, что сделать это без учета опыта эксплуатации PGPS будет гораздо сложнее.
Дорогу осилит идущий.
VctOs [07.10.2005 17:53] :
BreQwaS писал(а):
Переписывать с нуля нельзя. НЕЛЬЗЯ. Аксиома.
Хорошая статья по этому поводу:
Статья действительно хорошая и в чем то поучительная, но ее главную посылку правильнее называть догмой, а не аксиомой.
У любого программного продукта есть свой жизненный цикл.
LaserMap для MS-DOS был создан на базе кода для управления лазерной технологической установкой. Когда встал вопрос о необходимости разработки версии для WCE код был переписан с нуля за месяц и еще за полмесяца отлажен. На переработку 16-ти битного кода для настольных машин для DOS в 32-х битный код для карманных компьютеров под WCE ушло бы, может быть, 2-3 недели, может быть 2-3 месяца. На отлавливание тараканов в переработанном коде - полгода-год.
Второй раз код был начат практически с нуля когда стало понятно, что MFC это ловушка для торопыг, впрочем как и WIN API. На создание POSIX совместимой версии ядра ушел примерно год, но на создание оболочки к нему сил пока не хватает. Уже пятый год как.
Чайни [08.10.2005 00:42] :
Прочитал.
1) Статья на самом деле - спорная. Ибо кто-то (Нетскейп) попался на этом, а кто-то, возможно, и не попался
Где гарантии, что автор рассмотрел КУЧУ софтверных фирм, переписывающих код с нуля ?
Привести в доказательство лишь некоторые аргументы из тысяч проб - не совсем корректно. Впрочем, это не так важно.
2) Также, не очень важно и то, что в статье речь шла о правильно работающих системах - их переписывать с нуля глупо, согласен, и в этом случае статья - достаточно верная. Но я говорю о системе, которая работает неправильно (не ПГПС, а вообще - теоретизирую). Если так - её можно и переписать. Впрочем, с оговорками из п. 3)
3) Самое важное вот что - я не предлагаю переписать всё:(при этом совершенно не утверждаю, что надо переписывать ВСЁ, ибо наверняка какие-то, а может даже и многие наработки пригодятся)
Итог : ваша аксиома неприменима в данном конкретном случае 
Logout [09.10.2005 02:05] :
VctOs писал(а):
Именно это я и имел ввиду, когда писал об относительности понятия прямо. Почти это, потому что речь шла о МКАД. Боюсь что в Москве найдутся автолюбители, слишком буквально понимающие указание "ехать прямо". Нужно что-то типа "следуйте по главной дороге".
Согласен. По-английски это звучит "follow the road for further instructions". Подсказка "прямо" должна звучать только если главная дорога уходит в сторону, а маршрут проходит _прямо_.
VctOs писал(а):
[quote:95544edc18="Logout"]Потому что при выдаче подсказки он опирается на точку выхода из перекрестка. Из-за того, что точка выхода будет лежать на другом уровне - угол будет неправильный.
Угол по-моему будет неправильным не из-за того, что точки входа и точка выхода лежат на разных уровнях, а потому что используемая модель траектории (отрезок прямой) существенно неадекватна исходной траектории (дуга).
Когда я думал об гипотетическом алгоритме подсказок, я исходил из следующих соображений.
Когда я подъезжаю к перекрестку и я вижу его перед собой, для того, чтобы поехать в нужном направлении, мне нужно всего лишь одно - это точка выхода. То есть на какую дорогу мне нужно выехать. Поэтому то, что предложил я основывается имеено на прямой, соединяющей две точки: точку входа на перекресток (т.е. где нахожусь на данный момент "я") и точка выхода.
На данный момет перекресток представлен ввиде набора ребер графа, связывающие все мозможные точки выхода и выхода, причем зачастую с промежуточными ребрами. Именно эти промежуточные ребра и мешают точно определить направление, куда водителю надо повернуть голову, чтобы он увидел в каком направлении ему надо двигаться.
Однако, это правило будет работать неправильно на развязке, так как если представлять развязку ввиде одного перекрестка, точка выхода (съезд с рампы) может находиться сзади, слева, сверху, где угодно от точки входа, что не позволит водителю понять направление. Этот вопрос решается, конечно, представлением развязки ввиде сложного составного перекрестка. Но мое мнение - что это реализуется проще - путем введения дополнительного признака.
Может быть имеет смысл нарисовать пример для наглядности?
VctOs писал(а):
[quote:95544edc18="Logout"]А было бы интересно знать мнение.
Не понимаю, в чем может быть смысл именно моего мнения?
Критерий истины это практика и ничего кроме.
Все остальное - это досужие домыслы.
В Ваших руках формат данных, весь мыслимый и немыслимый инструментарий для того, чтобы попробовать или хотя бы прикинуть: какая трудоемкость реализации этого. Вы знаете код и архитектуру ядра, а я - нет.
VctOs писал(а):
Очень кажется, что стоит отложить текучку хотя бы на месяц-два и за это время можно будет достичь результата выше текущего уровня. Это из серии "в чужих руках работа всегда хорошо спорится".
Очень конструктивная мысль 
VctOs писал(а):
Понятно, что рано или поздно эту технологию если не в ядро, то в одну из надстроек мне придется добавлять. Очевидно, что сделать это без учета опыта эксплуатации PGPS будет гораздо сложнее.
Я уже высказывал идею о плагинах и (полу)открытом API.
VctOs писал(а):
Дорогу осилит идущий.
No comments. Но вырезать не стал - не смог вырезать настолько актуальную мысль 
gren [10.10.2005 18:20] :
VctOS писал(а):
В чем Вы видите демагогию?
Вы самостоятельно выбрали понравившиеся Вам фрагменты и сочли возможным опубликовать их изображения в конференции. По форме представления информации мне эти фраменты очень понравились, по содержанию - вызвали робкое недопонимание. Я его высказал потому что мне показалось, что Ваш пост адресован не кому-либо персонально, а всем участникам конференции.
демагогию я вижу в том, что тема данной ветки ПОДСКАЗКИ, а Вы углубляетесь и начинаете фантазировать по теме прокладки маршрута, и околовсяческих фазах, частотах дискредитации и т.д.
vctOS писал(а):
Вам виднее чему был посвящен Ваш пост.
есстественно, повторюсь, но он размещен в ветке ПОДСКАЗКИ, и буть эта ветка на нормальном модерируемом форуме, Вас бы давно забанили за отклонение от темы, и ветку почистили бы, оставиви в ней только посты с обсуждением подсказок
Gren писал(а):
Если Вы, как разработчик ядра, не знаете куда пропадают улицы в навигационных системах, это говорит о многом..... Может сбросимся Вам конфой на командировочку в Европу и рентакар с навигацией, чтобы Вы наконец поняли, какой "качественный" продукт мы тут 3 года обсуждаем
vctOS писал(а):
Не знаю. Я многого не знаю и не боюсь в этом признаваться. В командировку не собираюсь тем более за чужой счет. Если в исчезновении улиц в навигационных системах существует какой-то недоходящий до меня сокрытый смысл, не сочтите за труд, объясните мне, извиняюсь за прямоту, без излишней распонтовки, в чем он состоит.
он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе. Например, при масштабе 5км, система вообще рисует линию маршрута без улиц + подсказки
А скольо раз поднималась просьба убрать слой с линиями метро ПГПС Про??? Поездив с большой навигацией действительно понимаешь насколько перегружена карта в ПГПС Про, а это не помогает ориентированию уж точно
vctOS писал(а):
Пожалейте свое пиво и печень людей из команды ПГПС Про.
вот в том то и разница, что ПГПС Про напоминает пиво той самой марки, за качество которого, как и за качество оПГПС Про никто не ответил.....
А за качество приведенной мной в пример нави системы, как и за качество хорошего французского коньяка отвечают конкретно
vctOS писал(а):
Меня более интересует вопрос о том, к чему нужно стремиться.
если бы Вас и команду менеджеров/разработчиков это интересовало, вы бы давно уже перенеля опыт больших нави систем и ТомТом, но это упорно не делается
VctOs [11.10.2005 11:44] :
Logout писал(а):
Когда я думал об гипотетическом алгоритме подсказок, я исходил из следующих соображений.
Когда я подъезжаю к перекрестку и я вижу его перед собой, для того, чтобы поехать в нужном направлении, мне нужно всего лишь одно - это точка выхода. То есть на какую дорогу мне нужно выехать. Поэтому то, что предложил я основывается имеено на прямой, соединяющей две точки: точку входа на перекресток (т.е. где нахожусь на данный момент "я") и точка выхода.
Мысль по ходу. А правильно ли считать, что рампа находится на перекрестке? Многоуровневая развязка - это перекресток?
Logout писал(а):
На данный момет перекресток представлен ввиде набора ребер графа, связывающие все мозможные точки выхода и выхода, причем зачастую с промежуточными ребрами. Именно эти промежуточные ребра и мешают точно определить направление, куда водителю надо повернуть голову, чтобы он увидел в каком направлении ему надо двигаться.
Но по-моему проблема "промежуточных ребер на перекрестах" в первом приближении решена. Обратите внимание на то как рисуется траектория маршрута на перекрестах с лишними ребрами. Есть пользователи которые это трактуют как ошибку, но это не баг а фича.
Logout писал(а):
Однако, это правило будет работать неправильно на развязке, так как если представлять развязку ввиде одного перекрестка, точка выхода (съезд с рампы) может находиться сзади, слева, сверху, где угодно от точки входа, что не позволит водителю понять направление. Этот вопрос решается, конечно, представлением развязки ввиде сложного составного перекрестка.
По моему, формально с точки зрения ПДД выезд на рампу это один перекресток, а выед с рампы на другую автомагистраль - это второй перекресток.
«Перекресток» - место пересечения, примыкания или разветвления дорог на одном уровне, ограниченное воображаемыми линиями, соединяющими соответственно противоположные, наиболее удаленные от центра перекрестка начала закруглений проезжих частей. Не считаются перекрестками выезды с прилегающих территорий.
Logout писал(а):
Но мое мнение - что это реализуется проще - путем введения дополнительного признака.
Может быть имеет смысл нарисовать пример для наглядности?
Мне кажется, я Вас вполне понимаю.
Logout писал(а):
В Ваших руках формат данных, весь мыслимый и немыслимый инструментарий для того, чтобы попробовать
Попробовать на себе результативно можно только если много ездить по разным дорогам. Это не мой случай. Практически реализуемых идей о том как можно устроить массовое тестирование ядра у меня нет.
Logout писал(а):
или хотя бы прикинуть: какая трудоемкость реализации этого. Вы знаете код и архитектуру ядра, а я - нет.
Мой опыт прикидок собственных времязатрат даже по исходно понятным алгоритмам дает погрешность плюс-минус в пять раз. В обсуждаемом случае на начальном этапе непонятно во что это может вылиться. Для сравнения - прореживание лишних дуг на перекрестках это примерно 400 строк исходного кода, на разработку и исправление ошибок ушло в общей сложности примерно 2 недели, на отлавливание ошибок - около двух лет. На сегодня я знаю два места, в которых код работает не так как хотелось бы, но исправить их без потери правильности в других местах не получается.
Logout писал(а):
Я уже высказывал идею о плагинах и (полу)открытом API.
Этот вопрос не мне решать, но по-моему это не тот жанр. PGPS Pro это не конструктор и не самоделка. Все разумные опции должны быть в него вшиты.
VctOs [11.10.2005 13:03] :
gren писал(а):
он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе.
Я знаю что такое генерализация, но тупо не понимаю в чем может быть скрыт потаенный смысл запрета вывода непосредственно примыкающей к проезжаемому перекрестку десятиполосной Б.Тульской при одновременном выводе не имеющего никакого отношения к маневру полутораполосного Холодильного пер.?
Тем более, при таком маневре, при котором именно Б.Тульская прописывается в правой части экрана как цель маневра? (см. исходную формулировку вопроса: Опять же не понимаю, куда в левой половине экрана подевалась ул. Б.Тульская - не самая узкая дорога в этом месте. Зато узенький Холодильный прорисовался вполне успешно.) Зачем мне уезжать из Москвы, чтобы понять причины этого локального противоречия с Вами же сформулированными критериями генерализации? Может быть присутствие Б.Тульской утяжеляет восприятие? Тогда ее отстутствие, вероятно, восприятие облегчает? Тогда почему восприятие не облегчается за счет отказа от рисования М.Тульской, Мытной или Люсиновской ул.? Ведь именно Б.Тульская - это доминирующая на изображенном фрагменте магистраль. Все остальные дороги в этом районе имеют меньшую значимость. Или я действительно чего-то недопонимаю?
gren писал(а):
Например, при масштабе 5км, система вообще рисует линию маршрута без улиц + подсказки
Отличный способ решения проблем с низкой производительностью процессора.
Интересно было бы взглянуть как это выглядит.
Здесь есть картинки того как рисуются маневры в Que. Мне и Ваши картинки понравились, но этот способ прорисовки маневров кажется более прогрессивным. Вы как считаете?
http://www.hpc.ru/pda/board/index.php?t=61711
gren писал(а):
А скольо раз поднималась просьба убрать слой с линиями метро ПГПС Про???
Только не хватайте меня потом за рукав на том, что я отклонился от темы витка. Что не так с линиями местро в версии карты 0506? Я проводил специальный опрос на тему, а не удалить ли совсем линии метро. Мнения (их можно было пересчитать по пальцам одной руки) разделились. В итоге я взял на себя смелость принять половинчатое решение. Прорисовку линий метро оставить, но только на мелких масштабах. На крупных, на которых линии местро рисовались особо жирными линиями их не отображать.
gren писал(а):
Поездив с большой навигацией действительно понимаешь насколько перегружена карта в ПГПС Про, а это не помогает ориентированию уж точно
Вообще все возможные настройки параметров отображения всех объектов местности давно вынесены в интерфейс ядра. Поэтому нет непреодолимого препятствия, чтобы так же как это было реализовано в LaserMap 1.х - 2.х обеспечить "рюшечки" в виде возможности выбора шаблона отображения (день - ночь, детальнее - схематичнее, буквы крупнее-мельче) или диалога настройки параметров отображения.
gren писал(а):
А за качество приведенной мной в пример нави системы, как и за качество хорошего французского коньяка отвечают конкретно
Что такое "отвечают конкретно"?
Вы в этом витке привели три картинки. По качеству подсказок на каждой из них есть вопросы. Первая ложная подсказка связана с неверной прокладкой маршрута, поэтому вопрос о том, а правильна ли она Вы считаете демагогическим. На второй разворот рисуется как поворот налево на 135 градусов. Вероятно, вопрос "Что значит буква M в конце "TUL'SKAYA B. UL., M"? " Вам также показался демагогическим. Третью выбранную Вами подсказку по моему правильнее было бы именовать шарадой, но это Вас нисколько не смущает.
У Вас машина какого года выпуска? Если начала 2000-х, к бортовой навигации должен быть приложен диск в картонной коробочке "Digital road map for the BMW Navigation System...". Кроме диска в этой же коробочке должна быть белая брошюрка "END USER LICENSE AGREEMENT". Откройте ее и прочитайте раздел "LIMITED WARRANTY". Почитайте в нем, насколько конкретно они отвечают за качество.
gren писал(а):
если бы Вас и команду менеджеров/разработчиков это интересовало, вы бы давно уже перенеля опыт больших нави систем и ТомТом, но это упорно не делается
Разумеется, Вам виднее, что меня интересует, а что не интересует.
Logout [11.10.2005 16:22] :
VctOs писал(а):
Мысль по ходу. А правильно ли считать, что рампа находится на перекрестке? Многоуровневая развязка - это перекресток?
По моему, формально с точки зрения ПДД выезд на рампу это один перекресток, а выед с рампы на другую автомагистраль - это второй перекресток.
Совершенно верно, рампа - это не перекресток и в-принципе - это нечто большее. У рампы есть два перекрестка - один на входе, один на выходе.
VctOs писал(а):
Но по-моему проблема "промежуточных ребер на перекрестах" в первом приближении решена. Обратите внимание на то как рисуется траектория маршрута на перекрестах с лишними ребрами. Есть пользователи которые это трактуют как ошибку, но это не баг а фича.
Однако, рисуется не всегда так как нужно 
VctOs писал(а):
[quote:5b2d4b7389="Logout"]В Ваших руках формат данных, весь мыслимый и немыслимый инструментарий для того, чтобы попробовать
Попробовать на себе результативно можно только если много ездить по разным дорогам. Это не мой случай. Практически реализуемых идей о том как можно устроить массовое тестирование ядра у меня нет.
Вариант созданием тестовой тулзы не рассматривали? Можно было бы написать тулзу (для PC), с некоторым набором перекрестков (а лучше если их можно было бы "выдирать" из карты PGPSPro). Люди могли бы выбрать перекресток и "смоделировать" проезд и любой точки в любую. Как правило, сложные перекрестки - они все известны и бОльшая часть читателей этого форума проезжают их постоянно и имеют представление в голове.
Вот Вам несколько бесплатных тестировщиков. Такие люди найдутся.
Хотя, это опять же не к Вам, а к разработчикам PGPSPro. Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.
VctOs писал(а):
[quote:5b2d4b7389="Logout"]или хотя бы прикинуть: какая трудоемкость реализации этого. Вы знаете код и архитектуру ядра, а я - нет.
Мой опыт прикидок собственных времязатрат даже по исходно понятным алгоритмам дает погрешность плюс-минус в пять раз. В обсуждаемом случае на начальном этапе непонятно во что это может вылиться. Для сравнения - прореживание лишних дуг на перекрестках это примерно 400 строк исходного кода, на разработку и исправление ошибок ушло в общей сложности примерно 2 недели, на отлавливание ошибок - около двух лет. На сегодня я знаю два места, в которых код работает не так как хотелось бы, но исправить их без потери правильности в других местах не получается.
Это означает, что этим не надо заниматься в-принципе?
VctOs писал(а):
[quote:5b2d4b7389="Logout"]Я уже высказывал идею о плагинах и (полу)открытом API.
Этот вопрос не мне решать, но по-моему это не тот жанр. PGPS Pro это не конструктор и не самоделка. Все разумные опции должны быть в него вшиты.
Мне, например, не нравятся некоторые элементы программы. И с моей точки зрения они должны выглядеть совершенно по-другому.
Logout [11.10.2005 16:26] :
VctOs писал(а):
[quote:3966de7d5d="gren"]он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе.
Я знаю что такое генерализация, но тупо не понимаю в чем может быть скрыт потаенный смысл запрета вывода непосредственно примыкающей к проезжаемому перекрестку десятиполосной Б.Тульской при одновременном выводе не имеющего никакого отношения к маневру полутораполосного Холодильного пер.?
Кстати, тот же ТомТом или тот же Автороут, или тот же MapSource от Гармина поддерживает реглировку уровня детализации.
Чайни [11.10.2005 20:07] :
Logout писал(а):
Вот Вам несколько бесплатных тестировщиков. Такие люди найдутся.
Хотя, это опять же не к Вам, а к разработчикам PGPSPro. Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.
Да кому же охота заплатив деньги за готовую систему бесплатно помогать её писать ? 
Причём, при условии, что разработчики либо никак не проявляют интереса к этому процессу (помощи в создании нормальной системы), либо вообще занимают позицию "тут нет ошибок, тут только фичи" 
Вот поэтому вокруг интерфейса всё и вертится 
[Тема закрыта модератором]
[< Назад] [Вперед >]