Форум SAS.Планета

Если кого интересует, - почти ВСЕ карты ГГЦ 250/500/1000 - можно слить отсюда: http://smtm.lx10.net/torrents.html
Как вместе, так - и по-отдельности.
Меня интересовал квадрат М-38. Слил и склеил уже несколько районов. Белые поля вокруг рамки карты - убирал в Фотошопе. Создал простенький "макрос"-операцию. Делается и быстро, и удобно. Потом клеил квадраты в GM и резал ею же - на тайлы для SASPlanet. Там пришлось помучиться. Ибо границы квадратов не совпадают с границами тайлов. Т.е. - возможны накладки пустых и неполных тайлов. Нужно делать с захлестом и потом - вручную удалять пустые и неполные тайлы. У меня в GM получалось загрузить не более 2-х стандартных квадратов. Например: M-38-122 и M-38-123 плюс еще несколько "квадратиков" по бокам. Если кому нужно полное описание технологии с пояснениями - напишу... Склейки получились точными. Сделал 2 района области: z13,14,15,16,17...

на интересный материальчик наткнулся, делюсь

О подготовке карт ГГЦ
http://terraingis.ru/article/read/st_ggc.html

Пакет программ для подготовки растров
http://terraingis.ru/down/open/pacet_po ... aster.html

Подробная инструкция по привязке
viewtopic.php?f=2&t=1090&p=28254#p28254

http://nnm.ru/blogs/weber2005/karty-gos ... nstrukciya

Вот, собственно, ТУТ изложено подробно - КАК карты от "госгисцентра" подружить с программой SASPlanet
По всем вопросам - пишите в личку... Постараюсь ответить!

Написано хорошо, да плюс иллюстрации, однако, много лишней работы. Всё, что связано с Фотошопом, абсолютно лишнее, обрезку карт Global Mapper делает сам, причём в архивах с привязками, широко представленных на торрентах, есть готовые (но не совсем правильные) привязки специально для Global Mapper'а. То есть, если взять эти привязки (они в виде файлов *.gmw) и загрузить их в GM, то откроются соответствующие листы карт, и они будут уже обрезаны! "Не совсем правильность" этих привязок заключается в том, что сделаны они в Global Mapper'е, поэтому пиксельные координаты углов изображений (к которым привязываются координаты географические) там являются дробными числами. Это, во-первых, поправимо, а, во-вторых, не сильно страшно.

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

Тем более, что программы для автоматизации процесса уже есть.

Ничего не зная о программке ggcozi, я написал на vb свою аналогичную (почти) и стало просто интересно, какой алгоритм поиска углов рамки используют авторы. Я например ищу их за четыре прохода по сторонам карты, сравнивая с цветом фона (вернее самого светлого из четырех пикселей по углам изображения, для ГГЦ это Long -328966 или 250,250,250 в RGB; за минусом порогового значения, чтобы случайно не принять за край карты мусор) используя нативные функции из gdiplus.dll
Читал в этой ветке про способ поиска по готовым паттернам углов, но так делать не стал. Просто некоторые листы ggcozi отказывается привязывать, просто расставляя метки по углам изображения; по скорости работы наши софтины практически одинаковые.
Сравнивая результат своей работы с готовым архивом привязок заметил, что на многих листах километровок точки привязки полностью совпадают, хотя у меня случаются 1/50 выпады на местах карт, где изображение (например дороги) вызезает за рамку карты.
И еще, так и не понятно, какой алгоритм использует Озик для рассчета MM1B

ПС Никто смотрю не заморачивается с генерацией номенклатуры 200000 и 300000 )))

KeyPassed писал(а):И еще, так и не понятно, какой алгоритм использует Озик для рассчета MM1B

Когда-то я исследовал этот вопрос и разработал следующий алгоритм:
http://forum.poehali.net/index.php?boar ... eadid=9586

Shoorick, я как раз и выбрал ваш алгоритм, вам большое спасибо!
LatMid = (LatBeg + LatEnd) / 2) * (pi / 180) ' широта по середине карты
E2 = ((a ^ 2) - (b ^ 2)) / (a ^ 2)
V = a / (1 - (E2 * (Sin(LatMid) ^ 2) ^ 0.5))
xZap = V * Cos(LatMid) * Cos(CDbl(LonBeg) * pi / 180)
yZap = V * Cos(LatMid) * Sin(CDbl(LonBeg) * pi / 180)
xVos = V * Cos(LatMid) * Cos(CDbl(LonEnd) * pi / 180)
yVos = V * Cos(LatMid) * Sin(CDbl(LonEnd) * pi / 180)
'hd = sqrt((x_вост-x_зап)^2 + (y_вост-y_зап)^2) - расстояние между краями
hd = ((xVos - xZap) ^ 2 + (yVos - yZap) ^ 2) ^ 0.5
MM1B = hd / RezWidth

Но в результате, соотношение метры/точки измеренное по горизонтали выходит например 0.689890 против 0.687429 у ozi, и я уже думал плюнуть на эти вычисления (ведь озик пересчитает его все равно потом), но потом оставил.
Кстати, в свою прогу добавил очистку фона (и вообще всех пикселей светлее фона) на белый #ffffff, но она еще кривая как оглобля, никак не могу победить выпады привязки..

KeyPassed писал(а): никак не могу победить выпады привязки..

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

p/s/ мой метод вроде за счет поиска максимально черного угла и минимально белого куска внутри него - дает как раз 1% ошибок.
Я
1) ищу угол
2) перебираю вглубь от него паттерн 3x3 и ищу максимум еще одной корреляционной функции.

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

KeyPassed писал(а):Но в результате, соотношение метры/точки измеренное по горизонтали выходит например 0.689890 против 0.687429 у ozi, и я уже думал плюнуть на эти вычисления (ведь озик пересчитает его все равно потом), но потом оставил.

Можем попробовать улучшить результаты. С тех пор прошло 5 лет. Вот здесь http://www.trekbuddy.net/forum/viewtopic.php?p=32332 тоже обсуждали разные формулы, включая мою.
Там есть ответ от Des Newman (автор Ozi), который советует считать этот параметр не между левым и правым краями карты, а между двумя точками: левее центра карты на 50 пикселей, и правее на 50 пикселей.
"Do not use mercator meters to calculate the meters per pixel.
At the center of the map use the map calibration to obtain 2 positions (lat/lon) in an east west direction say 100 pixels apart. Calculate the distance between
the positions in meters and divide by the number of pixels.
You could even convert the positions to UTM grid and calculate the difference in the eastings."

Здесь тоже самое объясняется иными словами: http://sourceforge.net/p/mobac/patches/11/
В результате это решение работает теперь в Mobile Atlas Creator.
Можете попробовать. Та утилита, которую писал я для генерации MAP файлов, решала разовую задачу и давно неактуальна.