пятница, 29 июня 2007 г.

четверг, 28 июня 2007 г.

Google Mapplets: Начинаем работу

Итак, мы прочитали статью Google Mapplets: Концепция и примеры. Введение или ее оригинальный вариант на сайте Google, теперь хотим сделать что-нибудь сами. Разумеется, не для своей учетной записи в Google, а в общем доступе на своем сайте :-D Я не буду разделять маплеты и просто Google Maps API, хотя это не одно и то же, но из маплета можно скопировать код в обычную веб-страничку, также можно код Google Maps API оформить как маплет (не всегда, об этом пойдет речь в последней статье цикла). Будем просто рассматривать способы создания нужных нам приложений, а для удобства я использую название "маплет" как для кода Google Maps API в веб-страницах, так и для Google Mapplets. В тех случаях, когда речь будет идти исключительно о технологии Mapplets мы будем пользоваться термином "настоящий" маплет.

Первым делом нам нужно получить некий ключ, который позволит запускать маплеты со своего сайта. Дело в том, что скрипт, обслуживающий маплеты, проверяет этот самый ключ и если URL директории с маплетом не соответствует ключу, маплет не запускается. Правда, Вы можете скачать сам скрипт (http://maps.google.com/maps?file=api&v=2&key) и отключить в нем проверку ключа сайта (проверяется значение переменной GValidateKey), но будем надеяться, что Вы этого не сделаете, а отправитесь на страничку Google Maps API - Sign Up и честно получите ключ для своего сайта. На мой взгляд, условия использования довольно либеральные (полмиллиона просмотров в сутки, 50 тысяч запросов на геокодирование, общий доступ к сайту, не менять логотип на карте). Достаточно указать URL директории, в которой Вы планируете размещать маплеты и гугл сообщит Ваш ключ и предложит пример маплета, который вы можете тут же сохранить на Вашем сайте и насладиться работой своего первого маплета.
Заглянул на страничку с правилами для корпоративного использования, там все туманно, но есть одна "зацепка" - корпоративная лицензия стоит от 10 тысяч долларов в год. Немало, но паршивая карта Москвы (в формате MapInfo, с откровенно кривой топологией и атрибутикой в отдельных слоях) обойдется существенно дороже. Притом с условием использования только для одного клиента... А тут весь мир на карте. Есть о чем задуматься. А поскольку я очень "люблю" Роскартографию (притом взаимно, впрочем, я-то им ничего плохого не делал, а вот они мне...), то надеюсь, что Вы задумаетесь.

Зная то, о чем я Вам сейчас рассказал, нетрудно разместить пример из предыдущей статьи на своем сервере. Замечу мимоходом, что русский язык поддерживается, надписи на карте выводятся как им положено. Я использовал кодировку веб-страницы cp1251 (charset=windows-1251). Во избежание изматывающей дискуссии о том, какая кодировка "правильнее", попробовал вот так:
cat hello.html |iconv -f cp1251 -t utf8 >hello_u.html
и заменил в коде странички charset=windows-1251 на charset=utf-8. И в этом случае все работает правильно, на чем тему кодировок позвольте считать закрытой.

А теперь сделаем страничку чуть сложнее, добавив элементы управления и метку с надписью. Получили вполне информативную картинку, которую можно использовать на своем сайте (ну, например, чтобы друзья не забывали, где Вы живете - в наш век интернет случается и такое). Код странички простой, можете сами посмотреть, а координаты метки хранятся в файле data2.xml, расположенном в одной директории с файлом странички (да, свалка получается, надо будет переложить, но идею Вы поняли). Вот содержимое этого файла:

<markers>
<marker lat="56.2889" lon="43.940491"/>
</markers>


Вот так выглядит Javascript код:

function load() {
if (GBrowserIsCompatible()) {
var map = new GMap2(document.getElementById("map"));
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.setCenter(new GLatLng(56.2889, 43.940491), 12);

var infoTabs1 = [
new GInfoWindowTab("Центр города",
"Эту точку гугл эф считает центром Нижнего Новгорода"),
];

GDownloadUrl("data2.xml", function(data) {
var xml = GXml.parse(data);
var markers =
xml.documentElement.getElementsByTagName("marker");
var point1 = new GLatLng(
parseFloat(markers[0].getAttribute("lat")),
parseFloat(markers[0].getAttribute("lon")));
var marker1=new GMarker(point1);
map.addOverlay(marker1);

GEvent.addListener(marker1, "click", function() {
marker1.openInfoWindowTabsHtml(infoTabs1);
});
marker1.openInfoWindowTabsHtml(infoTabs1);

});
}
}


Для отображения нескольких точек и подписей к ним несложно расширить наш пример, это я предоставляю Вам, чтоб не скучно было.

Отлично, карта готова и ее может увидеть каждый посетитель Вашего сайта. Теперь Вы можете оформить созданный код в маплет и пользоваться им как кирпичиком при построении сайтов. Можно даже предоставить всем желающим этот "строительный элемент", если только Google сочтет его достойным внимания и включит в свой каталог.

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

В следующий раз мы научимся оформлять карту и добавлять к ней разные "фишки". Итак, читайте
Google Mapplets: Концепция и примеры. Практикум.

Google Mapplets: Концепция и примеры. Введение

Оригинальный документ находится по адресу
http://www.google.com/apis/maps/documentation/mapplets/.

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


Маплеты (Google Mapplets) это мини-приложения, которые можно встраивать в сайт, использующий технологию Google Maps. Примеры использования включают в себя поиск местоположения, отображение текущей погоды и измерение дистанции. Маплеты представляют собой набор инструментов, которые предоставляет Вам Google для управления картой путем программирования на Javascript вызовов Google Maps API.
Маплеты пока доступны только в предварительной версии для разработчиков Google Maps по адресу
http://maps.google.com/preview

Сегодня маплеты новинка, в которой могут быть обнаружены ошибки, документация также еще далека от идеала. Желающие могут присоединиться к группе обсуждения Maps API, внеся свой вклад в дальнейшее развитие представленной технологии.

Для кого написано это руководство

Статья рассчитана на JavaScript программистов, понимающих идеи объектно-ориентированного программирования. Маплеты это набор совместно используемых инструментов, так что не забывайте заглядывать в документацию по Google Gadgets API. Если Вы уже хорошо знакомы с Google Maps API, можете сразу перейти к разделу "Отличия маплетов от стандартного картографического API".

Что такое маплеты

Маплеты это небольшие веб-странички, размещаемые в элементе IFrame на сайте Google Maps. Вы можете разместить на этих страничках все то же, что и на обычных, включая HTML, Javascript и Flash. Google обеспечивает Javascript API, предоставляющий маплетам доступ к сервисам управления картой, получения контента из другого источника и сохранения настроек пользователя.
Когда пользователь публикует маплет, сервера Google's запрашивают исходный код маплета с Вашего вебсервера и потом публикуют его копию на сайте gmodules.com. Для уменьшения нагрузки на Ваш сервер сайт gmodules.com будет кэшировать исходный код в течении нескольких часов.

Основные средства разработчика

Прежде чем Вы начнете разрабатывать маплеты, перейдите к секции "Developer Tools" в директории Mapplets Content Directory и возьмите следующие утилиты:
Developer Mapplet: После установки утилиты в каждом запущенном маплете появится ссылка "Reload", которая позволит Вам отключить автоматическое кэширование исходного кода Ваших маплетов.
Mapplet Scratch Pad: Утилита обеспечивает возможность интерактивно писать код маплета и немедленно видеть результат выполнения. Вы можете скопировать и вставить код любого из примеров в Scratch Pad.

Очень простой маплет "Здравствуй, мир!"

Поскольку все маплеты представляют собой Google Gadgets, мы начнем с написания спецификации маплета, которая представляет собой XML-код с метаданными. Отображаемый пользователю HTML размещается в тэге , в котором Вы можете разместить любой HTML-код так же, как Вы это делаете на своих веб-страницах.

Нижеследующий пример отобразит надпись "Здравствуй, мир!" в левой панели.

<?xml version="1.0" encoding="UTF-8"?>
<Module>
<ModulePrefs title="Hello World"
description="The Hello World of Gadgets"
author="Your name"
author_email="your-email@gmail.com"
height="150">
</ModulePrefs>
<Content type="html"><![CDATA[

<h2>Здравствуй, мир!</h2>

]]></Content>
</Module>

Теперь добавим это описание в наш маплет. Инструкция внутри тэга обеспечит загрузку Mapplets Javascript API, необходимого для работы с картой.
В тэге добавим некоторый Javascript код, который обращается к этому API. Первая строка var map = new GMap2() создаст указатель на главную карту, вызов методов которого позволяет управлять объектом карта аналогично тому, как это делается с помощью вызовов Google Maps API.

Пример ниже уменьшает изображение и добавляет метку на карту с подписью "Привет, мир!".

<?xml version="1.0" encoding="UTF-8"?>
<Module>
<ModulePrefs title="Hello World"
description="The Hello World of Mapplets"
author="Your name"
author_email="your-email@gmail.com"
height="150">
<Require feature="sharedmap"/>
</ModulePrefs>
<Content type="html"><![CDATA[

<h2>Привет, мир!</h2>

<script>
// Center the map in the Mediterranean and zoom out to a world view
var map = new GMap2();
var point = new GLatLng(37.71859, 6.679688);
map.setCenter(point, 2);

// Add a marker to the center of the map
var marker = new GMarker(point);
map.addOverlay(marker);

// Open a "Hello World" info window
var message = "Hello World!";
marker.openInfoWindowHtml(message);
</script>

]]></Content>
</Module>


Публикация и установка маплета

После создания маплета необходимо сохранить его на общедоступном сайте. Если у Вас нет своего собственного сайта, мы рекомендуем Вам попробовать Google Page Creator. Только не используйте визуальный HTML редактор! Вместо этого воспользуйтесь опцией загрузки файла в разделе Site Manager (ссылка на загрузку расположена справа). Потом кликните на имени загруженного файла в секции загруженных элементов, чтобы узнать полный адрес файла на сайте.
Для установки маплета перейдите в директорию маплетов (Mapplets Directory) и щелкните ссылку "Add by URL", расположенную после кнопки "Search Google Maps Content" вверху страницы. Введите URL Вашего маплета и нажмите кнопку "Add". Теперь Ваш маплет будет доступен на вкладке "Mapplets", когда Вы вернетесь к Google Maps.
Примечание: вышеописанный способ установит маплет только для вашей учетной записи, маплет не будет опубликован для всех пользователей. Если Вы хотите с кем-то поделиться Вашим маплетом, необходимо переслать ему URL Вашего маплета.

Размещение Вашего маплета в каталоге

Для размещения Вашего маплета в каталоге используйте эту ссылку. Наша задача заключается в заполнении каталога высококачественными маплетами, полезными и интересными для пользователей. Мы выберем только лучшие из присланных нам маплетов.

Подводим итоги

Введение мы прочитали (если нет, советую все же это сделать, согласитесь, теорией я Вас не утомляю), в оригинальной документации еще много чего написано, но пора бы уже и самим что-то сделать, а оригинал продолжим читать в другой раз. Итак, займемся размещением карты на своем сервере. Если честно, прочитав англоязычное описание технологии, я сам многое не понял, но это не беда, в следующей статье я расскажу Вам, что же именно я не понял. Комментарии добавлять и переделывать текст я не стал, раз уж назвал переводом, пусть так и будет. Итак, читайте:
Google Mapplets: Начинаем работу.

вторник, 19 июня 2007 г.

GPSBabel: загрузка и получение данных с GPS-приемника и преобразование формата

GPSBabel преобразует путевые точки (waypoints), трэки (tracks) и маршруты (routes) из одного формата в другой, поддерживая стандартные картографические форматы (common mapping format), включая Delorme, Streets and Trips, а также COM-порт и USB загрузку и выгрузку для GPS приемников, таких как Garmin и Magellan. Программа позволяет легко загрузить нужные данные в GPS приемник или получить данные с приемника. Также есть функции пространственного анализа и возможна работа в режиме реального времени (в связке с Google Earth).

GPSBabel работает со следующими форматами:
Cetus, CoPilot Flight Planner, CSV, Custom CSV, Delorme Street Atlas, Delorme Street Atlas 2004 Plus, Delorms GPS Log, Delorme routes, DNA, EasyGPS Binary, Fugawi, Garmin serial, Geocaching.com loc, GeocachingDB, Geoniche, GPilotS, GPSDrive, GPSman, GPSPilot, gpsutil, GPX, Holux, IGC, Magellan serial, Magellan SD, Magellan Navigator Companion, Mapopolis.Com Mapconverter, Mapsend, Mapsource, Maptech, Microsoft Streets and Trips, Navicache, Netstumbler, NIMA/GNIS Geographic Names, NMEA sentences, OziExplorer, PalmDoc, PCX5, PocketStreets 2002 Pushpin, PSITrex, Quovadis, Tab-separated data, Tiger, TopoMapPro, Topo by National Geographic, xcsv, xmap, xmapwpt.

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

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

Программу скачать можно, перейдя по ссылке с официального сайта
www.gpsbabel.org

Пространственный анализ
Вот чрезвычайно интересная статья, которая показывает, как можно делать пространственный анализ с помощью gpsbabel (построение буфера, пространственная фильтрация, ...)
GPSBabel, Google Earth, and GPX Sonar

Обработка трэка в реальном времени
Есть еще одна интересная возможность, которая еще только разрабатывается, но тем не менее может быть полезна и сейчас - потоковое преобразование входных данных (опция -T). Если у Вас есть навигатор или другой источник координат в формате Garmin's PVT или NMEA и Вы хотите получить данные в формате KML, воспользуйтесь следующей командой:
gpsbabel -T -i garmin -f usb: -o kml -F xxx.kml
В результате выполнения программа будет считывать данные с подключенного к USB порту приемника Garmin и автоматически перезаписывать файл 'xxx.kml', что позволяет подключить этот файл как обновляемую сетевую ссылку (self-refreshing network link) в Google Earth.
Дополнительные форматы будут добавлены позднее.

Примечание: работает только в версиях GPSBabel начиная с 1.3.1 (текущая разрабатываемая версия 1.3.3).

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


P.S. Рекомендую почитать о работе с GPSBabel вот здесь:
Making GPX Tracks (From OpenStreetMap)


Примечание. Для ограничения числа точек в создаваемом трэке можно использовать ключ -x:
gpsbabel -i google -f yourfile.htm -x simplify, count=30 -o garmin -F com1:

воскресенье, 17 июня 2007 г.

PostGIS: Пространственный анализ в PostGIS с использованием множества координатных систем

В случае, если мы хотим воспользоваться функциями пространственного анализа в PostGIS, особых сложностей не возникает. Другое дело, если необходимо “на лету” выполнять различные трансформации координат. Рассмотрим следующий случай: в таблице house хранится пространственная информация в градусах WGS84 (идентификатор системы координат 4326), а мы ищем объект, заданный координатами в Пулково 1942-го года (идентификатор системы координат 28408).

Описания координатных систем хранятся в таблице spatial_ref_sys, по SRID=4326 можно найти информацию о мировой системе координат, а по SRID=28408 - российской. По умолчанию все координаты имеют SRID=-1, например: GeometryFromText('POINT(43 56)',-1) - точка с неопределенной системой координат. Функцией SETSRID можно указать систему координат, при этом просто меняется идентификатор SRID в записи, но никаких вычислений не происходит. Пересчет координат из одной системы координат в другую выполняет функция transform, при этом изменяется как числовое значение координаты, так и размерность (градусы, метры, футы, ярды и проч., в зависимости от принятого в текущей координатной системе). Выражение transform( SETSRID(GeometryFromText('POINT(43 56)',-1),4326), 28408 ) задает для точки 'POINT(43 56)' мировую систему координат (4326) функцией SETSRID и вычисляет координаты точки в российской системе (28408).

Далее предполагается, что наблюдатель 1 располагается в первой точке и обладает сферой видимости 100000 метров, а наблюдатель 2 расположен в точке 2 и имеет такую же сферу видимости.

Задача 1:
Поиск всех объектов в радиусе 100000 метров в российской системе координат Пулково 1942-го года от наблюдателя, расположенного в точке POINT(43 56), заданной в мировой системе координат, с выводом результата в мировой системе:
SELECT the_geom FROM house
WHERE
distance(
transform( SETSRID(the_geom,4326), 28408 ),
transform( SETSRID(GeometryFromText('POINT(43 56)',-1),4326), 28408 )
) < 100000;

Задача 2:
Поиск всех объектов в радиусе 100000 метров в российской системе координат Пулково 1942-го года от наблюдателя, расположенного в точке POINT(43 56), заданной в мировой системе координат, с выводом результата в российской системе:
SELECT transform( SETSRID(the_geom,4326), 28408 ) FROM house
WHERE
distance(
transform( SETSRID(the_geom,4326), 28408 ),
transform( SETSRID(GeometryFromText('POINT(43 56)',-1),4326), 28408 )
) < 100000;

Задача 3:
Поиск всех объектов в радиусе 100000 метров в российской системе координат Пулково 1942-го года от наблюдателя, расположенного в точке POINT(8434555.38952802 6235317.6754922), заданной в российской системе координат, с выводом результата в российской системе:
SELECT transform( SETSRID(force_3d(the_geom),4326), 28408 ) FROM house
WHERE
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT(8434555.38952802 6235317.6754922)',-1),28408 )
) < 100000;

