Global Mapper и его работа с картами от OziExplorer

[seno]

kefi
На всякий хочу предупредить от распространенной ошибки.
В GM есть два места где устанавливаются датум. Одно для привязки карты, второе для вывода на дисплей программы, оно же для экспорта.
В последних версиях GM даже окно специальное всплывает с предупреждением что для чего.
Проще понять на практическом примере:
Когда открываем первую карту, датум привязки карты и выходной датум идентичны. Правильны, неправильны они, неважно, они одинаковы. Когда открываем вторую и следующие карты, они открываются со своими датумами, но показываются они и экспортируются в проекции и датуме первой карты.
Поэтому:
Если делаем карту для OZI, не надо трогать датум по умолчанию. Неважно что он неправильный. В OZI карта всё равно будет работать под OZI датумом. А если меняем на пользовательский, необходимо и выходной датум сменить на такой же.
Вспомнил, потому что что только что сам накололся по невниманию.
Создал большой проект для вывода в JNX. Карты в Пулково, тщательно подобрал датум, накладывая треки и космоснимки. Подобрал датум и сохранил проект. Потом сменил выходной датум и проекцию на WGS84, Lat/Lon, сохранил как новый проект и вывел в Geotiff для JNX.
Через недельку подумал, дай выведу проект для OZI. А забыл дурак, что датум то подобранный. Т.е. привязка в Custom, а вывод в том что по умолчанию - PULKOVO 42.
Результат: сначала GM ночь работал, сшивая и нарезая Geotiff из почти тысячи листов, потом OziMapMerge трудился 15 часов сшивая огромную простыню.
И всё зря :)

<noindex></noindex>

[kefi]

2 Moskus>
>Эти csv-файлы относятся к одной из библиотек, используемых GM, а не хранят встроенные датумы.>

Так , а это не одно и то же ? А как тогда все же посмотреть какой датум соответствует тому, что в GUI видно как S-42 (PULKOVO 1942)

>Фон делается прозрачным (а иногда и полупрозрачным) в экспортируемом файле, если соответствующая опция включена в диалоге экспорта, а формат выбран такой, который эту прозрачность поддерживает.>

Мне в KMZ надо, но там только для PNG прозрачность фона есть, но в PNG получается в 3 раза больше KMZ, чем в JPG. Нельзя ли как-то обеспечить и небольшой размер архива и прозрачность фона для KMZ экспорта ?

