Обсуждение Beta версий (тестирование, баги, замечания)

[DarkDiver]

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

[DarkDiver]

Просьба отписаться по вылетам при работе с TYP файлом

Дважды поймал ошибку "Abnormal program termination" при переключении между тип-файлами, после чего редактор зависает.
Но в целом стало работать стабильнее. При создании объектов и при изменении типа, ошибок которые были раньше, пока не ловил.

[DarkDiver]

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

Пример:
[_polygon]
Type=0x28
String1=0x04,Ocean
String2=0x19,Океан
ExtendedLabels=N
Xpm="0 0 1 0"
"1 c #0095D5"
String1=0x04,Ocean
String2=0x19,Океан
[end]

[Fencer_Silver]

Про групповую панель я знаю, но что-то не пойму, как в ней разом изменить например тип для 100 объектов, не делая 100 кликов по каждой строчке в групповой панели, подскажите пожалуйста как это можно сделать.

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

Далее, что касается групповой - там есть магическая зеленая кнопка "вниз" - с ее помощью можно заполнять все что угодно для любого ключа объекта. В FAQ - все подробно расписано.

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

Будем смотреть дальше

[DarkDiver]

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

Далее, что касается групповой - там есть магическая зеленая кнопка "вниз" - с ее помощью можно заполнять все что угодно для любого ключа объекта. В FAQ - все подробно расписано.

Все получилось обоими способами, спасибо!

[User_tester]

Alex, за объяснение по эллипсам спасибо! Про генерализацию надо было сказать в самом начале. Вашу логику теперь я понял, хоть и не согласился.

2. User-tester. На навигаторе есть такой же пример кривого отображения карты с элипсом, нарисованном в МГЕ ?

Есть, могу приложить скрины с экрана, если хотите.

Странно, что некоторые части элипса выглядят ровнее, а некоторые более зубчатые. Я понимаю, если бы он был равномерно зубчатый. Но тут ИМХО действительно странно. Ведь генерализация поидее должна равномерно распределяться по всем точкам фигуры. Почему в данном случае она не равномерна ?

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

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

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

Но даже если делается генерализация, эллипсы не должны получатся такими, какими они получаются сейчас. Эллипс - фигура выпуклая, следовательно он аппроксимируется ВЫПУКЛЫМ многоугольником-полигоном. А у выпуклого многоугольника не должно быть внутренних углов больше 180 град. А у Ваших эллипсов-многоугольников это не так. Отсюда единственный, однозначный и абсолютно верный вывод - многоугольник аппроксимирующий эллипс в МГЕ строится не корректно. С математикой и геометрией не поспоришь.

Согласен полностью и на 100%! Даже комментировать и добавлять нечего.

[MaxBel]

User-tester
Да хотелось бы посмотреть скриншот.

[Fencer_Silver]

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

Я не знаю как МПС, но сGPSMapper - точно -этим заниматься не будет. Далее не видел еще ни одного компилятора, который корректно "исправлял" ошибки картографа. Для этого и введены в редактор проверки. В результате можно получить "архикрасивую" карту, сидеть и любоваться ею в гордом одиночестве....

[Cnfhbr]

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

Однако для создания, например, 3D моделей зданий с помощью МРС, контуры их полигонов должны максимально повторять оригинальные очертания этих строений, архитектурные формы которых могут быть достаточно вычурными.
Попробуйте открыть прикрепленный в аттаче исходник сначала в GPSMapEdit (только не пересохраняйте его там, поскольку данный исходник создан с помощью другого инструмента для наглядности форм), а затем - в MicroGIS Editor, и почувствуйте разницу, даже при отключенной сетке генерализации...

[DarkDiver]

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

Я не знаю как МПС, но сGPSMapper - точно -этим заниматься не будет.

Как раз таки сGPSMapper генерализацию выполняет, см. мануал:

PreProcess=x
Kind of pre-processing:

