MicroGIS™ DevCon

1. Нарисовал рядом друг с другом ряд полигонов и сгруппировал их. Для сгруппированных полигонов при экспорте в шейпы топология исправляется некорректно! В левом столбце до стрелки записаны исходные направления полигонов (лево- и правозакрученные). После стрелки - во что они превратились после экспорта в шейпы:

лево лево ---> право лево
право лево ---> право лево
лево право ---> право лево
право право ---> право лево

А должно быть во всех случаях "право-право". О дырявых полигонах в данном примере речь не идёт! Только о целостных сгруппированных полигонах.

Для сравнения: несгруппированные левозакрученные полигоны корректно исправляются на правозакрученные.

2. Длина поля в DBF-формате 254 символа, а не 255, как экспортируется сейчас. Например, 255 имеется в RD_SIGNS и RSTR, а во многих остальных атрибутах длины полей урезанные.

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

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

4. В формате ESRI *.SHP полигоны с дыркой вида (а) ошибкой совершенно не являются. А полигоны вида (б) являются, там обнаруживается самопересечение. Дорожка к внешнему краю удаляется и (б) превращается в (а).



Однако проверка карты на "многоэлементные полигоны" в микрогисе находит как настоящие сгруппированные полигоны (см. их в пункте 1 выше), так и полигоны вида (а). Очевидно, что для Garmin искать (а) не нужно, равно как и проводить "слияние внутренних полигонов" с превращением (а) в (б). В отличие от поиска настоящих сгруппированных полигонов.

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

1. поиск настоящих сгруппированных полигонов
2. поиск полигонов вида (а)

Я бы пользовался только первой проверкой.

Все вопросы, связаны с непониманием теории дырявых полигонов в польском формате. Постараюсь объяснить:

НЕМНОГО ТЕОРИИ КАСАТЕЛЬНО МНОГОЭЛЕМЕНТНЫХ ПОЛИГОНОВ
Как в исходнике представлен полигон? Полигон представлен неким параметром (описывающий форму элемента) DataX=, в котором находятся координатные пары периметральной линии, которую редактор отображает в виде полигона, замыкая её саму на себя и заливая соответствующей заливкой или текстурой. Например: То есть объект состоит из секции: [POLYGON], параметра определяющего тип объекта: Type= и параметра определяющего форму элемента: DataX=.

Как в исходнике представлены сгруппированные полигоны? А вот так: Мы имеем опять таки 1 объект (1 секция [POLYGON]), общий параметр: Type= и 2-а параметра описывающие форму элементов: DataХ=. Причем первый параметр DataХ= описывает основной элемент полигона, а второй параметр DataХ= описывает вложенный элемент полигона, говоря другими словами - "пригруппированный" полигон.

Как в исходнике представлен "дырявый" полигон Абсолютно также как и сгруппированный полигон: Разница сгруппированных полигонов от "дырявого" состоит лишь в том, что все "пригруппированные" элементы геометрически отстоят друг от друга на некотором расстоянии. А в "дырявом" последующие элементы попадают внутрь первого. Записи в исходнике "дырявого" полигона и сгруппированного полигона - абсолютно одинаковы. Определение дырки выполняется внутренней логикой программы. Из этого следует:
- Сгруппированный полигон - это многоэлементный полигон с несколькими геометрически отстоящими друг от друга элементами.
- "Дырявый" полигон - это многоэлементный полигон в котором некоторые элементы геометрически попадают внутрь первого. Элементы попавшие внутрь первого - принято считать "дырками".

ОТОБРАЖЕНИЕ МНОГОЭЛЕМЕНТНЫХ ПОЛИГОНОВ В РЕДАКТОРЕ
- В редакторе второй или последующие элементы полигона, при условии что они геометрически отстоят друг от друга, считаются СГРУППИРОВАННЫМИ полигонами и заливаются той же заливкой или текстурой, что и основной полигон (элемент).
- В редакторе второй или последующие элементы полигона, при условии что они попадают внутрь основного элемента полигона считаются ВЛОЖЕННЫМИ или "ДЫРКАМИ" и для визуального восприятия заливаются белой заливкой.
- В редакторе второй или последующие элементы полигона, при условии что они геометрически пересекают основной элемент полигона считаются САМОПЕРЕСЕКАЮЩИМИСЯ, поскольку пересечение происходит внутри одного объекта. Такие полигоны считаются ошибкой и могут иметь заливку либо "дырки", либо основного элемента, в зависимости от площади пересечения.

