подсказки :-(

[VctOs]

В Европе улицы не прямее московских. Однако я не согласен, что ориентироваться надо по дугам. Скажите, зачем мне слышать все время левее или правее, если я еду по садовому кольцу?

Именно это я и имел ввиду, когда писал об относительности понятия прямо. Почти это, потому что речь шла о МКАД. Боюсь что в Москве найдутся автолюбители, слишком буквально понимающие указание "ехать прямо". Нужно что-то типа "следуйте по главной дороге".

Кстати! Вырисовывается еще один трабл: садовое кольцо как известно состоит из многих улиц, переходящих одна в другую. Пока мне не приходит в голову как это можно обойти.

Особенно в тех местах, в которых есть развилки из который Садовое выходит коричневой дугой.

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

Угол по-моему будет неправильным не из-за того, что точки входа и точка выхода лежат на разных уровнях, а потому что используемая модель траектории (отрезок прямой) существенно неадекватна исходной траектории (дуга).

Кстати, Вы так на мое предложение (сентябрьское) и не отреагировали. А было бы интересно знать мнение.

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

А было бы интересно знать мнение.

Не понимаю, в чем может быть смысл именно моего мнения?
Критерий истины это практика и ничего кроме.
Все остальное - это досужие домыслы.
Понятно, что нужно искать некий набор правил. Понятно, что особых случаев по мере реализации всплывет немало, поэтому набор правил должен быть модифицируемым, а качество модификаций должно оцениваться автоматизированными методами тестирования. Непонятно какую часть особых случаев можно будет учесть алгоритмически и какая часть проблем будет решаема только методом переработки данных. Нет уверенности относительно незыбленности текущего способа представления данных в графе. Непонятно, достаточно ли входной информации, если не достаточно - какой именно информации не хватает для создания эффективного набора эвристик.
Очень кажется, что стоит отложить текучку хотя бы на месяц-два и за это время можно будет достичь результата выше текущего уровня. Это из серии "в чужих руках работа всегда хорошо спорится".
Понятно, что рано или поздно эту технологию если не в ядро, то в одну из надстроек мне придется добавлять. Очевидно, что сделать это без учета опыта эксплуатации PGPS будет гораздо сложнее.
Дорогу осилит идущий.

[VctOs]

Переписывать с нуля нельзя. НЕЛЬЗЯ. Аксиома.
Хорошая статья по этому поводу:

Статья действительно хорошая и в чем то поучительная, но ее главную посылку правильнее называть догмой, а не аксиомой.
У любого программного продукта есть свой жизненный цикл.
LaserMap для MS-DOS был создан на базе кода для управления лазерной технологической установкой. Когда встал вопрос о необходимости разработки версии для WCE код был переписан с нуля за месяц и еще за полмесяца отлажен. На переработку 16-ти битного кода для настольных машин для DOS в 32-х битный код для карманных компьютеров под WCE ушло бы, может быть, 2-3 недели, может быть 2-3 месяца. На отлавливание тараканов в переработанном коде - полгода-год.

Второй раз код был начат практически с нуля когда стало понятно, что MFC это ловушка для торопыг, впрочем как и WIN API. На создание POSIX совместимой версии ядра ушел примерно год, но на создание оболочки к нему сил пока не хватает. Уже пятый год как.

[Чайни]

Переписывать с нуля нельзя. НЕЛЬЗЯ. Аксиома.
Хорошая статья по этому поводу: http://joelonsoftware.com/articles/fog0000000069.html
Мой перевод (всё не соберусь довести до ума и выложить): http://rsdn.ru/Forum/Message.aspx?mid=1375257&only=1

Прочитал.
1) Статья на самом деле - спорная. Ибо кто-то (Нетскейп) попался на этом, а кто-то, возможно, и не попался Где гарантии, что автор рассмотрел КУЧУ софтверных фирм, переписывающих код с нуля ? Привести в доказательство лишь некоторые аргументы из тысяч проб - не совсем корректно. Впрочем, это не так важно.
2) Также, не очень важно и то, что в статье речь шла о правильно работающих системах - их переписывать с нуля глупо, согласен, и в этом случае статья - достаточно верная. Но я говорю о системе, которая работает неправильно (не ПГПС, а вообще - теоретизирую). Если так - её можно и переписать. Впрочем, с оговорками из п. 3)
3) Самое важное вот что - я не предлагаю переписать всё:

