Основы работы динамических TMS-сервисов: различия между версиями
(Новая страница: «== Введение == TMS-сервис может функционировать в одном из двух режимов - статическом и дина…») |
мНет описания правки |
||
Строка 46: | Строка 46: | ||
Чтобы разобраться с тем, как организована работа современных тайловых серверов ([http://tilecache.org/ TileCache], [http://mapproxy.org/ MapProxy]) (фактически работающих в смешанном режиме), попытаемся написать собственный динамический TMS-сервер. | Чтобы разобраться с тем, как организована работа современных тайловых серверов ([http://tilecache.org/ TileCache], [http://mapproxy.org/ MapProxy]) (фактически работающих в смешанном режиме), попытаемся написать собственный динамический TMS-сервер. | ||
== Архитектура динамического TMS-сервиса == | |||
Логику любого динамического TMS-сервиса можно упрощённо представить в виде следующей схемы: | |||
[[Файл:Dynamic tms.png|640px|thumb|center|<center>Схема работы динамического TMS-сервиса</center>]] | |||
Из данной схемы следует, что для создания сервиса необходимы инструменты, позволяющие следующее: | |||
# Элемент нумерованного списка | |||
# Элемент маркированного списка | |||
# Извлекать информацию о координатах тайла из URL | |||
# По вычисленным координатам тайла получать его охват в единицах измерения карты | |||
# Извлекать данные из хранилища по переданному охвату | |||
# Отрисовывать (рендерить) извлечённые данные | |||
# Формировать HTTP ответ, содержащий готовый тайл | |||
Каждая из этих задач может быть решена с помощью широкого спектра инструментов (библиотек), не связанных друг с другом. Например, процедуру извлечения данных из хранилища можно выполнить с помощью таких библиотек как [http://www.gdal.org/ GDAL/OGR] или [http://geopython.github.com/OWSLib/ OWSLib], рендеринга - [http://mapnik.org/ Mapnik] или [http://mapserver.org/mapscript/ MapScript] и т.д. | |||
== Выбор инструментов == | |||
Для решения 1 и 5 задачи подходит любой Веб-фреймворк. Поскольку наши требования к его функциональности достаточно скромные, то нет нужды использовать что-то вроде [https://www.djangoproject.com/ Django] или [http://www.pylonsproject.org/ Pyramid], вполне можно обойтись любым микрофреймворком, таким как [http://flask.pocoo.org/ Flask] или [http://bottlepy.org/docs/dev/ Bottle]. Остановимся на последнем. | |||
2-я задача довольно простая, решим её самостоятельно без привлечения сторонних библиотек. | |||
Для решения 3-й и 4-й задачи воспользуемся Mapnik-ом. Заметьте, что Mapnik в данном случае выступает не только в роли рендерера, но и в роли библиотеки, умеющей извлекать данные из хранилища. Полный список форматов, которые умеет читать Mapnik, доступен [https://github.com/mapnik/mapnik/wiki/PluginArchitecture здесь]. Mapnik вообще очень универсальный инструмент, позволяющий, в частности, отрисовывать объекты и [http://gis-lab.info/qa/mapnik-datasources.html без предоставления прямого доступа к хранилищу]. | |||
== Заключение == | == Заключение == | ||
Таким образом, мы написали свой собственный примитивный TMS-сервер в котором пока нет ни возможности кэширования тайлов, ни многих других важных функций, но который наглядно отражает подходы, используемые современным ПО данного класса. | Таким образом, мы написали свой собственный примитивный TMS-сервер в котором пока нет ни возможности кэширования тайлов, ни многих других важных функций, но который наглядно отражает подходы, используемые современным ПО данного класса. |
Версия от 12:52, 6 апреля 2013
Введение
TMS-сервис может функционировать в одном из двух режимов - статическом и динамическом. В первом случае это ни что иное, как просто набор файлов, организованных определённым образом в файловой системе - тайловый кэш (здесь и далее в статье мы предполагаем, что тайловый сервис отвечает лишь за передачу самих тайлов (Tile Resources), остальные ресурсы, описываемые в спецификации, мы рассматривать не будем в виду их тривиальности). При запросе конкретного тайла HTTP-сервер (Apache, nginx) самостоятельно отображает запрашиваемый URL на структуру файловой системы и возвращает клиенту нужный тайл. Пример организации тайлового кэша:
└── admin_EPSG3857 ├── 1 │ ├── 0 │ │ ├── 0.png │ │ └── 1.png │ └── 1 │ ├── 0.png │ └── 1.png └── 2 ├── 0 │ ├── 0.png │ ├── 1.png │ ├── 2.png │ └── 3.png ├── 1 │ ├── 0.png │ ├── 1.png │ ├── 2.png │ └── 3.png ├── 2 │ ├── 0.png │ ├── 1.png │ ├── 2.png │ └── 3.png └── 3 ├── 0.png ├── 1.png ├── 2.png └── 3.png
В данном случае, чтобы получить, тайл с координатами (0, 0) на втором масштабном уровне, необходимо выполнить запрос, который может выглядеть следующим образом:
http://10.22.0.9/tms/1.0.0/admin_EPSG3857/2/0/0.png
Для создания тайлового кэша существует различное программное обеспечение, например, утилиты gdal2tiles и mapproxy-seed, TileMill, QTiles. Процесс создания тайлового кэша называется сидированием (seeding). Данная процедура весьма требовательна к объёму жесткого диска и может занимать очень много времени. Например, время создания тайлового кэша на территорию Казахстана вплоть до 16 масштабного уровня (профиль global-mercator) при средней наполненности слоёв составляет 2-3 дня, поэтому на практике данный способы используется для подготовки кэшей карт небольших территорий или для создания кэшей определённых масштабных уровней.
Второй режим работы тайлового сервиса - динамический - предполагает, что никакого тайлового кэша нет, а запрашиваемые клиентом тайлы генерируются по запросу "на лету".
Условно, можно выделить ещё один режим работы тайлового сервиса - смешанный. В этом случае сервис, функционирующий в динамическом режиме, не только отдаёт клиенту сгенерированный тайл, но и сохраняет его в некоторый кэш, что позволяет при следующем запросе этого тайла, не создавать его вновь, а брать из кэша, что значительно повышает скорость работы сервиса в целом.
Чтобы разобраться с тем, как организована работа современных тайловых серверов (TileCache, MapProxy) (фактически работающих в смешанном режиме), попытаемся написать собственный динамический TMS-сервер.
Архитектура динамического TMS-сервиса
Логику любого динамического TMS-сервиса можно упрощённо представить в виде следующей схемы:
Из данной схемы следует, что для создания сервиса необходимы инструменты, позволяющие следующее:
- Элемент нумерованного списка
- Элемент маркированного списка
- Извлекать информацию о координатах тайла из URL
- По вычисленным координатам тайла получать его охват в единицах измерения карты
- Извлекать данные из хранилища по переданному охвату
- Отрисовывать (рендерить) извлечённые данные
- Формировать HTTP ответ, содержащий готовый тайл
Каждая из этих задач может быть решена с помощью широкого спектра инструментов (библиотек), не связанных друг с другом. Например, процедуру извлечения данных из хранилища можно выполнить с помощью таких библиотек как GDAL/OGR или OWSLib, рендеринга - Mapnik или MapScript и т.д.
Выбор инструментов
Для решения 1 и 5 задачи подходит любой Веб-фреймворк. Поскольку наши требования к его функциональности достаточно скромные, то нет нужды использовать что-то вроде Django или Pyramid, вполне можно обойтись любым микрофреймворком, таким как Flask или Bottle. Остановимся на последнем.
2-я задача довольно простая, решим её самостоятельно без привлечения сторонних библиотек.
Для решения 3-й и 4-й задачи воспользуемся Mapnik-ом. Заметьте, что Mapnik в данном случае выступает не только в роли рендерера, но и в роли библиотеки, умеющей извлекать данные из хранилища. Полный список форматов, которые умеет читать Mapnik, доступен здесь. Mapnik вообще очень универсальный инструмент, позволяющий, в частности, отрисовывать объекты и без предоставления прямого доступа к хранилищу.
Заключение
Таким образом, мы написали свой собственный примитивный TMS-сервер в котором пока нет ни возможности кэширования тайлов, ни многих других важных функций, но который наглядно отражает подходы, используемые современным ПО данного класса.