MicroGIS™ DevCon

А чем они вообще опасны и для всех ли навигационных систем?

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

Они опасны разворотами в этом месте (если не стоит запретов). Поэтому было бы лучше, если бы его не было в моем случае.

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

Надоело переключать?

Ага )) И забудешь что он короткий, и пытаешь понять какого фига маршруты неверные. У же 2 раза за седня так накололся.

Добавлено спустя 46 минут 6 секунд:
Сейчас после применения операции Создать дор граф не проставляет скорости и класс. Это очень плохо. Должна проставлять ! Исправить атрибуты рутинга не предлагать - она проставляет на всех линиях, а мне надо только на вновь созданных, как в ГМЕ !

Возвращаюсь к вопросу о белых нодах.

Более того! Если делаешь адресный поиск для гармина, как все обычно и делают: http://chelmaps.ru/articles/articles_gp ... esnym.html

то обязательно будут в карте белые ноды. На них микрогис ругается и по каждой белой ноде вываливает ошибку. А адресов в карте тысячи, и от каждого - 2 белые ноды. Представляете, сколько ошибок в карте находит программа? Хотя на самом деле ничего страшного для гармина в таких белых нодах с адресным поиском нет, всё успешно конвертируется и работает.

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

Просто не пользуйся этой проверкой и всё.

Конечно, мне не сложно отключить её. Но ведь эта проверка находит ещё и "плохие" белые ноды, которые не имеют адреса, а возникли просто в узле разрыва дороги на 2 части. Вот эти белые ноды я бы с удовольствием исправил.

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

Вот такие пока мысли.

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

Не для всех навигационных программ белые ноды приемлемы. Для СитиГида например - преступление. Для Garmin - принимайте решения из своих предписаных правил.

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

Уже говорил ранее и повторю еще раз, резать дороги на перекрестках - не лишнее для любых программ. И для СитиГид и для GARMIN. У нас в программе для этого есть специальный инструмент. Но даже если вы этого не делаете, компилятор это сделает за вас. Как будет шейп, то перед экспортом, мы это тоже сделаем автоматом.

Когда ставим галку Односторонее движение что бы автоматом ставилась Линия имеет направление!

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

Не знал. Добавить в инструменты Убрать направление для всех полилиний!