Задача 4:
Поиск всех объектов в радиусе 100000 метров в российской системе координат Пулково 1942-го года от наблюдателя, расположенного в точке POINT1=POINT(8434555.38952802 6235317.6754922), которые исчезнут из поля зрения при перемещении наблюдателя в точку POINT2=..., заданных в российской системе координат, с выводом результата в российской системе:
SELECT transform( SETSRID(force_3d(the_geom),4326), 28408 ) FROM house
WHERE
not
(
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT2',-1),28408 )
) < 100000
and
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT1',-1),28408 )
) < 100000
)
and
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT1',-1),28408 )
) < 100000;

Задача 5:
Поиск всех объектов в радиусе 100000 метров в российской системе координат Пулково 1942-го года от наблюдателя, расположенного в точке POINT1=POINT(8434555.38952802 6235317.6754922), которые появятся в поле зрения при перемещении наблюдателя в точку POINT2=..., заданных в российской системе координат, с выводом результата в российской системе:
SELECT transform( SETSRID(force_3d(the_geom),4326), 28408 ) FROM house
WHERE
not
(
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT2',-1),28408 )
) < 100000
and
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT1',-1),28408 )
) < 100000
)
and
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT2',-1),28408 )
) < 100000;

Обсуждение: в примерах 4-5 выражение
(
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT2',-1),28408 )
) < 100000
and
distance(
transform( SETSRID(the_geom,4326), 28408 ),
SETSRID(GeometryFromText('POINT1',-1),28408 )
) < 100000
)
задает объекты, входящие в сферу видимости обоих наблюдателей. Соответственно, объекты сферы видимости первого наблюдателя, не входящие в общую сферу видимости, пропадают из поля зрения (пример 4), а входящие в сферу видимости второго наблюдателя, не входящие в общую сферу видимости – появляются в поле зрения при перемещении наблюдателя из позиции 1 в позицию 2. Естественно, если сферы видимости обоих наблюдателей не перекрываются, решение задачи принимает вырожденный вид согласно примеру 3.