(при этом совершенно не утверждаю, что надо переписывать ВСЁ, ибо наверняка какие-то, а может даже и многие наработки пригодятся)

Итог : ваша аксиома неприменима в данном конкретном случае

[Logout]

Именно это я и имел ввиду, когда писал об относительности понятия прямо. Почти это, потому что речь шла о МКАД. Боюсь что в Москве найдутся автолюбители, слишком буквально понимающие указание "ехать прямо". Нужно что-то типа "следуйте по главной дороге".

Согласен. По-английски это звучит "follow the road for further instructions". Подсказка "прямо" должна звучать только если главная дорога уходит в сторону, а маршрут проходит _прямо_.

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

Угол по-моему будет неправильным не из-за того, что точки входа и точка выхода лежат на разных уровнях, а потому что используемая модель траектории (отрезок прямой) существенно неадекватна исходной траектории (дуга).

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

Может быть имеет смысл нарисовать пример для наглядности?

А было бы интересно знать мнение.

Не понимаю, в чем может быть смысл именно моего мнения?
Критерий истины это практика и ничего кроме.
Все остальное - это досужие домыслы.

В Ваших руках формат данных, весь мыслимый и немыслимый инструментарий для того, чтобы попробовать или хотя бы прикинуть: какая трудоемкость реализации этого. Вы знаете код и архитектуру ядра, а я - нет.

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

Очень конструктивная мысль

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

Я уже высказывал идею о плагинах и (полу)открытом API.

Дорогу осилит идущий.

No comments. Но вырезать не стал - не смог вырезать настолько актуальную мысль

[gren]

В чем Вы видите демагогию?
Вы самостоятельно выбрали понравившиеся Вам фрагменты и сочли возможным опубликовать их изображения в конференции. По форме представления информации мне эти фраменты очень понравились, по содержанию - вызвали робкое недопонимание. Я его высказал потому что мне показалось, что Ваш пост адресован не кому-либо персонально, а всем участникам конференции.

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

Вам виднее чему был посвящен Ваш пост.

есстественно, повторюсь, но он размещен в ветке ПОДСКАЗКИ, и буть эта ветка на нормальном модерируемом форуме, Вас бы давно забанили за отклонение от темы, и ветку почистили бы, оставиви в ней только посты с обсуждением подсказок

Если Вы, как разработчик ядра, не знаете куда пропадают улицы в навигационных системах, это говорит о многом..... Может сбросимся Вам конфой на командировочку в Европу и рентакар с навигацией, чтобы Вы наконец поняли, какой "качественный" продукт мы тут 3 года обсуждаем

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

он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе. Например, при масштабе 5км, система вообще рисует линию маршрута без улиц + подсказки
А скольо раз поднималась просьба убрать слой с линиями метро ПГПС Про??? Поездив с большой навигацией действительно понимаешь насколько перегружена карта в ПГПС Про, а это не помогает ориентированию уж точно

Пожалейте свое пиво и печень людей из команды ПГПС Про.

вот в том то и разница, что ПГПС Про напоминает пиво той самой марки, за качество которого, как и за качество оПГПС Про никто не ответил.....

А за качество приведенной мной в пример нави системы, как и за качество хорошего французского коньяка отвечают конкретно

Меня более интересует вопрос о том, к чему нужно стремиться.

если бы Вас и команду менеджеров/разработчиков это интересовало, вы бы давно уже перенеля опыт больших нави систем и ТомТом, но это упорно не делается

[VctOs]

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

Мысль по ходу. А правильно ли считать, что рампа находится на перекрестке? Многоуровневая развязка - это перекресток?

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

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

Однако, это правило будет работать неправильно на развязке, так как если представлять развязку ввиде одного перекрестка, точка выхода (съезд с рампы) может находиться сзади, слева, сверху, где угодно от точки входа, что не позволит водителю понять направление. Этот вопрос решается, конечно, представлением развязки ввиде сложного составного перекрестка.

По моему, формально с точки зрения ПДД выезд на рампу это один перекресток, а выед с рампы на другую автомагистраль - это второй перекресток.

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

Но мое мнение - что это реализуется проще - путем введения дополнительного признака.
Может быть имеет смысл нарисовать пример для наглядности?

