Основы работы динамических TMS-сервисов: различия между версиями

Материал из GIS-Lab
Перейти к навигации Перейти к поиску
(Новая страница: «== Введение == 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-сервиса можно упрощённо представить в виде следующей схемы:

Схема работы динамического TMS-сервиса

Из данной схемы следует, что для создания сервиса необходимы инструменты, позволяющие следующее:

  1. Элемент нумерованного списка
  2. Элемент маркированного списка
  3. Извлекать информацию о координатах тайла из URL
  4. По вычисленным координатам тайла получать его охват в единицах измерения карты
  5. Извлекать данные из хранилища по переданному охвату
  6. Отрисовывать (рендерить) извлечённые данные
  7. Формировать HTTP ответ, содержащий готовый тайл

Каждая из этих задач может быть решена с помощью широкого спектра инструментов (библиотек), не связанных друг с другом. Например, процедуру извлечения данных из хранилища можно выполнить с помощью таких библиотек как GDAL/OGR или OWSLib, рендеринга - Mapnik или MapScript и т.д.

Выбор инструментов

Для решения 1 и 5 задачи подходит любой Веб-фреймворк. Поскольку наши требования к его функциональности достаточно скромные, то нет нужды использовать что-то вроде Django или Pyramid, вполне можно обойтись любым микрофреймворком, таким как Flask или Bottle. Остановимся на последнем.

2-я задача довольно простая, решим её самостоятельно без привлечения сторонних библиотек.

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

Заключение

Таким образом, мы написали свой собственный примитивный TMS-сервер в котором пока нет ни возможности кэширования тайлов, ни многих других важных функций, но который наглядно отражает подходы, используемые современным ПО данного класса.