суббота, 16 июня 2007 г.

Google Earth: конвертация в формат KML шейпфайлов (shp) и трэков (nmea, gpx)

Недавно захотелось посмотреть некоторые трэки на карте Google Earth, для чего я начал искать способ конвертации шейпфайлов в формат KML, который можно открыть в этой программе. Оказалось, что все не так просто, хотя проще, чем кажется :-) Вариантов много, начиная от модулей к ESRI ArcView и другим ГИС и вьюверам и заканчивая отдельными утилитами. Вот как раз последние меня и интересовали.

Библиотека GDAL/OGR поддерживает формат KML, только нужно брать и компилировать исходники из CVS-репозитория. Или скачать уже скомпилированные. Например, можно использовать пакет программ FWTools (скомпилирован для Windows и Linux).

ogr2ogr -f KML track.kml track.shp

А вот так можно преобразовать из формата GPX:

gpx2shp -t track.gpx
ogr2ogr -f KML track.kml track_trk.shp

Здесь ключ -t у тилиты gpx2shp означает, что нужно конвертировать только трэк, при этом к названию файла добавляется постфикс _trk. В моем случае в шейпфайле содержится именно трэк и этот ключ не обязателен, но так мы точно знаем, что получится в результате конвертации. Если ключ не указывать, постфикс не добавляется.

А так из формата NMEA:

gpsbabel -t -i nmea -o gpx track.nme track.gpx
gpx2shp -t track.gpx
ogr2ogr -f KML track.kml track_trk.shp

Вот так выглядит трэк, открытый в Google Earth.


Файлы примера можно взять здесь.

Документацию по формату KML можно почитать здесь. Я сам с удивлением узнал, что можно не только векторные , но и растровые слои добавлять (см. "Ground Overlays"). Правда, только в формате JPEG, даже TIFF не поддерживается, но дареному коню...
Интересно, как преобразовать из tiff или jpeg файлов с геопривязкой в формат KML, если мне об этом вопросы будут задавать, посмотрю :-)

Раз уж я залез на сайт с документацией, бегло пробегусь по ней. Итак, что мы имеем на сегодня.

Предусмотрена возможность получать KML-файлы из сети. Эту функцию гугл окрестил "Network Links".
Кроме того, можно создавать KML-файлы "на лету", указав URL скрипта, который генерирует KML-файл по запросу, см. "CGI Scripting for KML".
Но это все привычно, в сущности, какая разница программе, получить статичный или динамически созданный файл, с сервера или с жесткого диска. А вот функция формирования динамического запроса к серверу позволит в полной мере реализовать потенциал, заложенный в методе динамической генерации KML-файлов.

Что ж, очень даже неплохо, можно реализовывать полнофункциональные клиентские приложения, притом, что труд создания вьювера взял на себя Гугл, да еще и космоснимками обеспечил на всю территорию планеты.

Еще нашел способ конвертации из NMEA или GPX напрямую в KML, правда, размер файла получается намного больше, но открывается быстро. Как я посмотрел в самом файле, там сделано красивое форматирование :-) А на самом деле, gpsbabel создает файл KML с гипертекстовым комментарием для каждой точки (скорость, координаты и проч.), что и увеличивает объем получаемого файла.

gpsbabel -t -i nmea -o kml track.nme test.kml

Такое вот приятное открытие, что gpsbabel из Debian Etch умеет и с KML работать.

Примечание: gpsbabel доступна для платформ Microsoft Windows 95, 98, ME, 2000, XP, а также для POSIX операционных систем, таких, как Linux, UnixWare, OpenServer, Solaris, FreeBSD, OSX.
Подробное описание программы gpsbabel см. здесь.

Mapserver: Использование библиотеки OGR

Документ содержит информацию об использовании в картсервере векторных источников данных, поддерживаемых библиотекой OGR.
Последнее обновление: 14-11-2004

Введение

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

Далее предполагается, что вы:

  • Уверенно разбираетесь в проектах для картсервера и особенно в настройке файла проекта.

  • Имеете навыки компиляции и нуждаетесь в компиляции собственной версии картсервера с поддержкой OGR.



Что такое OGR?

Библиотека простых функций OGR это написанная на C++ библиотека с открытым исходным кодом (а также набор утилит командной строки), обеспечивающая чтение (в некоторых случаях и запись) различных форматов векторных данных, включая шейпфайлы ESRI и MapInfo mid/mif и TAB файлы.

Зачем нужно использовать OGR в картсервере?

Библиотека простых функций OGR позволяет картсерверу отображать различные векторные данные, представленные в их собственном формате. Например, MapInfo Mid/Mif и TAB нет необходимости конвертировать в ESRI шейпфайлы, если используется поддержка OGR в картсервере.

Какие форматы данных поддерживаются?

Самый свежий список поддерживаемых форматов доступен по адресу http://ogr.maptools.org/ogr_formats.html. В момент подготовки текущего документа, поддерживались следующие форматы:

  • Покрытия ArcInfo,

  • ESRI шейпфайлы,

  • FMEObjects Gateway (шлюзы),

  • IHO S-57 datasets (наборы данных),

  • MapInfo TAB и MIF/MID files,

  • Microstation DGN файлы,

  • OGDI векторы,

  • Oracle Spatial,

  • PostgreSQL,

  • SDTS TVP (Topological Vector Profile and Point Profile datasets – наборы данных топологических векторных профилей и точечных профилей),

  • TIGER/Line наборы файлов,

  • UK.NTF (National Transfer Format – национальный протокол передачи).


Примечание1: Некоторые из перечисленных выше форматов (в частности, OGDI) имеют внешние зависимости и не всегда включаются в готовые бинарные дистрибутивы картсервера с поддержкой OGR.

Примечание 2: Некоторые из перечисленных выше форматов не поддерживают возможность произвольного доступа к данным, в частности, это верно для MapInfo MIF/MID файлов, которые представлены в текстовом формате и при их использовании для веб-приложений производительность системы будет очень низкой. С другой стороны, некоторые бинарные форматы, в частности, MapInfo TAB предоставляют произвольный доступ и при их использовании достигается высокая производительность, сравнимая с получаемой при использовании шейпфайлов.

Где можно узнать больше о проекте OGR

Более подробная информация о проекте OGR доступна по адресу http://www.gdal.org/ogr/

Mapserver: растры (перевод)

Растры

В документе рассказывается о методах работы с растрами, используя картсервер
Последнее обновление: 14/11/2004


Введение

Картсервер поддерживает отрисовку растров множества различных форматов. Ниже перечислены некоторые из поддерживаемых форматов и приведены рекомендации по работе с ними.

Далее предполагается, что вы разбираетесь в настройках файла проекта, но еще не знакомы со специфичными аспектами использования растровых данных.

Как добавить растр в файл проекта?

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

LAYER
NAME "JacksonvilleNC_CIB"
DATA "Jacksonville.tif"
TYPE RASTER
STATUS ON
END

Кроме указанных инструкций, растры поддерживают также директивы PROJECTION, METADATA, PROCESSING, MINSCALE, и MAXSCALE информацию. Растровые слои не могут содержать подписей, запросов, директив CONNECTION, CONNECTIONTYPE, или FEATURE информации.

Классификация растров

Растры могут классифицировааться подобно векторным данным, однако с некоторыми исключениями. Значение CLASSITEM всегда указывается в пикселах, что указывается специальной строкой "[pixel]" (обязательно в нижнем регистре). Следующий пример демонстрирует растровый слой с простой схемой классификации.

LAYER
NAME "JacksonvilleNC_CIB"
DATA "Jacksonville.tif"
TYPE RASTER
STATUS ON
CLASSITEM "[pixel]"
CLASS
EXPRESSION ([pixel] < 64)
COLOR 0 0 0
END
CLASS
EXPRESSION ([pixel] >= 64 AND [pixel] < 128)
COLOR 255 0 0
END
CLASS
EXPRESSION ([pixel] >= 128 AND [pixel] < 196)
COLOR 0 255 0
END
CLASS
EXPRESSION ([pixel] >= 196 AND [pixel] < 256)
COLOR 0 0 255
END
END


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

Отметим, что только COLOR, EXPRESSION и NAME параметры используются для классификации растров, прочая же информация игнорируется [для классификации].

Поддерживаемые форматы

Список поддерживаемых растровых форматов в основном определяется настройками конфигурации. Если вы используете для отрисовки библиотеку работы с растрами GDAL, некоторые форматы являются втроенными.

