cMap 1.42 (полигоны и слои есть)

[Kerg]

http://ingit.narod.ru/cmap142.zip Версия 1.42 не поддерживает вывод в PLT-файл!!! Причина: Отсутствие возможности порезки вложенных полигонов сGPSmap. - Полигоны как полигоны. ( не забывайте обработать (порезать) pGPSmap) (порезка файла при помощи сGPSmap приведет к сбоям!!!) - Сборка и оптимизация сегментов одного объекта. - Оптимизация названий (размер выходного IMG уменьшается до 20%) - Включено формирование слоев. (колонка LAYER dbf-файла) - Исправлено наименование объектов. - Файл cmap.dat больше не используется, имя файла .gem или сборного .gct указывается в командной строке. - Секция заголовка карты [IMG ID] добавляется из файла header.txt (при отсуствии header.txt формируется самостоятельно) cMap D:\\GWRU0102\MAPS\mskare.gct gps -out:С:\TEMP\MAPS cMap D:\\GWRU0102\MAPS\KOSTROBL.GEM gps -out:С:\TEMP\MAPS\ Конвертирование береговых линий Баренцова и Белого морей, поймы Волги и прочие издевательства вроде как проходят. ) Есть единичные ошибки в полиногонах (1-2 на регион) ╚не врезка╩ островов, чьи они пока непонятно┘ Остальное может и не все поправлено, главное это было разобраться со "вложенными полигонами". Если что-то жизнено необходимо пишите... Сергей.

[Subject]

Ругаец-ца.... :(
См почту...

[crab12]

Приветствую, Сергей!
С gem файлом BELARE.GEM падает с доктором ватсоном
С MSKARE.GTC формирует только заголовок , остальное пусто
В качестве выходного файла всегда формирует имя "T"


С уважением, Алексей.

[Kerg]

: С gem файлом BELARE.GEM падает с доктором ватсоном

Размер файла?

:С MSKARE.GTC формирует только заголовок , остальное пусто
:В качестве выходного файла всегда формирует имя "T"

MSKARE.GCT

Сергей.

[Kerg]

Сергей.

[Kerg]

О приятном.

После оптимизации импорта и сортировки объектов Ингит (и их сегментов)
скорость обработки cGPSmap заметно повысилась, в отдельных случаях
перестали выскакивать сообщения о невозможности импортировать
объект. Файл мегов эдак на 30 обрабатывается в обозримые сроки,
в результирующим .img на 2,5 мег.

Самое печальное. ((

cGPSmap Ver 00442 пытается резать уже порезанные полигоны
после pGPSmap. Из-за этого допустим пропадают ╚острова╩.
Старый Ver 00412 делает все нормально, т.к. резать не умеет вообще.
Надо наверно просить Стена выключить порезалку, либо не трогать
полигоны < 255 точек.

У полигонов Ингита иногда бывают дубли ╚дырок╩ (1,2,3┘).
(пока такие замечены только в 31110000 Океаны и моря)
При попытке врезать такую ╚дырку╩ на место уже имеющейся
╚падает╩ pGPSmap. Это вообщем излечимо.
Пока правда несколько не ясно, откуда они там появились? )

Есть и соприкасающиеся дырки, с ними немного хуже, это уже
касается не только морей. (Это большая редкость).
(Вопрос к главному линчевателю?...)

Между порезанными полигонами иногда появляются промежутки
из-за помещения их pGPSmap▓ом в разные TRE.
Бывает и незначительный нахлест, что более приятно.

Предложение к главному линчевателю.

Устал подбирать параметры AlignMethod, TreSize и др. для устранения этого.
Может при порезке ╚внешнего контура╩ полигона сделать этот
╚внахлест╩ специально (опцией) по значению сетки слоя?...
Тогда pGPSmap▓у будет некуда деваться. )

(из Readme00442)
┘
-no more limitations for number of points for polyline and polygon
-automatic splitting of large objects - now single region doesn't have to be as big
as the biggest imported element

Переведите с более точным смыслом фразу начиная с
- now single region doesn't┘

Сергей.

[crab12]

Да, конечно, GCT. Это былв описка.
Но у меня он вообще не реагирует на имя входного файла (gem или gct). что ему на вход ни задай, даже несуществующий файл, пишет одинаково
============
Make cGPSmap .txt files...
field name in DBF - Ok!

Output file t

End export.

Objects 'Point'...... 0
Objects 'Poliline'... 0
Objects 'Poligon'.... 0
Total export Segments 0
Total export Lat/Lon 0

Create file t
(WGS 84)
=====================

С уважением, Алексей.

[Nax]

еще какая-то проблема с выходным файлом. В нужную папку не кладет, и ваще что-то не то.

Максим

[Kerg]

Поправлю.

Сергей.

[Olexa]

: cGPSmap Ver 00442 пытается резать уже порезанные полигоны
: после pGPSmap. Из-за этого допустим пропадают ╚острова╩.
: Старый Ver 00412 делает все нормально, т.к. резать не умеет вообще.
: Надо наверно просить Стена выключить порезалку, либо не трогать
: полигоны < 255 точек.

Интересно, а для чего он это делает? Вероятно, для оптимизации разбивки на TRE. Тогда, быть может, можно чего-то добиться, манипулируя параметрами заголовка. А может, стоит доработать pGPSmap так, чтобы он контролировал не только количество вершин, но и возможность создания такого TRE, в который данный объект смог бы уместиться целиком. Можешь прислать мне пример, в котором cGPSmap режет уже порезанный полигон, чтобы проверить эту гипотезу?

: У полигонов Ингита иногда бывают дубли ╚дырок╩ (1,2,3┘).
: (пока такие замечены только в 31110000 Океаны и моря)
: При попытке врезать такую ╚дырку╩ на место уже имеющейся
: ╚падает╩ pGPSmap. Это вообщем излечимо.
: Пока правда несколько не ясно, откуда они там появились? )

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

: Между порезанными полигонами иногда появляются промежутки
: из-за помещения их pGPSmap▓ом в разные TRE.
: Бывает и незначительный нахлест, что более приятно.
:
: Предложение к главному линчевателю.
:
: Устал подбирать параметры AlignMethod, TreSize и др. для устранения этого.
: Может при порезке ╚внешнего контура╩ полигона сделать этот
: ╚внахлест╩ специально (опцией) по значению сетки слоя?...
: Тогда pGPSmap▓у будет некуда деваться. )

Ох не нравится мне это... С одной стороны, Стен хвастался своим "new algorithm for line generalisation with intersection tracing" и что "definitly solved problem of region shift", с другой стороны cGPSmap, по идее, должен создавать такие искажения, которые не будут заметны на заданном уровне. Может, стоит уровнями поиграться?

: -automatic splitting of large objects - now single region doesn't have to be as big
: as the biggest imported element
:
: Переведите с более точным смыслом фразу начиная с
: - now single region doesn't┘

Насколько я понял, "теперь один регион [TRE] не обязан быть таким же большим, как наибольший импортируемый элемент". То есть, матюков насчёт того, что TRE cannot be found не будет. Но он вероятно сам будет резать большие полигоны (см. начало этого сообщения).