MicroGIS™ DevCon

которое не будет исправлятся до подтверждения АКТУАЛЬНОСТИ этого формата.

Я тоже подтверждаю... поддержать формат OZI Explorer - нужно... очень... Я вообще за универсальность... Я уже задолбался одновременно несколькими программами пользоваться, когда можно было бы все сделать в МГЕ

При загрузке карты в журнале сообщений выдаётся:
Надо бы убрать это неактуальное замечание. Тем более, что не только 26-я битность реализована в программе, но имеются также битности 27 и 28. И можно их выбирать через "Свойства карты".

DarkDiver писал(а):Кроме того многие программы работают с форматом геотиф (MPC, map2jnx, EasyTrace и др.), который MGE не поддерживает в принципе. В итоге приходится хранить одни и те же карты уже в 3-х форматах под каждое применение, а это не очень удобно.

Во-во! Шейпы MPC для векторных карт практически поддержали, а растровый слой для них в формате GeoTIFF приходится готовить в сторонних прогах...

Незнаю баг или нет:
Нажимаю на полигон(например города) -> выделить пересекающиеся объекты, "Открыть в таблице" не активно
Выделяю просто определенную область (город) "открыть в таблице" активно

Цветопредставление при включенной подсветки по адресу и зуммировании карты - баг или фишка?
Если фишка - что этим преследуется?

Добавлено спустя 25 минут 9 секунд:
Shape File - добавьте к набору одноименный файлик принадлежности CK - PRJ (не все сразу скармливают в MPC, а умным программам необходимо знать в чем им скармливают данные, так как систем координат множество... да и указывать каждому шейпу, что это СК WGS84 надоедает) Добавлено спустя 9 минут 28 секунд:
Набор Shape roads не открывается в ArcGis, без запуска утилит восстановления геометрии
Причину я так понимаю переводить не нужно?

И как я понимаю причина кроется в этом -
Если вы перед экспортом делаете проверку на порезанность дороги на перекрёстках, то наверное и остальное проверить не мешает.. ИМХО

Добавлено спустя 19 минут 37 секунд:
Я был прав - ошибка из-за дорог без конечного NOD (Надо бы проверять на наличие подобных дорог перед экспортом... ИМХО)

Адресные точки...
Эээ... а кто сказал что совместить точки ADDR_PNT и ARRV_PNT это правильное решение? ADDR_PNT - это точка прибытия (конечная цель) а ARRV_PNT подъезда, которая находится на дороге и до которой прокладывается маршрут по дорогам.
Совмещение этих точек не критический случай, но на 100% через ж...пу реализованый однозначно.

PS .. извините за выражения...

Добавлено спустя 42 минуты 40 секунд:
Не критичный БАГ, но бьющий по себялюбию...

Полигональные полигоны в шейпах создаются с ошибкой геометрии, в результате чего получаем казусы при отображении и редактировании в сторонних программах (одно только значение площади чего стоит)
Смею предположить, что причина кроется в том, что в шейпах последняя точка описываемоего полигона является и самой первой, т.е. если есть прямоугольник с точками вершин {1,2,3,4}

то правильной записью полигона в шейпах будет {1,2,3,4,1}, в отличие от польского формата записи {1,2,3,4}

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

По точкам, нет первая и последняя - совпадают. Причём записываются по часовой стрелке. Перенесенные шейпы в приборе отображаются корректно

В МГЕ есть точки прибытия. При их расстановке - они не будут совпадать. Совпадают только при отсутствии точки прибытия, рассчитываются как центр полигона.