Разнообразную информацию о библиотеке GDAL вы можете найти по адресу http://www.remotesensing.org/gdal , включая список поддерживаемых форматов supported formats list. Некоторые продвинутые возможности картсервера в работе с растрами, такие как топологическое преобразование, использование цветового куба RGB и автоматической проекции доступны только при работе с растрами через GDAL. GDAL обычно устанавливается и настраивается отдельно от картсервера, и подключяется через директиву компиляции –with-gdal. Список поодерживаемых GDAL форматов, кроме перечисленных ниже, также включает CEOs, DOQ, ECW, ESRI Labelled BIL, Arc/Info Binary Grid, OGDI и Erdas Imagine (.hfa).

Можно узнать о настройках компиляции картсервера, запустив его с ключом -v. Чтобы узнать о поддерживаемых GDAL форматах, используется команда gdal-config. Пример:

warmerda@gdal[103]% ./mapserv -v
MapServer version 3.5 (pre-alpha) OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
SUPPORTS=PROJ SUPPORTS=TTF INPUT=EPPL7 INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE
warmerda@gdal[104]% gdal-config --formats
gxf gtiff hfa aigrid aaigrid ceos ceos2 iso8211 sdts raw dted mem jdem
envisat elas ogdi gif jpeg png fits grass

Указанные форматы потенциально встроены в библиотеку GDAL:

  • TIFF/GeoTIFF: если картсервер собран с параметром INPUT=TIFF , в него уже встроена поддержка форматов TIFF или GeoTIFF. Встроенная поддержка TIFF формата имеет ограничения на устройство читаемых файлов (не разделенные (no tiled), 16bit, RGB, или нечетная цветовая модель (odd color models)). Этот драйвер поддерживает файлы привязки world files, или простые встроенные GeoTIFF координаты для геопривязки. Директива проецирования AUTO не поддерживается.
    Полнофункциональная поддержка TIFF/GeoTIFF доступна только через GDAL. Отметим, что только GDAL поддерживает разделенные (tiled) TIFF файлы и TIFF файлы с перекрытиями. Разделенные (tiled) TIFF файлы с перекрытиями, подготовленные заранее, один из лучших путей значительного повышения эффективности работы сервера с растровыми изображениями.

  • GIF: если GD собрана с поддержкой GIF (OUTPUT=GIF), картсервер также сможет читать GIF файлы для растровых слоев. Геопривязка GIF файлов может быть выполнена только с использованием файлов привязки (world file).
    Если GD не включает поддержку GIF, эта возможность может быть доступна через GDAL, который также поддерживает геопривязку через файлы привязки (world file).

  • PNG: Если GD собрана с поддержкой PNG (OUTPUT=PNG), картсервер также сможет читать PNG файлы для растровых слоев. Геопривязка PNG файлов может быть выполнена только с использованием файлов привязки (world file).
    Если GD не включает поддержку PNG, эта возможность может быть доступна через GDAL, который также поддерживает геопривязку через файлы привязки (world file).

  • JPEG: если картсервер включает встроенную поддержку JPEG (INPUT=JPEG) , то JPEG файлы в оттенках серого могут использоваться при отрисовке растровых слоев. RGB файлы (более продвинутый стандарт) не поддерживаются. Геопривязка JPEG файлов может быть выполнена только с использованием файлов привязки (world file).
    Если картсервер не имеет встроенной поддержки ффйлов JPEG, GDAL может работать с этим форматом. В этом случае RGB файлы также поддерживаются (через механизм цветового куба RGB). Геопривязка только с использованием файлов привязки (world file).

  • Erdas .LAN/.GIS: Iесли картсервер включает встроенную поддержку (INPUT=EPPL7) (по умолчанию), поддерживаются 8-битные Erdas LAN/GIS файлы. Файл .trl читается для получения цветовой схемы, и если не указан слой в оттенках серого. Информация о геопривязке размещается в самом файле .



Разделенные растры

Когда обрабатываются очень большие растровые файлы, значительное повышение производительности может быть достигнуто путем разделения исходного большого растрового изображения на множество маленьких картинок. Каждый файл является частью большой растровой мозаики, доступной для отображения. Список файлов мозаики может быть сохранен в шейпфайле с указанием координат границ каждого файла и имени файла. Такая запись называется TILEINDEX и работает аналогично соответствующему механизму для векторных файлов. Результат может быть описан в файле проекта как один слой, поскольку картсервер умеет автоматически сканировать файлы мозаики, перечисленные в шейпфайле и отображать только те из них, которые видны в текущем окне просмотра.

Ниже приведен простой пример. Инструкция DATA не требуется, поскольку картсервер найдет имена файлов мозаики в аттрибутивном столбце Location в файле hp2.dbf , соответствующем файлу hp2.shp, содержащему набор пересекающихся регионов. Полигоны в файле hp2.shp являются прямоугольниками, соответствующими границам файлов мозаики. Заметим, что файлы мозаики могут иметь разный размер, форматы могут отличаться и элементы мозаики могут перекрываться (последующие картинки отрисовываются поверх предыдущих); разумеется, все изображения должны быть в единой системе координат (проекции) со слоем.

LAYER
NAME "hpool"
STATUS ON
TILEINDEX "hp2.shp"
TILEITEM "Location"
TYPE RASTER
END

Существует множество способов создать шейпфайл мозаики TILEINDEX для использования согласно вышеописанному способу, один из путей состоит в использовании программы gdaltindex, входящей в комплект утилит GDAL. Программа gdaltindex автоматически создает шейпфайл мозаики из списка поддерживаемых GDAL растровых файлов, переданного в командной строке.

Использование:
gdaltindex [-tileindex field_name] index_file [gdal_file]*