ИНСТРУМЕНТ "СЛИЯТЬ ВНУТРЕННИЕ ПОЛИГОНЫ"
Дело в том, что не все навигационные программы одинаково способны обработать сгруппированные объекты (об этом - мы упоминали в мануале к MicroGISEditor). Для того, что бы избавиться от многоэлементных полигонов, перед выпуском карты для таких программ, в MicroGISEditor существует инструмент "Слиять внутренние полигоны". Если применить данный инструмент:
- СГРУППИРОВАННЫЕ полигоны - разгруппируются, на несколько объектов. Каждый объект унаследует все свойства (атрибуты) первого.
- ВЛОЖЕННЫЕ элементы сольются с основным, сохраняя при этом вид и форму предыдущего. Виуально - тело полигон получит линию образованную стыковкой его рёбер. В навигационной программе, эта линия убирается, путем нехитрых комбинаций при формировании стиля визуального оформления. Но это уже совсем другая песня.

Теперь, что касается вопросов:

1. С топологией всё в порядке. Программа работает так как ей и предписано:
В процессе экспорта многоэлементного полигона в SHP Shapefile основной элемент всегда приобретает правое "вращение", все остальные элементы - левое. Так и было задумано. Программа не выполняет проверку дополнительных элементов на признак: СГРУППИРОВАННЫЙ/ВЛОЖЕННЫЙ.

2. Максимальная длина поля в DBF-формате может достигать 255 символов. Поэтому говорить об ошибке в программе - это не правильно. Компилятор MPC прекрасно справляется с 255 символами. Я понимаю, что проблема обусловлена совместимостью с ArcGIS, который обрабатывает 254 символа. Мы обсудим этот вопрос у себя еще раз.

3. Проанализировав присланный пример, отвечаю:
При слиянии полилиний белый НОД автоматически убирается только при отсутствии в нём запретов дорожного движения. В вашем случае - в НОДе имеется запрет (Restrict).

4. ArcGIS при импорте одинаково понимает и вариант (а) и вариант (б). В последствии он преобразовывает вариант (б) в (а) - и это правильно. Как в ArcGIS это достигается и как хранится я не знаю. Да и какая разница. Для ArcGIS - выполнять "Слияние внутренних полигонов" не нужно. Он вполне адекватно понимает и обрабатывает "дырки". MPC тоже абсолютно нормально обрабатывает "дырки". Поэтому выполнять "Слияние внутренних полигонов" для компилятора MPC - не нужно. CityGuide тоже научился адекватно обрабатывать вариант (а). Для него тоже выполнять "Слияние внутренних полигонов" - не нужно. Ну а в исходнике, "ради забавы", выполнять "Слияние внутренних полигонов" я не рекомендую, обратного инструмента в программе -нет. Еще раз повторюсь: "Слияние внутренних полигонов" нужно выполнять только при подготовке карт под конкретный проект (на копии карты) если того требуют рекомендации поставщика компилятора.

Что касается проверок:
- Проверка на "Многоэлементные полигоны" одинаково находит и "дырявые" полигоны и сгруппированные полигоны. Потому что это разновидности одного и того же. Так было и так будет. Если конечная программа или компилятор понимает один вид, то и второй она поймет автоматически. В любом случае проверка работает - правильно. Разнести данную проверку на 2-е теоретически можно, но практического смысла - не вижу.

- Проверка на "Самопересечение полигонов" правильно обрабатывает полигоны вида (б). Полигон вида (б) - не считается самопересекающимся если координаты стыковочных узлов совпадают.

Alex писал(а):1. С топологией всё в порядке. Программа работает так как ей и предписано:
В процессе экспорта многоэлементного полигона в SHP Shapefile основной элемент всегда приобретает правое "вращение", все остальные элементы - левое. Так и было задумано. Программа не выполняет проверку дополнительных элементов на признак: СГРУППИРОВАННЫЙ/ВЛОЖЕННЫЙ.

Спасибо за объяснения! Из-за отсутствия таковой проверки многоэлементные полигоны и приобретают неверное направление при экспорте в шейпы. Так или иначе, но при обмене шейпами приходится в ArcGIS запускать инструмент "Repair Geometry" и исправлять данную ошибку:
После исправления сгруппированность полигонов по-прежнему сохраняется, но теперь каждый из них приобретает правильное направление (правозакрученное), как того требует формат шейпфайлов ESRI.

Alex писал(а):2. Максимальная длина поля в DBF-формате может достигать 255 символов. Поэтому говорить об ошибке в программе - это не правильно. Компилятор MPC прекрасно справляется с 255 символами. Я понимаю, что проблема обусловлена совместимостью с ArcGIS, который обрабатывает 254 символа.