Мне кажется, я Вас вполне понимаю.

В Ваших руках формат данных, весь мыслимый и немыслимый инструментарий для того, чтобы попробовать

Попробовать на себе результативно можно только если много ездить по разным дорогам. Это не мой случай. Практически реализуемых идей о том как можно устроить массовое тестирование ядра у меня нет.

или хотя бы прикинуть: какая трудоемкость реализации этого. Вы знаете код и архитектуру ядра, а я - нет.

Мой опыт прикидок собственных времязатрат даже по исходно понятным алгоритмам дает погрешность плюс-минус в пять раз. В обсуждаемом случае на начальном этапе непонятно во что это может вылиться. Для сравнения - прореживание лишних дуг на перекрестках это примерно 400 строк исходного кода, на разработку и исправление ошибок ушло в общей сложности примерно 2 недели, на отлавливание ошибок - около двух лет. На сегодня я знаю два места, в которых код работает не так как хотелось бы, но исправить их без потери правильности в других местах не получается.

Я уже высказывал идею о плагинах и (полу)открытом API.

Этот вопрос не мне решать, но по-моему это не тот жанр. PGPS Pro это не конструктор и не самоделка. Все разумные опции должны быть в него вшиты.

[VctOs]

он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе.

Я знаю что такое генерализация, но тупо не понимаю в чем может быть скрыт потаенный смысл запрета вывода непосредственно примыкающей к проезжаемому перекрестку десятиполосной Б.Тульской при одновременном выводе не имеющего никакого отношения к маневру полутораполосного Холодильного пер.?
Тем более, при таком маневре, при котором именно Б.Тульская прописывается в правой части экрана как цель маневра? (см. исходную формулировку вопроса: Опять же не понимаю, куда в левой половине экрана подевалась ул. Б.Тульская - не самая узкая дорога в этом месте. Зато узенький Холодильный прорисовался вполне успешно.) Зачем мне уезжать из Москвы, чтобы понять причины этого локального противоречия с Вами же сформулированными критериями генерализации? Может быть присутствие Б.Тульской утяжеляет восприятие? Тогда ее отстутствие, вероятно, восприятие облегчает? Тогда почему восприятие не облегчается за счет отказа от рисования М.Тульской, Мытной или Люсиновской ул.? Ведь именно Б.Тульская - это доминирующая на изображенном фрагменте магистраль. Все остальные дороги в этом районе имеют меньшую значимость. Или я действительно чего-то недопонимаю?

Например, при масштабе 5км, система вообще рисует линию маршрута без улиц + подсказки

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

Здесь есть картинки того как рисуются маневры в Que. Мне и Ваши картинки понравились, но этот способ прорисовки маневров кажется более прогрессивным. Вы как считаете?
http://www.pocketgps.ru/board/viewtopic.php?t=61711

А скольо раз поднималась просьба убрать слой с линиями метро ПГПС Про???

Только не хватайте меня потом за рукав на том, что я отклонился от темы витка. Что не так с линиями местро в версии карты 0506? Я проводил специальный опрос на тему, а не удалить ли совсем линии метро. Мнения (их можно было пересчитать по пальцам одной руки) разделились. В итоге я взял на себя смелость принять половинчатое решение. Прорисовку линий метро оставить, но только на мелких масштабах. На крупных, на которых линии местро рисовались особо жирными линиями их не отображать.

Поездив с большой навигацией действительно понимаешь насколько перегружена карта в ПГПС Про, а это не помогает ориентированию уж точно

Вообще все возможные настройки параметров отображения всех объектов местности давно вынесены в интерфейс ядра. Поэтому нет непреодолимого препятствия, чтобы так же как это было реализовано в LaserMap 1.х - 2.х обеспечить "рюшечки" в виде возможности выбора шаблона отображения (день - ночь, детальнее - схематичнее, буквы крупнее-мельче) или диалога настройки параметров отображения.

А за качество приведенной мной в пример нави системы, как и за качество хорошего французского коньяка отвечают конкретно