G - generalization only (faster method, but 'crossroad' nodes might be removed). Also the nodes from intersections may be removed. Data will be simplified using Douglas-Peucker polyline simplification algorithm which will ensure that the output is not jagged.

F (or Y) - full generalization + intersection detection for polylines. Unnecessary nodes are not removed if there are intersections (this is important for more advanced maps - at intersections, all the intersecting roads have to have nodes or 'find intersection' won't work). This is very similar to 'G' with one important exception - all intersection points of the roads are preserved too (even if according to the simplification algorithm these points should be reduced) - this is especially important when we are interested in using 'find intersection' functionality.

Intersections are detected only for the most detailed layer, for the others no trace is done.

P - very similar to option ‘F’ - full generalization + intersection detection for polylines and polygons. Should be used with caution, as process time might be much longer.

Intersections for polygons are detected for all the layers, for polylines – only for the most detailed layer.

N - no generalization and no intersection detection. Unnecessary nodes (from the resolution point of view) will be removed automatically. There will be no reduction of the 'oversampled' points in the objects - the only reduction of the points will be done because of alignment to the same coordinates. This option should be used if input data is prepared separately for each layer - the data for each layer having already been adjusted to the map author's requirements.
Used only if you explicitly provide data for all layers.
Default =F

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

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

[User_tester]

User-tester
Да хотелось бы посмотреть скриншот.

Хорошо. На этих выходных сделаю подборку и выложу сюда. Эти дни пока занят по работе.

Я не знаю как МПС, но сGPSMapper - точно -этим заниматься не будет. Далее не видел еще ни одного компилятора, который корректно "исправлял" ошибки картографа. Для этого и введены в редактор проверки. В результате можно получить "архикрасивую" карту, сидеть и любоваться ею в гордом одиночестве....

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

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

Что касается MPC, то, по имеющейся у меня информации, в его настройках есть функция "Disable polyline simplification". Она отвечает за генерализацию линий и полигонов. Если поставить птичку на этой функции, то генерализация проводиться не будет, и в полученной карте сохранится входное качество исходника. Так вот, если это качество у исходника изначально неважное, то таким же оно останется после компиляции. Разумеется, при поставленной птичке на функции. Несколько ухудшить внешний вид карты, конечно, можно, и для этого надо снять птичку в настройках, чтобы провелась генерализация.

Выводы:

1. чётко выраженные зубья в сторонах эллипсов убрать и сделать карту лучше, чем исходник, при компиляции не получится! Можно только либо оставить всё как есть, либо ухудшить ещё больше, по сравнению с исходником.
2. ни в коем случае нельзя обеднять исходник картографической информацией, как это реализовано при рисовании и генерализации эллипсов в микрогисе! Потому что любой компилятор может или сохранить исходное качество, или ухудшить его. Но никак не улучшить!
3. незачем отказывать себе в удовольствии получить красивую работоспособную карту с гладкими эллипсами, тем более что компилятор этому никак не мешает. Здесь вся задача в том, что разработчикам надо выправить алгоритм аппроксимации эллипсов многоугольниками и сделать так, чтобы эллипсы были гладкие.

[DarkDiver]

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

Однако для создания, например, 3D моделей зданий с помощью МРС, контуры их полигонов должны максимально повторять оригинальные очертания этих строений, архитектурные формы которых могут быть достаточно вычурными.
Попробуйте открыть прикрепленный в аттаче исходник сначала в GPSMapEdit (только не пересохраняйте его там, поскольку данный исходник создан с помощью другого инструмента для наглядности форм), а затем - в MicroGIS Editor, и почувствуйте разницу, даже при отключенной сетке генерализации...

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

[DarkDiver]

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

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

[Alex]

Да вот как раз не в любой. Лучше прилипание к сетке не отключать. Иначе если она не была включена и объекты создавались без неё, а потом включить и выполнить генерализацию - на выходе получишь кучу самопересечений/наложений в карте.

[DarkDiver]

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