Не соглашусь, максимальное число символов в текстовом поле (char) базы данных - 254 символа. А максимальное число полей в записи, с чем вы путаете, это 255. Везде это упоминается. Вот навскидку описание:

http://www.codenet.ru/progr/formt/dbf.php

Так что ArcGIS тут совершенно не причем. Это ограничение придумано не мной и не данной программой, а форматом DBF.

Итого, есть 2 задачи:

1. экспортировать из польского формата в формат шейпфайлов ESRI
2. экспортируемые шейпы наполнять в соответствии со спецификацией Garmin MPC

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

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

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

Читаем ОПИСАНИЕ Shape File в оригинале, от "производителя", как того требует формат шейпфайлов ESRI.:

The instance diagram in Figure 2 illustrates the representation of polygons. This figure
shows a polygon with one hole and a total of eight vertices.
The following are important notes about Polygon shapes.
The rings are closed (the first and last vertex of a ring MUST be the same).
The order of rings in the points array is not significant.
Polygons stored in a shapefile must be clean. A clean polygon is one that
1. Has no self-intersections. This means that a segment belonging to one ring may
not intersect a segment belonging to another ring. The rings of a polygon can
touch each other at vertices but not along segments. Colinear segments are
considered intersecting.
2. Has the inside of the polygon on the "correct" side of the line that defines it. The
neighborhood to the right of an observer walking along the ring in vertex order is
the inside of the polygon. Vertices for a single, ringed polygon are, therefore,
always in clockwise order. Rings defining holes in these polygons have a
counterclockwise orientation. "Dirty" polygons occur when the rings that define
holes in the polygon also go clockwise, which causes overlapping interiors.


Таким образом
Vertices for a single, ringed polygon are, therefore, always in clockwise order. - Внешняя сторона "дырявого" полигона - по ЧАСОВОЙ стрелке.

Rings defining holes in these polygons have a counterclockwise orientation. - "Дырка" - против часовой.

Что касается dBase (Очень спасибо за Вашу ссылку на dBase, очень давно искали )

Organization of
the dBASE File
The dBASE file (.dbf) contains any desired feature attributes or attribute keys to which
other tables can be joined. Its format is a standard DBF file used by many table-based
applications in Windows™ and DOS. Any set of fields can be present in the table. There
are three requirements, as follows:
The file name must have the same prefix as the shape and index file. Its suffix must
be .dbf. (See the example on page 2, in Naming Conventions.)
The table must contain one record per shape feature.
The record order must be the same as the order of shape features in the main (*.shp)
file.
The year value in the dBASE header must be the year since 1900.
For more information on the dBASE file format, visit the INPRISE Corp

А общий вывод
Вообще-то не могу понять причем тут АркГис?

Разговор слепого с глухим

Нарисуем для примера квадратный полигон леса против часовой стрелке и в 100 метрах от него - такой же полигон против часовой стрелки. Сгруппируем их через контекстное меню. Сохраним и экспортируем в шейпы.

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

Где тут дырка?

Добавлено спустя 12 минут 32 секунды:

Fencer_Silver писал(а):Вообще-то не могу понять причем тут АркГис?

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

User_tester писал(а):Разговор слепого с глухим

Согласен. Еще раз:

Я ответил Вам по поводу Вашего высказывания как того требует формат шейпфайлов ESRI.

Разберемся, что же ТРЕБУЕТ формат ESRI. В шейпах могут хранится следующие объекты

0 Null Shape
1 Point
3 PolyLine
5 Polygon
8 MultiPoint
11 PointZ
13 PolyLineZ
15 PolygonZ
18 MultiPointZ
21 PointM
23 PolyLineM
25 PolygonM
28 MultiPointM
31 MultiPatch

Нас интересую ПОЛИГОНЫ:
1. Просто "Polygon" - его описание
The following are important notes about Polygon shapes.
-The rings are closed (the first and last vertex of a ring MUST be the same).
-The order of rings in the points array is not significant.
Polygons stored in a shapefile must be clean. A clean polygon is one that
1. Has no self-intersections. This means that a segment belonging to one ring may
not intersect a segment belonging to another ring. The rings of a polygon can
touch each other at vertices but not along segments. Colinear segments are
considered intersecting.
2. Has the inside of the polygon on the "correct" side of the line that defines it. The
neighborhood to the right of an observer walking along the ring in vertex order is
the inside of the polygon. Vertices for a single, ringed polygon are, therefore,
always in clockwise order. Rings defining holes in these polygons have a
counterclockwise orientation. "Dirty" polygons occur when the rings that define
holes in the polygon also go clockwise, which causes overlapping interiors.