Fencer_Silver писал(а):Тебе надо, ОДИН РАЗ - для всего ВАШЕГО проекта - вбить HEX кода - в настройки MPC (т.к., что, вбивать HEX, что JELEZNAYA_DOROGA - одинаково HEX - короче и вбить его быстрее

Читал долго, все верно и логично - HEX это быстро, но String намного понятнее... Счас вот, как человек не работающий в польском, получил карту в шейпах сделанную с помощью MГЕ
Для меня проще понять, что то что помеченные красным было бы записано как BURIAN чем как сейчас - 0x10F06

PS Ни на что не претендую, но идея Вована более чем достойна на более подробное рассмотрение.

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

Fencer_Silver писал(а):По точкам, нет первая и последняя - совпадают. Причём записываются по часовой стрелке. Перенесенные шейпы в приборе отображаются корректно

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

PS... Я ни на что не настаиваю - увидел косяк - сообщил. Править или не править - ваше решение.

Ну и вопрос - как если нет точки прибытия записывать? Оставлять поле ARR_PNT пустым? По геометрии - вообще что-то непонятное. С помощью МГЕ собиралась карта из нескольких. Если бы мы что-то неправильно писали бы между картами роутинг никогда бы не работал.... Никогда не совпали бы области покрытия карт и дорожный граф.... Потом - при импорте шейпа в МГЕ им же созданным - все нормально, нет никакого искажения. Так же смею предположить - может в системе координат проблема? Датум, полуоси эллипсоида?

П.С пишу с тапаталка андроида - поэтому так много сообщений. Неудобно....

Fencer_Silver писал(а):Ну и вопрос - как если нет точки прибытия записывать? Оставлять поле ARR_PNT пустым?

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

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

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

Fencer_Silver писал(а):Так же смею предположить - может в системе координат проблема? Датум, полуоси эллипсоида?

я вроде как не дилетант, и проблем с СК допустить не могу - на скрине виден лог исправления геометрии, если простого перевода недостаточно можно заглянуть в support ESRI и прочитать более детально.

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

Monstria писал(а):

Fencer_Silver писал(а):Ну и вопрос - как если нет точки прибытия записывать? Оставлять поле ARR_PNT пустым?

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

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

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

Fencer_Silver писал(а):Так же смею предположить - может в системе координат проблема? Датум, полуоси эллипсоида?

я вроде как не дилетант, и проблем с СК допустить не могу - на скрине виден лог исправления геометрии, если простого перевода недостаточно можно заглянуть в support ESRI и прочитать более детально.

При сборке карты из нескольких - присутствует полигон 0х4B в польском Область покрытия карты Вы же не хуже меня знаете, что несовпадение любой координаты этих полигонов приведут к невозможности роутинга между картами. Надо разобраться почему так открывают "взрослые программы". Просьба ко всем Гарминологам - обратите внимание на отображение полигонов в приборе. И вопрос к Monstria - а Вы не пробовали открывать шейпы, сделанные скриптом Василия? Нет у меня взрослых программ - не на чем проверить.....

П.С. КАЧЕСТВО СКРИНА -очень плохое, по крайней мере на Андроиде. Ничего рассмотреть не удаётся. Попробую чуть позже на Винде.

Добавлено спустя 25 минут 29 секунд:
Перепроверил. Первая и последняя точка совпадают.

for (size_t cPoint = 0; cPoint < cPoints; cPoint++) {
const point_t & point = element.points [cPoint];
x[cCurrentPoint] = point.x;
y[cCurrentPoint] = point.y;
z[cCurrentPoint] = 0;
m[cCurrentPoint] = 0;
++cCurrentPoint;
}
x[cCurrentPoint] = element.points [0].x;
y[cCurrentPoint] = element.points [0].y;
z[cCurrentPoint] = 0;
m[cCurrentPoint] = 0;
++cCurrentPoint;


Проблема точно не здесь. Надо искать в другом месте....

Добавлено спустя 43 минуты 4 секунды:
Проверил запись и содержимое shp. Нарисовал обычный прямоугольник. Он записался 5-ю координатами, как и задумано. При вычитке файла вычитываются 5-ть координат. Запись корректна.

Fencer_Silver писал(а):

Monstria писал(а):

Fencer_Silver писал(а): Перепроверил. Первая и последняя точка совпадают.
.....

Проблема точно не здесь. Надо искать в другом месте....

Добавлено спустя 43 минуты 4 секунды:
Проверил запись и содержимое shp. Нарисовал обычный прямоугольник. Он записался 5-ю координатами, как и задумано. При вычитке файла вычитываются 5-ть координат. Запись корректна.

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

Fencer_Silver писал(а):Просьба ко всем Гарминологам - обратите внимание на отображение полигонов в приборе.

На что конкретно надо обращать внимание в полигонах?