2 seno > Да, спасибо, я до этого доходил тоже не сразу, когда обрезку границ делал .
Кстати, насчет текущей (или как ее справка называет Global'ной ) проекции - а почему километровая сетка в GM не показывается в WGS84 ?

[Moskus]

Нет, не одно и то же. Датум посмотреть - элементарно. Сначала удостовериться, что в Configuration - General в Miscelaneous Advanced Options стоит галка "Include Datum Transformations in PRJ files" (если не стоит - поставить и нажать Apply). Потом пойти на закладку Projections, выбрать нужный датум, проекцию (для простоты) - Lat/Lon, а потом сохранить оттуда же PRJ-файл. И наслаждаться в нем вот такой секцией: TOWGS84[28,-130,-95,0,0,0,0] Это и есть параметры перехода в форме, в которой их диктует хранить формат PRJ/WKT. Правильно, в JPEG прозрачность не хранится, только в PNG, а TIFF в KMZ не всё понимает. Потому ради экономии места, надо распаковать KMZ-файлик (это ZIP-архив просто), вынуть из него все PNG (которые будут 24-битными с 8-битным каналом прозрачности) и любой подходящей утилитой для оптимизации и сжатия PNG (например - improved pngnq, http://pornel.net/pngnq ) сделать их 8-битными с 8-битной прозрачностью. При желании, можно придумать, как заменить полноценный альфа-канал (прозрачность) на однобитный ключевой цвет. Утилиты "в один клик" не припомню, но средствами imagemagick это в любом случае реализуемо, возможно - в несколько шагов. <noindex></noindex>

[kefi]

2 Moskus> А ну вот - спасибо. Теперь можно и посмотреть. Смотрим и что оказывается? Тот DATUM, что предлагал seno для коррекции привязки карты в точности соответствует тому, что было в DATUM'е до его коррекции :

Это то, что встроено :
PROJCS["Transverse_Mercator",GEOGCS["Geographic Coordinate System",DATUM["PULKOVO",SPHEROID["Krassovsky",6378245,298.3000003760163],TOWGS84[28,-130,-95,0,0,0,0]],
PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],
PARAMETER["scale_factor",1],PARAMETER["central_meridian",39],PARAMETER["latitude_of_origin",0],
PARAMETER["false_easting",7500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Это то, что дал seno и что так замечательно скорректировало карту :
PROJCS["Transverse_Mercator",GEOGCS["Geographic Coordinate System",DATUM["S-42_OLD",SPHEROID["Krassovsky",6378245,298.3000003760163],TOWGS84[28,-130,-95,0,0,0,0]],
PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],
PARAMETER["scale_factor",1],PARAMETER["central_meridian",39],PARAMETER["latitude_of_origin",0],
PARAMETER["false_easting",7500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

Отличий нет - вопрос ПОЧЕМУ ?

А насчет "вынуть из него все PNG (которые будут 24-битными с 8-битным каналом прозрачности)"
Дело в том , что KMZ готовится несколько часов и соответственно включает несколько сотен тайлов для Google Earth. Как вынуть нужные ?
Чей-то как-то работа эта становится невероятно трудоемкой ....

А нельзя все-таки как-то отдельные полигональные куски сделать имеющими прозрачные края - т.е. те площади, что дополняют полигон до соответсвующего описывающего его прямоугольника?

PS
2 seno> Хотел тут еще добавить насчет экспорта в GM - он делается во всяком случае для WEB экспорта в KMZ это так, НЕ в текущем DATUM'е, а ВСЕГДА в WGS84, т.е. том , что требуется для Google Earth.

<noindex></noindex>

[Moskus]

Простейший корректный алгоритм, делающий средствами ImageMagick из PNG с alpha-каналом PNG с ключевым цветом - такой (исхожу из того, что фон карты - белый, т.е. бумага)
- уменьшить яркость на единицу (чтобы в изображении не было цвета #FFFFFF)
- сделать все пиксели фона белыми (convert с параметром -background White)
- убрать прозрачность (convert с параметром -alpha off)
- сконвертировать это в 8-битный PNG (через pngnq)
- присвоить ключевой цвет белому (ключ -transparent-color )

<noindex></noindex>

[seno]

Moskus, Спасибо! Сам себе удивляюсь как могу так долго тупить глядя на кнопку с понятным названием. Но лучше не знать. Не знаешь, спокойно спишь :) И правда, почему встроенный PULKOVO 42 абсолютно совпадает по тексту с S-42_Old, но картинки такие: http://s57.radikal.ru/i158/1111/c2/aca6 ... f Выход: WGS-84, Lat/Lon <noindex></noindex>

[Moskus]

Где-то в программе глюк, видимо. То есть датум там корректный, но возникает какая-то ошибка, вызывающая сдвиг.

Еще рекомендую посмотреть, что скажет gdalinfo про растры, сохраненные с этими датумами в GeoTIFF.

<noindex></noindex>

[seno]

2 kefi
>> насчет текущей (или как ее справка называет Global'ной ) проекции - а почему километровая сетка в GM не показывается в WGS84 ?
Не понял вопрос. Видимо речь идет о проекции Lat/Lon и её родственных? Если так, то раз карта привязана в градусной сетке, только градусная и показывается. Километровая будет очень неравномерной.

>>насчет экспорта в GM - он делается во всяком случае для WEB экспорта в KMZ это так, НЕ в текущем DATUM'е, а ВСЕГДА в WGS84, т.е. том , что требуется для Google Earth.
Других то вариантов нет. KMZ насколько понимаю чисто Гугловый формат с жестко заданными проекцией и датумом.


<noindex></noindex>

[kefi]

2 Moskus > А как Вы предлагаете "вынуть из него(KMZ) все PNG (которые будут 24-битными с 8-битным каналом прозрачности) " ?
Это программировать утилиту отдельную нужно ? Их же там много.

2 seno> Видимо речь идет о проекции Lat/Lon и её родственных? Если так, то раз карта привязана в градусной сетке, >
Да в Lat/Lon WGS84 . Но я , к сожалению , не понимаю этого, - что значит в градусной сетке привязана ? И что значит Проекция Широта/Долгота ? - это еще не понятней

[Moskus]

Чтобы вынуть PNG из KMZ, ничего программировать не надо - достаточно KMZ переименовать в ZIP и открыть архиватором.
Вся остальная процедура с конвертированием 24bit RGB + 8Bit Alpha в 8 bit paletted + key color требует написания cmd-скрипта (знать, как минимум, синтаксис команды FOR).
Правда, я уверен, что можно то же самое сделать через batch mode в фотошопе, или найти готовую утилиту, которая превращает прозрачные полноцветные PNG в индексные с ключевым цветом, но мне описанный выше подход ближе, потому и пишу про него.

<noindex></noindex>