2.PolygonZ
A PolygonZ consists of a number of rings. A ring is a closed, non-self-intersecting loop.
A PolygonZ may contain multiple outer rings. The rings of a PolygonZ are referred to as
its parts.

The following are important notes about PolygonZ shapes.
The rings are closed (the first and last vertex of a ring MUST be the same).
The order of rings in the points array is not significant.

3.PolygonM

A PolygonM consists of a number of rings. A ring is a closed, non-self-intersecting loop.
Note that intersections are calculated in X,Y space, not in X,Y,M space. A PolygonM
may contain multiple outer rings. The rings of a PolygonM are referred to as its parts.

The following are important notes about PolygonM shapes.
The rings are closed (the first and last vertex of a ring MUST be the same).
The order of rings in the points array is not significant.


Как Вы, наверняка видите, формат шейпфайлов ESRI НЕ ДАЕТ НИКАКИХ УКАЗАНИЙ относительно ПРОСТО сгруппированных полигонов, вопреки Вашему утверждению! То, что АркГис "ругается" при открытии, я и спрашиваю - причем тут АркГис? Вы наверняка убедились, что МПС - считает все корректным, не правда ли?

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

Действительно, не в вакууме. Вы пишите о том, что не можете "безболезненно" поделится с пользователями АркГиса. А Вы уверены, что после переделки НЕДОКУМЕНТИРОВАННОЙ "ошибки", как Вы изволили выразится - шейпы будут открываться, в других программах?

User_Tester, перечитал еще раз спецификацию записи в шейп. Вот из описания:

A polygon may contain multiple outer rings. - Полигон может содержать несколько (много) внешних колец (частей). Внешнее кольцо - это как раз часть сгруппированного полигона. Читаем далее:
Vertices of rings defining holes in polygons are in a counterclockwise direction. - Вершины кольца (части), определяющего ДЫРКУ в полигоне - ПРОТИВ ЧАСОВОЙ СТРЕЛКИ.
Vertices for a single, ringed polygon are, therefore, always in clockwise order. - Вершины для ОДИНОЧНОГО, ДЫРЯВОГО полигона - всегда ПО ЧАСОВОЙ СТРЕЛКЕ.

И я нигде не нашел, что вершины для внешнего элемента ДОЛЖНЫ следовать по-часовой. Если таковое описание существует просьба привести его здесь.

Так здесь же всё сказано прямым текстом.

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

А касательно вашего вопроса, поймут ли другие программы - на 99,9% думаю, что да! У кого есть, к примеру, MapInfo и умеют там работать - могут уже сейчас это проверить. Исходники шейпов пришлю.

А касательно ArcGIS, у меня к его проверкам топологии подозрений как-то не возникает. Всё-таки лидер на рынке профессиональных ГИС, разработан самим автором шейпов - фирмой ESRI. Откуда должны возникнуть поводы сомневаться в справедливости выдаваемых варнингов?

User_tester писал(а):А целостные полигоны и полигоны с дырками (то есть, внешние контуры) - всегда по часовой стрелке. Всё более чем понятно!

Оригинальный текст
Vertices for a single, ringed polygon are, therefore, always in clockwise order.

В корне не согласен с Вашим трактованием! Полигон может быть одно элементным - это single. А вот ringed polygon - это полигон СОДЕРЖАЩИЙ ДЫРКУ(И). Т.Е. первый элемент полигона, а второй, третий его элемент - это "дырки".



Добавлено спустя 2 минуты 53 секунды:
P.S. Может не совсем правильно выразился выше - Внешние элементы- это "outer rings". И как их записывать - ни слова. Это не "целостные полигоны", а именно - элементы (outer rings). Поэтому, не понятно, где " Всё более чем понятно!"

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

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

И насчёт 255 символов, я полагаю, вам всё понятно. Здесь наблюдается смещение и утери значений атрибутов при импорте. Сам лично наблюдал обнуление скоростей. 254 символа - максимум должно быть.

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

Приветствую!

Если закрыть карту меню -> закрыть, то с файла *.bak не снимается блокировка

Условия теста: Win 8.1 64 бита. МГЕ 32 и 64 бита.
Воспроизвести данную проблему не удается. Все файлы карты, а так же *.BAK - удаляются, переносятся и т.д.

При этом сам МГЕ не закрывать, закрыть только карту. Работает?
win7, MGE 32 бит

Почему то опустели панели "Главная" и "Присоединённые объекты"