Что такое "отвечают конкретно"?
Вы в этом витке привели три картинки. По качеству подсказок на каждой из них есть вопросы. Первая ложная подсказка связана с неверной прокладкой маршрута, поэтому вопрос о том, а правильна ли она Вы считаете демагогическим. На второй разворот рисуется как поворот налево на 135 градусов. Вероятно, вопрос "Что значит буква M в конце "TUL'SKAYA B. UL., M"? " Вам также показался демагогическим. Третью выбранную Вами подсказку по моему правильнее было бы именовать шарадой, но это Вас нисколько не смущает.
У Вас машина какого года выпуска? Если начала 2000-х, к бортовой навигации должен быть приложен диск в картонной коробочке "Digital road map for the BMW Navigation System...". Кроме диска в этой же коробочке должна быть белая брошюрка "END USER LICENSE AGREEMENT". Откройте ее и прочитайте раздел "LIMITED WARRANTY". Почитайте в нем, насколько конкретно они отвечают за качество.

если бы Вас и команду менеджеров/разработчиков это интересовало, вы бы давно уже перенеля опыт больших нави систем и ТомТом, но это упорно не делается

Разумеется, Вам виднее, что меня интересует, а что не интересует.

[Logout]

Мысль по ходу. А правильно ли считать, что рампа находится на перекрестке? Многоуровневая развязка - это перекресток?

По моему, формально с точки зрения ПДД выезд на рампу это один перекресток, а выед с рампы на другую автомагистраль - это второй перекресток.

Совершенно верно, рампа - это не перекресток и в-принципе - это нечто большее. У рампы есть два перекрестка - один на входе, один на выходе.

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

Однако, рисуется не всегда так как нужно

В Ваших руках формат данных, весь мыслимый и немыслимый инструментарий для того, чтобы попробовать

Попробовать на себе результативно можно только если много ездить по разным дорогам. Это не мой случай. Практически реализуемых идей о том как можно устроить массовое тестирование ядра у меня нет.

Вариант созданием тестовой тулзы не рассматривали? Можно было бы написать тулзу (для PC), с некоторым набором перекрестков (а лучше если их можно было бы "выдирать" из карты PGPSPro). Люди могли бы выбрать перекресток и "смоделировать" проезд и любой точки в любую. Как правило, сложные перекрестки - они все известны и бОльшая часть читателей этого форума проезжают их постоянно и имеют представление в голове.
Вот Вам несколько бесплатных тестировщиков. Такие люди найдутся.
Хотя, это опять же не к Вам, а к разработчикам PGPSPro. Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.

или хотя бы прикинуть: какая трудоемкость реализации этого. Вы знаете код и архитектуру ядра, а я - нет.

Мой опыт прикидок собственных времязатрат даже по исходно понятным алгоритмам дает погрешность плюс-минус в пять раз. В обсуждаемом случае на начальном этапе непонятно во что это может вылиться. Для сравнения - прореживание лишних дуг на перекрестках это примерно 400 строк исходного кода, на разработку и исправление ошибок ушло в общей сложности примерно 2 недели, на отлавливание ошибок - около двух лет. На сегодня я знаю два места, в которых код работает не так как хотелось бы, но исправить их без потери правильности в других местах не получается.

Это означает, что этим не надо заниматься в-принципе?

Я уже высказывал идею о плагинах и (полу)открытом API.

Этот вопрос не мне решать, но по-моему это не тот жанр. PGPS Pro это не конструктор и не самоделка. Все разумные опции должны быть в него вшиты.

Мне, например, не нравятся некоторые элементы программы. И с моей точки зрения они должны выглядеть совершенно по-другому.

[Logout]

он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе.

Я знаю что такое генерализация, но тупо не понимаю в чем может быть скрыт потаенный смысл запрета вывода непосредственно примыкающей к проезжаемому перекрестку десятиполосной Б.Тульской при одновременном выводе не имеющего никакого отношения к маневру полутораполосного Холодильного пер.?

Кстати, тот же ТомТом или тот же Автороут, или тот же MapSource от Гармина поддерживает реглировку уровня детализации.

[Чайни]

Вот Вам несколько бесплатных тестировщиков. Такие люди найдутся.
Хотя, это опять же не к Вам, а к разработчикам PGPSPro. Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.

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

[VctOs]

Совершенно верно, рампа - это не перекресток и в-принципе - это нечто большее. У рампы есть два перекрестка - один на входе, один на выходе.

Или нечто ординарное. Участок дороги.