eg.
% gdaltindex doq_index.shp doq/*.tif

Примечание:
o Шейпфайл (index_file) будет создан, если он еще не существует.
o Имена файлов мозаики по умолчанию сохраняются в столбце 'location'.
o Имена файлов мозаики сохраняются точно в том виде и в том порядке, в котором они указаны в командной строке.
o Простые прямоугольные полигоны создаются в координатной системе растров.

Программа gdaltindex может быть собрана как часть GDAL (не входит в пакет по умолчанию).

Проектирование растров

Картсервер может преобразовать GDAl растры в новую проекцию “на лету”. Не поддерживаемые GDAL растры могут быть только увеличены или уменьшены без поворотов или других искажений.

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

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

Обработка 24-битных RGB растров

Традиционно картсервер применяют для создания 8-бит псевдо-цветной карты, основанной на 8-бит картинки в оттенках серого или псевдоцветной. Таким образом, если растровый файл является 24-бит изображением (красный, зеленый и синий диапазоны), обычно используемый метод отрисовки не пригоден. Отрисовка 24-бит изображений поддерживается только через GDAL. Встроенные PNG, JPEG и другие драйверы не поддерживают вывод 24-бит изображений.

Если строится 8-бит псевдо-цветное изображение (параметр IMAGEMODE установлен как PC256 в соответствующей OUTPUT директиве), тогда полная 24-бит RGB картинка для отображения будет преобразована в карту цветов выходного изображения. По умолчанию используется цветовой куб. Он включает фиксированный набор из 175 цветов и поддерживает использование 5 уровней красного, 7 уровней зеленого и 5 уровней синего, и плюс к этому 32 оттенка серого. Растры отрисовываются “на лету” одним из цветов куба. Такой механизм ухудшает качество цветопередачи, особенно для изображений с плавными переходами цвета. Также можно использовать фиксированный набор из 256 цветов, что работает значительно быстрее.

Вариацией изложенного подхода является скользящее сглаживание в процессе отрисовки. Этот алгоритм вычисляет цвет пиксела исходя из цвета соседних. В случае однотонных участков изображения результат аппроксимации получается точнее, чем в предыдущем методе. Технология сглаживания может быть полезна не только для цветового куба, но и для заданной цветовой палитры. Сглаживание поддерживается библиотекой GDAL 1.1.9 или более новой, и активизируется директивой PROCESSING "DITHER=YES" в файле проекта. Отметим, что сглаживание требует больше ресурсов процессора чем простое использование цветового куба, в силу чего следует избегать использование этой технологии в тех случаях, когда важна производительность.

Кроме перечисленных возможностей, картсервер позволяет создавать 24-бит выходное изображение при использовании 24-бит исходного. По умолчанию директивы "IMAGETYPE png24" или "IMAGETYPE jpeg" могут использоваться для создания 24-бит PNG или JPEG изображения в отличие от стандартного 8-бит псевдо-цветного. Директива OUTPUTFORMAT обеспечивает полный контроль формата вывода. Опции IMAGEMODE RGB и IMAGEMODE RGBA создают 24-бит и 32-бит (24-бит плюс 8-бит альфа-канал/прозрачность) изображение для поддерживаемых форматов.

Специальные директивы обработки

Рассмотрим возможности использования ключевого слова PROCESSING в объекте LAYER. В основном эта опция используется для передачи специальных параметров обработки растров в библиотеку GDAL, выполняющую обработку растров. Перечислим некоторые из поддерживаемых опций.


DITHER=YES
Включает диффузионное размытие, используется при конвертации 24-бит изображения в 8-бит для лучшей цветопередачи.
Пример:
PROCESSING "DITHER=YES"


BANDS=red_or_grey[,green,blue[,alpha]]
Директива позволяет указать диапазон или диапазоны, которые будут выбраны из растрового файла. Если выбран один диапазон, изображение будет обработано так, как если бы оно было сохранено в оттенках серого. Если выбрано 3, они будут обработаны как красный, зеленый и синий цвет. Если выбрано 4, кроме того еще еще будет обработана прозрачность (альфа-канал).
Пример:
PROCESSING "BANDS=4,2,1"


SCALE[_n]=AUTO or min,max
Директива указывает библиотеке GDAL предварительно изменить цветовую шкалу. В основном используется для приведения 16-бит данных или с плавающей точкой к диапазону 0-255, но также может применяться для растяжения диапазона 8-бит данных. Если объявлены значения min/max, то исходные данные преобразуются так, что минимальное значение карты принимает нулевое значение, а максимальное становится равно 255. Если указана опция AUTO, вычисление min/max производится автоматически. Для управления шкалой индивидуального входного диапазона используйте ключи SCALE_1, SCALE_2 и SCALE_3 (для красного, зеленого и синего цветов) вместо ключа SCALE, который применяется ко всем диапазонам.
Пример:
PROCESSING "SCALE=AUTO"
или
PROCESSING "SCALE_1=409,1203"
PROCESSING "SCALE_2=203,296"
PROCESSING "SCALE_3=339,1004"

COLOR_MATCH_THRESHOLD=n
Управляет точностью, с которой цвета представляются в цветовой таблице, используемой для создания 8-бит изображения (IMAGEMODE PC256). Обычно цвета из растровой карты цветов или оттенки серого должны вычисляться точно. Директива указывает, что точность определения цветов лежит в пределах заданного цветового расстояния. Таким образом, установка COLOR_MATCH_THRESHOLD равного 3 будет означать, что существующее значение цвета в пределах 3 (сумма разностей красного, зеленого и синего) будет использоваться вместо создания нового элемента таблицы цветов. Особенно для растров в оттенках серого, которые обыкновенно содержат 256 доступных цветов, представляется хорошая возможность сжатия карты цветов. В большинстве случаев хороший результат достигается при использовании значений в диапазоне 2-6.
Пример:
PROCESSING "COLOR_MATCH_THRESHOLD=3"

Методология отображения растров

  • Построение перекрывающихся уровней для больших растров гарантирует, что только разумно необходимый объем данных будет обработан при построении карты. Могут быть организованы группы перекрывающихся слоев, отображаемых в зависимости от выбранного разрешения, используя директивы MINSCALE и MAXSCALE для управления отображением слоев при выбранном разрешении. Другой, возможно более простой путь, заключается в построении пирамид для поддерживаемых библиотекой GDAL форматов, используя утилиту gdaladdo.

  • Предварительная обработка RGB 8-бит изображений с использованием таблицы цветов с целью уменьшения объемов обрабатываемых данных и числа вычислений “на лету”.

  • Для больших изображений используется их разбиение на набор малых, что позволяет загружать лишь небольшой набор данных для текущей области отображения. Такой путь может пользоваться механизмом TILEINDEX в файле проекта, или построением файла пирамиды (например, для формата TIFF библиотеки GDAL).

  • Убедитесь, что вы заранее подготовили изображение во всех необходимых проекциях, чтобы исключить перепроецирование “на лету”, требуещее много ресурсов компьютера.

  • Если вы используете вывод отладочной информации картсервера в журнал вашего сервера, проверьте, не появляется ли в нем сообщение msResampleGDALToMap in effect. Это сообщение означает, что выполняется перепроецирование растрового слоя. Если вы не делаете это специально, убедитесь, что проекция, указанная в файле проекта совпадает с проекциями всех слоев (верный путь – совсем не указывать проекцию слоя, в этом случае по умолчанию принимается проекция проекта и лишние преобразования выполняться не будут).



Геопривязка растров с помощью файла привязки

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

Структура файла привязки следующая. Первый коэффициент представляет собой размер по координате X в пикселах.Второй и третий являются коэффициентами поворота/сдвига (для неискаженного изображения равны 0.0). Четвертый коэффициент представляет собой размер по координате Y в пикселах, обычно этот коэффициент отрицателен, что соответствует направлению оси ординат вниз от левого верхнего угла. Последние два значения представляют собой X и Y координаты центра левого верхнего пиксела изображения. Следующий пример соответствует изображению с размером пиксела 2m x 2m, и левым верхним углом в точке (356800E, 5767999N).
2
0.0000000000
0.0000000000
-2
356800.00
5767999.00

Имя файла привязки основывается на имени файла изображения. Например, для файла aerial.tif файл привязки будет называться aerial.tfw. Кроме того, картсервер также понимает файлы привязки с расширением .wld.

Mapserver: быстрый старт (перевод)

Быстрый старт
Документ рассказывает о компонентах картографического сервера и их совместной работе.
Последнее обновление: 13/11/2004

Элементы картографического сервера

Самый простой путь использования картографического сервера заключается в его запуске как CGI приложения через ваш HTTP сервер. Этот путь рекомендуется использовать в случае, когда вы не нуждаетесь в более сложном приложении на основе MapScript, которое будет напрямую использовать MapServer API.

Картографическое CGI приложение использует следующие ресурсы:

  1. HTTP сервер, например, Apache или Internet Information Server,

  2. Приложение MapServer,

  3. Файл инициализации, в котором хранятся настройки приложения MapServer для первого запуска (опционально),

  4. Файл проекта (Mapfile), в котором содержится информация о данных,

  5. Файл шаблона, в котором настраивается пользовательский интерфейс приложения для работы через браузер клиента,

  6. База пространственных данных (GIS dataset).


Рекомендуется установка MapServer в CGI-BIN директории HTTP сервера и размещение прочих файлов в каталоге документов сервера (http document directory).

Файл инициализации

Этот файл может быть частью другого HTML файла, однако в самом простом случае он может быть отдельным файлом. Файл инициализации использует форму для отправки запроса инициализации к HTTP серверу, который возвращает результат работы картографического сервера. Картографический сервер в этом случае запускается отдельно для каждого выполняемого запроса без сохранения информации о состоянии, вследствии чего необходимо сохранение значений инициализированных переменных в скрытых параметрах запроса. Вышеозначенный файл является стандартным HTML файлом с расширением .htm или .html. В качестве альтернативного варианта может использоваться гипертекстовая ссылка, передающая параметры инициализации CGI приложения.

Файл проекта (Mapfile)

Файл проекта определяет данные, которые будут использованы приложением, настройки внешнего вида карты и параметры выполнения запросов. Также содержит информацию о том, как будет отрисовываться карта, легенда, и как будут представлены результаты поиска.Обычно файл имеет расширение.MAP.

Файл шаблона

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

База пространственных данных (GIS Dataset)

В качестве формата векторных файлов по умолчанию выбран формат ESRI шейпфайла. Растровые данные могут храниться в различных форматах, набор которых зависит от параметров компиляции приложения. По умолчанию, поддерживаются geoTiff файлы и Tiff файлы с привязкой. Другие форматы данных могут быть использованы, если изменить настройки компиляции приложения. Размещение файлов данных описывается в файле проекта. Картографический сервер также содержит утилиты для оптимизации шейпфайлов (shptree, sortshp).

Установка

В первую очередь необходимо установить картографический сервер. Для установки вы должны обладать необходимыми разрешениями на вашем сервере, в ином случае обратитесь к вашему системному администратору. В системах Windows вы можете воспользоваться уже готовым скомпилированным приложением. Аналогично, в Linux-системах вы можете установить соответствующий пакет. Предварительно скомпилированные версии доступны для следующих операционных систем:

  • Windows

  • UNIX/Linux

  • Cygwin на Win32



Тестирование

После того, как вы установите картсервер, вы готовы к созданию вашего первого картографического приложения. Рекомендуем вам использовать MapServer Demo Application для проверки установленного сервера. Файл проекта (Mapfile) и файл шаблона (Template file) это простые ASCII текстовые файлы, которые вы можете редактировать в вашем любимом текстовом редакторе (например, notepad или wordpad в системах Windows). Файл инициализации это простой HTML файл, который вы можете редактировать в вашем любимом HTML редакторе.

Первое приложение

Набор MapServer Demo поможет вам настроить ваш сервер и ближе познакомиться с файлами проекта и шаблона.

Mapserver: движок для публикации растровых и векторных карт

В последний год замечаю значительный интерес к работе с GPS приемниками, электронным картам и сопутствующим вопросам. Тем не менее, информация в сети на эти темы очень скудна, а то, что есть, далеко не полно и многократно дублируется. Все это навело меня на мысль опубликовать собственные наработки за несколько лет, благо материалов накопилось немало. Мною выполнены такие проекты, как разработка картсервера и спутниковой навигационной системы для ГУВД Нижнего Новгорода (лично представлял в рамках проекта "Дозор-Антитеррор" в ГУВД), работа с фондом имени Бортника по программе "Старт", разработка мобильного клиента (мидлета) для просмотра карты и поиска объектов на сотовом телефоне (разработка была показана в местных новостях по инициативе компании Мегафон в рамках выполненного для них проекта по передаче видео на сотовый телефон через сеть EDGE/GPRS) и другие. В проектах участвовали и другие люди, но я всегда был ведущим разработчиком и единственным специалистом по ГИС и готовил отчеты, так что если я не расскажу об этих технологиях, все так и забудется. Коммерческого успеха эти проекты не принесли, то ли ментальность людей в Нижнем Новгороде "совковская", то ли вся Россия такая, но тем не менее, проекты были выполнены, долгое время работали, но за ненужностью были отключены. Разве что в ГУВД картсервер действует до сих пор, но мне это уже не интересно. Время от времени я переписываю "движок" картсервера, поскольку я и мои друзья продолжаем пользоваться собственным вьювером для просмотра карты Нижнего Новгорода и области. За актуальные и подробные карты "для некоммерческого использования" большое спасибо Дурандину Андрею Витальевичу. Единственные карты Нижнего Новгорода и области, которые удовлетворяют мировым стандартам (корректная топология, наличие классификатора атрибутивной информации, формат шейпфайлов) и могут быть загружены в модуль PostGIS... Итак, сначала введение и переводная документация, а потом поделюсь собственными "рецептами" и программами.

Существует множество ГИС, набор их функций бывает как очень скромным (узкоспециализированные проекты), так и совершенно необъятным (GRASS, ESRI ArcInfo, etc.). Но у всех систем есть отличительное свойство - они ориентированы на анализ данных и предоставление результатов в различных видах, но не на электронную публикацию интерактивных карт. И когда появляется задача опубликовать готовую карту в Интернет или Интранет, приходится или смириться с примитивным оформлением или искать другой способ публикации. В этом случае на помощь приходит программный продукт mapserver, который способен не только быстро отобразить векторную, растровую или гибридную карту, но и сделать это красиво. Благодаря полной поддержке шейпфайлов (shapefiles) и интеграции с PostGIS возможен и различного рода пространственный анализ, который позволяет идентифицировать объект на карте, проводить поиск по атрибутам и многое другое, притом, что слои карты могут быть в разных проекциях или без нее. За последние два-три года изменений в mapserver довольно мало, он стабильно работает и имеющихся функций вполне достаточно. Для желающих увеличить функциональность есть модули mapserver для различных языков (например, tcl, python, perl, php). Интеграция с java и платформой .net также присутствует, но о работе mapserver с этими технологиями я вам ничего не расскажу, не пробовал.

Предлагаю Вашему вниманию часть документации, переведенной на русский язык. Перевод я делал 3 года назад, тем не менее, эта информация актуальна и сегодня. Переводил далеко не все материалы, так как в свое время в очень сжатые сроки прочитал больше 1000 страниц англоязычной документации (из них 500 страниц за 1 день), переводить все просто не было времени, к тому же в те времена никто этим проектом не интересовался и не знал о нем. Да и потом много времени занимал поиск различных нетривиальных моментов в форумах и рассылке проекта. Тем не менее, если читатели будут заинтересованы в каких-то разделах документации, переведу. Также расскажу о различных тонкостях, таких, как работа с mapserver из разных языков программирования, наборах символов, проекциях, оптимизации и прочем. Если что интересно, пишите, у меня много исходников накопилось за 3 или 4 года работы с mapserver, разбираться в них долго, да и нужно ли, так что буду ориентироваться на комментарии читателей.


Mapserver: быстрый старт (перевод)

Mapserver: растры (перевод)

Обзоры в интернет

Для интересующихся приведу ссылки на некоторые русскоязычные обзоры mapserver, благо они появились (наконец-то!). Приведу только русскоязычные статьи/проекты, поскольку в России своя специфика и свои проблемы, с которыми никогда не сталкиваются за рубежом (например, отвратительное состояние всех картографических материалов, которые язык не повернется назвать spatial dataset). Также будет полезным сравнение с ArcIMS, коммерческим аналогом от компании ESRI. От себя замечу, что продукты несколько различаются по своей направленности - ArcIMS предназначен для пользователей платформы ESRI ArcGIS и позволяет легко и быстро опубликовать данные, накопленные в рамках этой платформы, в то время как mapserver нацелен на публикацию разнородных данных, в силу чего требует больше времени и усилий (понятно, что уже подготовленные данные опубликовать несравнимо проще, чем сборную "солянку"). Этот момент в сравнениях часто не учитывают, что приводит новичков в недоумение - часто звучит вопрос, почему в mapserver нельзя сделать все так же просто, как и в ArcIMS. Кстати, если у Вас есть данные, уже обработанные в ESRI ArcGIS или ArcView, можно воспользоваться скриптом к ArcView, который по настройкам проекта создаст конфигурационный файл mapserver.

Вот простое сравнение mapserver и ArcIMS:
Создание картографических сервисов с использованием ArcIMS. Введение.
Создание картографических сервисов с использованием MapServer. Введение.

Вот здесь можно почитать об открытых стандартах в области ГИС, которые разрабатывает и продвигает OGC (Open GIS consortium):
Классификация картографических веб-сервисов OGC

Довольно интересная презентация, по уровню не уступает англоязычному оригиналу, плюс авторы рассказали о российской специфике, рекомендую прочитать всем:
phpConf 2007 - слайды MapScript и MapServer


Продолжение следует...

Quantum GIS (QGIS): обзор

Quantum GIS (QGIS) представляет собой геоинформационную систему, построенную на платформе Linux/Unix. QGIS поддерживает различные векторные и растровые форматы, а также предоставляет доступ к базам данных.

Перечислим основные возможности системы:

  • Поддержка таблиц PostGIS с пространственными данными

  • Поддержка форматов shapefiles (шейпфайлы), покрытий ArcInfo, файлов Mapinfo, и других форматов, доступных через OGR

  • Поддержка растров

  • Идентификация объектов

  • Отображение аттрибутивных таблиц

  • Возможности выбора объектов

  • Экспорт в map-файл Mapserver


Планируемые возможности:

  • Редактирование shapefiles и слоев PostGIS

  • Генерирование выходных карт

  • Поддержка скриптов

  • Поддержка метаданных



Quantum GIS 0.8.0 ('Titan')

Текущая версия QGIS имеет номер 0.8.1 и была выпущена 15 июня 2007 года. В этой версии устранены замеченные ошибки. Предыдущая версия с номером 0.8.0 выпущена 29 декабря 2006 года.

Что нового в версии 0.8

  • Поддержка WMS

  • Улучшено редактирование векторной и атрибутивной информации

  • Функции измерения дополнены измерением площади

  • Поиск по атрибутам

  • Новая структура легенды

  • Переделана структура приложения для обеспечения возможности использовать библиотеки QGIS в сторонних приложениях для отрисовки карт

  • Улучшена утилита экспорта в формат MapServer

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

  • GRASS теперь поддерживается на всех платформах

  • Расширенная поддержка GRASS и панель команд

  • Расширены редактирование векторных данных, включая копирование, вырезание, вставку, "клики" и редактирование вершин

  • Редактирование слоев шейпфайлов и подключаемых через библиотеку OGR (не понял, то ли только шейпы через OGR, то ли шейпы и все, что подключается через OGR, уточню)



Еще есть WFS модуль, но он еще только-только тестируется, так что о нем пока ничего не говорится в анонсе.

Еще один новый модуль "PostgreSQL Geoprocessing", хотя при беглом взгляде там обнаружилась только функция построения буфера.

Модуль GPS работает только с форматом GPX (поддержка встроена в QGIS). Для поддержки других форматов необходим GPSBabel, программа его находит, выдает список поддерживаемых форматов, но файлы не грузит. Не знаю, в чем дело, разбираться пока не хочу.

Поддержкка WMS слоев работает, программа сама знает несколько серверов, можно поэкспериментировать.

Изменений много, попробую во вторник или около того загрузить целиком векторную карту Нижнего Новгорода в формате шейпфайлов, средствами QGIS сохранить ее в PostgreSQL, попробовать редактировать из шейпфайлов и из PostgreSQL. О результатах расскажу, если кого что интересует, пишите, буду знать, на что обратить внимание.

Ну вот уже и вторник, продолжаем наше исследование. Проверим на практике, что и как. Стандартом де-факто настольных ГИС многими специалистами справедливо признан ESRI ArcView 3.2, вот с ним и будем сравнивать. Впрочем, кто не знаком с ArcView, не огорчайтесь - я просто буду рассказывать о тех особенностях, которые бросаются в глаза при поочередном использование вышеназванных программ. Кстати, сам я ArcView не использую в силу лицензионных соображений, благо альтернативы есть. А вот QGIS на мой взгляд совершенно напрасно считается альтернативой, но об этом ниже.

Запускаем QGIS, идем в главное меню и выбираем пункт Layer->Add a Vector Layer. Выбираем нужные нам шейпфайлы и добавляем их в проект. Теперь перемещаем слои в соответствии с нужным нам порядком их отрисовки. Пока список всех слоев помещается на экране, все в порядке, но как только список перестает помещаться, при перемещении элементы в легенде начинают прыгать, жутко мешая работе. Так, обнаруживаем как это обойти - создаем группы в легенде и в них распихиваем слои. Теперь если свернуть группы, то можно нормально перетаскивать слои. Что будет, если список групп не поместится на экране, думать не хочется. Да, совсем забыл - пока добавляете слои, растаскиваете их по группам и указываете параметры отображения, обязательно отключите перерисовку карты (rendering), сняв флажок в правом нижнем углу программы!

Для удобства работы раскрашиваем слои как нам удобно. Сразу отметим минус - нельзя сохранить раскраску слоя в отдельный файлик, в каждом проекте слои придется оформлять заново. Указываем цвет полигонов и линий, где нужно, задаем цвет границы.



Для домов и улиц включаем отображение названий из поля атрибута LBL, настраиваем цвет и размер шрифта. И тут новые грабли - подписи слоя показываются всегда, притом перекрывают друг друга, приходится выставить диапазон масштабов, в которых слой отображается, иначе все просто ужасно. В результате карта получается бедная, хочется больше элементов отобразить, но они начинают перекрываться и сливаться.

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

При определенном увеличении карта становится более насыщенной, и все же выглядит очень непрофессионально.


Ладно, худо-бедно карту видим. Теперь попробуем идентификацию объектов на карте. Выбираем нужный слой в легенде, щелкаем на одном из объектов слоя на карте. Появляется окошко с информацией. Как и в ArcView, остается проблема определить, к какому слою относится интересующий нас объект. В mapserver такой проблемы нет, слой находится автоматически.

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

Еще можно посмотреть таблицу атрибутов. Первое впечатление - очень медленно работает. Второе - не хочет показывать на карте выбранный объект. Отредактировать записи вроде можно, но проверять не буду, слишком медленно и не видно на карте, что делаю, проще в OpenOffice открыть dbf файл и что надо поправить.

Создадим новый векторный слой (шейпфайл) и нарисуем в этом слое полигон. При создании слоя QGIS предлагает создать атрибуты, создадим парочку - ID типа Integer и LBL типа String. Начнем редактирование слоя, нарисуем полигон, завершим редактирование. QGIS предложит заполнить значения атрибутов нового объекта, заполняем, сохраняем. Теперь попробуем изменить созданный объект. Опять начинаем редактирование, пробуем изменить. Появляется сообщение об ошибке и предложение установить параметр Tolerance в Settings->Project Properties->General. Закрываем окно с сообщением. Снова появляется то же самое сообщение об ошибке, явный баг. Заходим в указанное меню, обнаруживаем, что параметр на самом деле называется Snapping Tolerance, устанавливаем значение 10 (метров). После чего успешно пробуем перетащить одну из вершин полигона в новое место. Ну что ж, редактирование работает, хотя опять же медленно. При каждом изменении редактируемого слоя и начале/окончании редактирования видимая область карты перерисовывается, что раздражает и замедляет работу.

Резюме: отредактировать пару объектов карты или нарисовать их вполне можно, но для постоянной работы система не годится совершенно. Интерфейс очень медленный, движок отрисовки карты примитивный. Есть интеграция с GRASS и PostGIS, возможно, на мощной машине что-то и получится, но я даже пробовать не буду. Тестирование проводилось на компьютере Celeron 2,4 GHz, 512 MB RAM, 80 Gb SATA HDD. За кадром остались такие возможности, как создание пирамидальных растров, геопривязка растров и работа с векторными форматами, отличными от шейпфайлов, но при текущем быстродействии QGIS мало у кого хватит желания и терпения добраться до этих функций. Функция создания конфигурационного файла для mapserver выглядит абсолютно нелепой - не ясно, кому нужна в mapserver карта с качеством отображения аналогичным QGIS. Лучше бы сделали наоборот - импорт файла mapserver, хотя бы тех параметров, которые в QGIS поддерживаются.

P.S. Впечатление о том, что разработчики ваяют нового Qt-шного монстра возникло еще в версии 0.3, теперь же это можно считать свершившимся фактом. Быстрее и удобнее редактировать карту через веб-интерфейс к mapserver. Рекомендую смотреть в сторону SagaGIS, много модулей и работает быстро.

PostGIS: начинаем работу с модулем пространственных операций PostGIS для СУБД PostgreSQL

PostGIS добавляет поддержку геоданных в ОР (объектно-реляционную) СУБД PostgreSQL. таким образом, PostGIS делает возможным работу сервера PostgreSQL с пространственными данными, создавая таким образом прекрасное хранилище для GIS. Примечание: PostgreSQL самостоятельно поддерживает пространственные типы данных, так что на самом деле PostGIS предоставляет скорее удобный интерфейс управления, нежели просто возможность хранения данных. В этом случае становится возможным сохранение целых векторных слоев, а не просто точек или полигонов.

PostGIS/PostgreSQL включает следующие возможности:

  • Поддержку стандартов OpenGIS Consortium (OGC)

  • Поддержку текстовых и двоичных представлений геоинформационных объектов

  • Быстрое пространственное индексирование, используя GiST

  • Функции геоанализа

  • PostgreSQL JDBC доступ к геоданным

  • Поддержку функций доступа в соответствии со спецификацией OGC



Инициализация PostGIS

Включить поддержку языка PL/pgSQL:
create function plpgsql_call_handler() returns opaque as '/usr/lib/postgresql/lib/plpgsql.so' language 'c';
create language 'plpgsql' handler plpgsql_call_handler lancompiler 'PL/pgSQL';

Загрузить функции PostGIS:
psql -d template1 -f /usr/share/doc/postgis/postgis.sql
psql -d template1 -f /usr/share/doc/postgis/spatial_ref_sys.sql

Удалить функции PostGIS:
psql -d template1 -f /usr/share/doc/postgis/postgis_undef.sql

Загрузка шейпфайлов в PostgreSQL

Дано:
векторные карты в формате шейп-файлов
Требуется:
загрузить карты в СУБД PostgreSQL
Решение:
утилита /usr/lib/postgresql/bin/shp2pgsql позволяет создать SQL-код из содержимого шейпфайла
команда shp2pgsql ./rivers.shp rivers>rivers.sql создает sql-дамп таблицы rivers согласно шейпфайлу rivers.shp в файле rivers.sql
Осталось загрузить созданную таблицу в базу:
psql -d имя_базы -f ./rivers.sql

Принцип работы PostGIS лучше всего изложен в оригинальном мануале, добавить особо нечего, кроме, разве что, некоторых хитростей.

Что касается использования PostGIS:
==========================================
#database_init.sql
drop database map;
create database map with template="template0" encoding='koi8';

\c map

CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler
AS '/usr/lib/postgresql/lib/plpgsql.so', 'plpgsql_call_handler'
LANGUAGE c;

CREATE PROCEDURAL LANGUAGE plpgsql HANDLER plpgsql_call_handler;

#!/bin/sh
# create & init databases
psql -d template1 -f ./database_init.sql

# init PostGIS functions
psql -d $MAP -f postgis.sql
psql -d $MAP -f spatial_ref_sys.sql

echo "making shapefiles list in directory $MAPDIR/$MAP"
tables=`ls $MAPDIR/$MAP/*.shp|sed 's/.shp//g'|awk -F"/" '{print $NF}'`

echo "creating sql reprezentation of selected shapefiles"
for loop in $tables
do
/usr/lib/postgresql/bin/shp2pgsql -d $MAPDIR/$MAP/$loop.shp $loop>$MAPDIR/$MAP/$loop.sql
echo "$loop.shp => $loop.sql"
done

echo "loadind geospatial tables into database $MAP"
for loop in $tables
do
psql -f $MAPDIR/$MAP/$loop.sql -d $MAP
echo "loaded $loop.sql"
done
==========================================

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

См. далее
Пространственный анализ в PostGIS с использованием множества координатных систем

ПУБЛИКАЦИЯ ВЕКТОРНЫХ КАРТ

Подготовка векторных карт к виду, пригодному для их использования в геоинформационных системах (ГИС), является необходимой частью процесса создания карты. Однако в настоящее время практически все отечественные карты не могут быть загружены в ГИС без значительных доработок, а зачастую требуется их векторизация заново. Причиной являются как множественные нарушения топологии, так и проблемы денормализации пространственных и метаданных. В России повсеместно используются векторные карты в файловом формате программы MapInfo, значительно реже - в форматах ArcView, ArcGIS и других, в то время как в мировой практике большие массивы пространственных данных сохраняют в так называемых пространственных хранилищах данных (spatial datasets), представляющих собой реляционные или объектно-реляционные базы данных (БД) с поддержкой геометрических типов данных и операций над ними. Примером таких баз данных являются PostgreSQL с модулем PostGIS и Oracle. Применение указанного подхода обеспечивает логическую целостность данных и удобство применения любых преобразований данных, как в интерактивном режиме (под управлением оператора), так и в пакетном режиме (полностью автоматически, по заданному алгоритму). Одним из таких преобразований является изменение проекции карт "на лету". Построив реляционное хранилище пространственных данных, можно получать из него разнообразные наборы карт в произвольной проекции, а также автоматически генерализованные карты или синтетические, содержащие результаты анализа хранимой географической информации (геоинформации). Статья посвящена вопросам подготовки векторных карт для построения пространственных хранилищ данных для дальнейшего их использования в ГИС.

В общем случае процесс подготовки векторных карт может быть представлен набором следующих шагов:

  1. Загрузка в БД.

  2. Проверка топологии пространственных объектов.

  3. Нормализация данных.

  4. Агрегирование данных.

  5. Предварительный анализ и вычисление функционалов (площадь, периметр, протяженность и проч.)


Рассмотрим каждый шаг более подробно.

Шаг 1. Преобразование в sql-формат для сохранения в БД может быть произведено из стандартного обменного формата шейпфайлов с применением специальных утилит. Загрузка в БД sql-файла может производиться как вручную, так и с использованием вспомогательных программ.

После выполнения преобразования необходимо проверить, все ли объекты были сохранены в БД. Для этого из БД объекты выгружаются в новый шейпфайл и производится сверка полученного файла с исходным. Несохраненные объекты заново векторизуются или корректируются вручную, после чего добавляются в БД. Описанная процедура повторяется до тех пор, пока все объекты не будут успешно сохранены в БД. Стоит отметить, что большинство отечественных карт с которыми работал автор, оказались полностью непригодны и должны быть оцифрованы заново. И лишь некоторые карты, изготовленные специалистами, успешно и без особых проблем загружаются в БД. Кроме того, существуют программы, которые сохраняют в БД непосредственно шейпфайлы, выполняя преобразование скрытно от пользователя. Однако в большинстве случаев с российскими картами такие программы не могут работать, поскольку требуют исходные карты с корректной топологией. Так что практически карты нужно грузить вручную, как описано выше, после чего проверять и исправлять топологию объектов.

Шаг 2. В том случае, когда исходная карта имеет нарушенную топологию (практически всегда для отечественных карт), необходимо выявить все объекты с нарушенной топологией и исправить их вне базы, аналогично описанной в Шаге 1 методике. Определение нетопологичных объектов является стандартной операцией над набором пространственных данных и может выполняться в пакетном режиме средствами БД.

Шаг 3. Понятие нормализации строго определено в теории реляционных баз данных. Нормальная форма выбирается в зависимости от специфики решаемых задач. Заметим, что ненормализованная БД работать будет, но не столь эффективно, как это может быть достигнуто за счет нормализации. Кроме того, процедура приведения к нормальной форме позволяет быстро найти и исправить ошибки в аттрибутивных данных.

Шаг 4. Пространственные типы данных могут быть как простыми (точка, линия или полигон), так и составными (набор точек, линий или полигонов). Агрегирование геоданных представляет собой глобальную процедуру агрегирования объектов. Иначе говоря, все объекты (как простые, так и составные), являющиеся логическими частями сложных структур, должны быть объединены в составные объекты. Указанное преобразование является синтетическим и при успешном использовании позволяет объединять в одном хранилище карты разных масштабов, обеспечивая прозрачный (незаметный для пользователя) переход между разномасштабными картами. Насколько известно автору, в отечественной практике вышеописанный подход не применяется. Алгоритм агрегирования следует реализовывать очень аккуратно, иначе возможно возникновение артефактов, описание которых выходит за рамки статьи.

Шаг 5. Работа с данными может быть оптимизирована за счет предварительного вычисления значений некоторых функций и их сохранения в БД. Такими функциями являются площадь и периметр полигональных объектов, протяженность линейных и другие. Список часто используемых функций составляется в ходе предварительного анализа работы ГИС или при тестовом запуске системы. Кроме того, также рекомендуется индексирование таблиц БД. При больших объемах данных индексирование пространственных данных является необходимым.

Применение вышеописанного подхода позволяет создавать быстрые и эффективные ГИС.

ПУБЛИКАЦИЯ РАСТРОВЫХ КАРТ

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

Когда обрабатываются большие растровые файлы, значительное повышение производительности может быть достигнуто путем разделения исходного большого растрового изображения на множество маленьких картинок. Каждый файл является частью большой растровой мозаики, доступной для отображения. Список файлов мозаики может быть сохранен в шейпфайле с указанием координат границ каждого файла и имени файла. В этом случае отдельные файлы могут иметь произвольные размеры и допускаются перекрытия между отдельными элементами мозаики. Программа отображения должна уметь сканировать файлы мозаики, перечисленные в шейпфайле и отображать только те из них, которые видны в текущем окне просмотра. Кроме того, при разделении файла на определенное число равных частей (например, на 16 частей, что соответствует двумерному массиву из 4 элементов по двум измерениям) информация об этом может быть сохранена в самом файле. В таком случае при построении карты требуется считывать информацию о разбиении исходного изображения из файла.

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

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

Если строится 8-битное псевдо-цветное изображение, тогда полная 24-битная RGB картинка для отображения будет преобразована в карту цветов выходного изображения. Для преобразования может быть использован цветовой куб. Он включает фиксированный набор из 175 цветов и поддерживает использование 5 уровней красного, 7 уровней зеленого и 5 уровней синего, и плюс к этому 32 оттенка серого. Растры отрисовываются “на лету” одним из цветов куба. Такой механизм ухудшает качество цветопередачи, особенно для изображений с плавными переходами цвета. Также можно использовать фиксированный набор из 256 цветов, что работает значительно быстрее.

Вариацией изложенного подхода является скользящее сглаживание в процессе отрисовки. Этот алгоритм вычисляет цвет пиксела исходя из цвета соседних. В случае однотонных участков изображения результат аппроксимации получается точнее, чем в предыдущем методе. Технология сглаживания может быть полезна не только для цветового куба, но и для заданной цветовой палитры. Отметим, что сглаживание требует больше ресурсов процессора чем простое использование цветового куба, в силу чего следует избегать использование этой технологии в тех случаях, когда важна производительность.

Также существующее программное обеспечение позволяетсоздавать 24-битное выходное изображение при использовании 24-битного исходного.

Простым механизмом для добавления географической информации (мировых координат) к растровым файлам являются файлы привязки. ESRI была первой компанией, предложившей идею использования файлов привязки, и сейчас часто используют такие файлы с форматом TIFF заместо внедрения географической информации непосредственно в файл (формат geoTIFF). Использование преобразования проекции растров “на лету” удобно, однако следует учитывать, что этот процесс требует произведение большого объема вычислений при каждом обращении к карте.

Структура файла привязки следующая. Первый коэффициент представляет собой размер по координате X в пикселах.Второй и третий являются коэффициентами поворота/сдвига (для неискаженного изображения равны 0.0). Четвертый коэффициент представляет собой размер по координате Y в пикселах, обычно этот коэффициент отрицателен, что соответствует направлению оси ординат вниз от левого верхнего угла. Последние два значения представляют собой X и Y координаты центра левого верхнего пиксела изображения. Следующий пример соответствует изображению с размером пиксела 2m x 2m, и левым верхним углом в точке (356800E, 5767999N).

2
0.0000000000
0.0000000000
-2
356800.00
5767999.00

Имя файла привязки основывается на имени файла изображения. Например, для файла aerial.tif файл привязки будет называться aerial.tfw. Также используются файлы привязки с расширением .wld.

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

  • Построение перекрывающихся уровней для растров высокого разрешения гарантирует, что только разумно необходимый объем данных будет обработан при построении карты. Могут быть организованы группы перекрывающихся слоев, отображаемых в зависимости от выбранного разрешения. Другой, возможно, более простой путь, заключается в построении пирамид для поддерживаемых форматов.

  • Для больших изображений используется их разбиение на набор малых, что позволяет загружать лишь небольшой набор данных для текущей области отображения. Такой путь может пользоваться механизмом разделения растров, или построением файла пирамиды (например, для формата TIFF). Заметим, что речь идет о растрах, покрывающих большую плошадь, в отличие от рассмотренного выше случая растра высокого разрешения. Вообще говоря, ранее предложенный способ обычно легче реализуем, а текущий – более трудоемок, что окупается его универсальностью.

  • Предварительная обработка RGB 8-битных изображений с использованием таблицы цветов с целью уменьшения объемов обрабатываемых данных и числа вычислений “на лету”.

  • Подготовьте заранее изображение во всех необходимых проекциях, чтобы исключить перепроецирование “на лету”, требовательное к ресурсам компьютера.

  • Убедитесь, что проекция карты совпадает с проекциями всех слоев , в этом случае лишние преобразования выполняться не будут.

ПРОЕКТИРОВАНИЕ ГЕОИНФОРМАЦИОННЫХ СИСТЕМ

Существует множество определений географических информационных систем (ГИС), которые зачастую противоречивы. Кроме того, ни одно из известных автору определений не может являться основой построения реальной ГИС. В то же время понятие геоинформационной системы может быть получено на основе определения системы. В общем случае, система представляет собой совокупность частей и взаимодействий между ними. Тогда информационную систему мы можем определить как множество информации и заданные над этим множеством операции, то есть приходим к понятию теоретико-множественной модели, давно известной математикам. Заметим, что определение множества требует от нас лишь одного: задания критерия принадлежности элементов множеству. То есть, если для любого элемента мы можем однозначно указать, входит он в множество или нет, множество определено. Для географической информации могут быть определены следующие типы информации: точка, линия и полигон. Аттрибутивную информацию можно представлять строками и числами. Алгебра множеств обеспечивает мощный теоретический аппарат для манипулирования произвольными множествами. Важным свойством является замкнутость: любые допустимые над элементами множества операции приводят к результату, также содержащемуся в множестве. Проще говоря, выполняя операции над геометрическими объектами, мы получаем геометрические объекты (возможно, вырожденные). Точно также, операции над аттрибутивной информацией приводят в результате к другим аттрибутивным данным. Далее, допустим возможность создания связей между элементами разных множеств. Связи могут создаваться произвольно, между элементами множеств одного и того же или разного типа. Кроме того, необходимо предусмотреть некоторое физическое хранилище данных, абстрагированное от логического представления информации. Всем перечисленным требованиям удовлетворяет реляционная модель данных, которая, вообще говоря, создавалась для работы с массивами аттрибутивной информации, но может быть расширена для оперирования географическими данными за счет введения новых типов данных, соответствующих элементам множеств геоданных. Таким образом, географическая информационная система представляет собой хранилище пространственной и аттрибутивной информации заданных типов с определенными операциями над данными, обеспечивающими свойство замкнутости, где логическая структура данных изолирована от их физического представления.

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

Примером ГИС для работы с векторными данными является объектно-реляционная система управления базами данных PostgreSQL с модулем PostGIS. Широкие возможности для работы как в векторными, так и с растровыми данными предоставялет ГИС GRASS (может работать совместно с предыдущей).

(C) Alexey Pechnikov aka MBG, mobigroup.ru