Однако, рисуется не всегда так как нужно

Если покажете примером, буду признателен.

Вариант созданием тестовой тулзы не рассматривали?

LaserMap Advanced Kernel это библиотека. Без соответствующего тестового инструментария при разработке библиотеки я смог бы пройти не далее синтаксического контроля исходного кода.

Можно было бы написать тулзу (для PC), с некоторым набором перекрестков

Так делалось на этапе начального тестирования трассировщика маршрута и при отладке блокиратора наложения названий. Это очень трудоемкий процесс.

а лучше если их можно было бы "выдирать" из карты PGPSPro.

Еще лучше - выбирать на карте. Проблема только в том, что карты меняются и некоторые проблемные места пропадают в новых версиях.

Люди могли бы выбрать перекресток и "смоделировать" проезд и любой точки в любую.

Такой режим в принципе можно реализовать при помощи web сервера lms2, построенного ровно на том же ядре. Проблема в том, что до приписывания к нему соответствующего интерфейса на 77.ru не доходят руки, в том числе потому, что без нормального алгоритма планирования подсказок не получается нармальная легенда маршрута, необходимая для успеха фичи трассировки маршрута на web сервере.

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

Дело даже не столько в том, чтобы знать все сложные перекрестки, важно знать все характерные особенности московских перекрестков. Например случай на Цветном бульваре (их уже даже два случая описано). До него я был категорическим противником выдачи подсказок вне развилок. Теперь вижу, что и с этим правилом не все настолько просто.

Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.

Значит работают. То, насколько я понимаю абстрактный механизм поддержки ПО (абстрактного ПО, а не обсуждаемого, о структуре поддержки обсуждаемого я ничего не знаю), между разработчиками и пользователями есть первый и второй уровни техподдержки. Первый уровень обрабатывает 9/10 обращений по списку часто задаваемых вопросов. Те вопросы, на которые нет ответа в FAQ переключаются на профильных специалистов поддержки второго уровня, имеющих общее представление о продукте. И только через них к абстрактным разработчикам замыкается петля обратной связи.

Это означает, что этим не надо заниматься в-принципе?

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

Мне, например, не нравятся некоторые элементы программы. И с моей точки зрения они должны выглядеть совершенно по-другому.

Это не заказная разработка, а коробочный продукт. Он поставляется таким как он есть и в принципе нравиться всем не может. Маркетологи (абстрактные маркетологи любого коробочного ПО, а не конктретные маркетологи PGPS Pro), прокладывающие курс на разработку программ, стараются угадать в какую сторону дует ветер потребительских симпатий, при этом начинает работать закон больших чисел, растворяющий потребности продвинутых пользователей в океане среднестатистических высокоприоритетных "рюшечек".
Стоит добавить, что и заказная разработка не всегда нравится заказчику.

[VctOs]

он состоит в том, чтобы НЕ отображать на карте объекты/слои не имеющие отношения к маршруту, или утяжеляющие визуальное восприятие при выбранном масштабе.

Я знаю что такое генерализация, но тупо не понимаю в чем может быть скрыт потаенный смысл запрета вывода непосредственно примыкающей к проезжаемому перекрестку десятиполосной Б.Тульской при одновременном выводе не имеющего никакого отношения к маневру полутораполосного Холодильного пер.?

Кстати, тот же ТомТом или тот же Автороут, или тот же MapSource от Гармина поддерживает реглировку уровня детализации.

И при помощи регулирования уровня детализации можно добиться того, чтобы показывались однополосные переулки, но не показывались десятиполосные магистрали?
Кстати, в VGA версии PGPS Pro случайно не появилась такая регулировка?

[Logout]

Вот Вам несколько бесплатных тестировщиков. Такие люди найдутся.
Хотя, это опять же не к Вам, а к разработчикам PGPSPro. Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.

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

Вот поэтому я тут и сотрясаю воздух в надежде что волна дойдет до разработчиков
По-крайней мере с Виктором общаемся адекватно. Еще бы услышать хоть одно мнение разработчиков PGPSPro.

[Logout]

Кстати, тот же ТомТом или тот же Автороут, или тот же MapSource от Гармина поддерживает реглировку уровня детализации.

И при помощи регулирования уровня детализации можно добиться того, чтобы показывались однополосные переулки, но не показывались десятиполосные магистрали?

Нет, такого конечно нет. Относительно PGPSPro я бы сделал такую гарадацию:
1.Федеральные трассы
2. крупные улицы
3. мелкие улицы и переулки
4. ж/д дороги
5. здания
6. линии метро

естественно каждый бОльий уровень включает в себя отрисовку всех объектов предыдущего уровня.

Кстати, в VGA версии PGPS Pro случайно не появилась такая регулировка?

понятия не имею. Сомневаюсь.

[Logout]

Совершенно верно, рампа - это не перекресток и в-принципе - это нечто большее. У рампы есть два перекрестка - один на входе, один на выходе.

Или нечто ординарное. Участок дороги.

Смотря с какой точки зрения смотреть. Если с точки зрения алгоритма прокладки маршрута - да. Ему абсолютно по барабану что это. Для него есть только ребра и вершины графа.
Если рассматривать с точки зрения пригодности использования программы конечными пользователем - то нет. Ему надо попасть из точки А в точку Б и чтобы программа его провела по маршруту и не заставляла материться из-за неправильно проезженого перекрестка.

Однако, рисуется не всегда так как нужно

Если покажете примером, буду признателен.

Люди уже писали об иногда встречающихся проблемах. Я попозже найду, если не возражаете.

Вариант созданием тестовой тулзы не рассматривали?

LaserMap Advanced Kernel это библиотека. Без соответствующего тестового инструментария при разработке библиотеки я смог бы пройти не далее синтаксического контроля исходного кода.

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

Можно было бы написать тулзу (для PC), с некоторым набором перекрестков

Так делалось на этапе начального тестирования трассировщика маршрута и при отладке блокиратора наложения названий. Это очень трудоемкий процесс.

Cut & paste?

Люди могли бы выбрать перекресток и "смоделировать" проезд и любой точки в любую.

Такой режим в принципе можно реализовать при помощи web сервера lms2, построенного ровно на том же ядре. Проблема в том, что до приписывания к нему соответствующего интерфейса на 77.ru не доходят руки, в том числе потому, что без нормального алгоритма планирования подсказок не получается нармальная легенда маршрута, необходимая для успеха фичи трассировки маршрута на web сервере.

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

Но последние что-то все больше по интерфейсу специализируются, и в дискуссию по основной работе PGPSPro не вступают.

Значит работают. То, насколько я понимаю абстрактный механизм поддержки ПО (абстрактного ПО, а не обсуждаемого, о структуре поддержки обсуждаемого я ничего не знаю), между разработчиками и пользователями есть первый и второй уровни техподдержки. Первый уровень обрабатывает 9/10 обращений по списку часто задаваемых вопросов. Те вопросы, на которые нет ответа в FAQ переключаются на профильных специалистов поддержки второго уровня, имеющих общее представление о продукте. И только через них к абстрактным разработчикам замыкается петля обратной связи.

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

Это означает, что этим не надо заниматься в-принципе?

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

Интересная аналогия Я почему-то думаю, что первично должно быть создание прототипа, которое устраивает всеим или почти всем.

Это не заказная разработка, а коробочный продукт. Он поставляется таким как он есть и в принципе нравиться всем не может. Маркетологи (абстрактные маркетологи любого коробочного ПО, а не конктретные маркетологи PGPS Pro), прокладывающие курс на разработку программ, стараются угадать в какую сторону дует ветер потребительских симпатий, при этом начинает работать закон больших чисел, растворяющий потребности продвинутых пользователей в океане среднестатистических высокоприоритетных "рюшечек".
Стоит добавить, что и заказная разработка не всегда нравится заказчику.

Обратите внимание на "коробочные" продукты, установленные у Вас на PC. Почти все поддерживают плагинную идеологию. MS Office, Visual Studio (embedded кстати тоже), MSIE, Mozilla Firefox, Media Player, ICQ, FAR, Total Commander. Продолжать?
Если производитель ПО хочет сделать свой продукт хорошим, он подумает о его перспективе. Когда начинает работать закон больших чисел, обязательно найдутся энтузиасты, которые кроме того, что купят этот продукт, еще бесплатно напишут плагины. Тем самым простимулировав еще большее расширение потребителей.

P.S. Я еще один тред начну. В этом мы ушли далеко от первоначальной темы