Мультивременные слои в GeoMixer WEB-GIS - История изменений

Александр Мурый в 08:42, 10 декабря 2013

2013-12-10T08:42:38Z

← Предыдущая версия		Версия от 10:42, 10 декабря 2013
Строка 1:		Строка 1:
	{{Статья\|~~Черновик~~}}		{{Статья\|Опубликована\|geomixer-multitemporal-layers}}
	{{Аннотация\|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}		{{Аннотация\|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

Parshin: /* Как оно работает (скучный технический раздел :) */

2013-12-05T21:15:59Z

Как оно работает (скучный технический раздел :)

← Предыдущая версия		Версия от 23:15, 5 декабря 2013
Строка 61:		Строка 61:
	[[Файл:Geomixer_temporal_vector_tiles.png\|center\|400px\|]]		[[Файл:Geomixer_temporal_vector_tiles.png\|center\|400px\|]]
	<p style="text-align: center">''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''</p>		<p style="text-align: center">''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''</p>


	Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.		Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.
Строка 79:		Строка 78:
	<p style="text-align: center">''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл содержит примерно одинаковое количество данных, так что при увеличении протяжённости во времени размер тайла в пространстве уменьшается.''</p>		<p style="text-align: center">''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл содержит примерно одинаковое количество данных, так что при увеличении протяжённости во времени размер тайла в пространстве уменьшается.''</p>

	Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (~~кстати~~, ~~определение этого набора тоже интересная задачка~~, ~~которая~~ может ~~быть решена разными способами~~).		Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы.

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

			На клиенте при показе на карте мультивременного слоя API вычисляет временны́е рамки запроса и выбирает подмножество тайлов, которые нужно запросить с сервера. Пример: пусть на сервере хранятся тайлы длительностью день и неделя, а пользователь выбрал период в 10 дней. У нас есть вариант запросить тайлы за 10 дней по отдельности, за неделю и отдельно за 3 оставшихся дня, или за две недели. Последний вариант может оказаться предпочтительнее, если общее количество данных мало (из-за меньшего числа запросов на сервер).

	~~Процесс построения мультивременных тайлов выглядит следующим образом. Сначала мы формируем~~ тайлы ~~длительностью~~ в~~, скажем, один день~~. ~~Берём исходные данные, и выбираем из них данные за первый день~~ (~~мы предполагаем~~, что с каждым объектом связана определённая дата). По отобранным данным строим тайлы как для обыкновенного векторного слоя (в тайлах, ~~конечно~~, ~~запоминаем~~, ~~что это тайлы за первый день~~)~~. Затем выбираем данные за второй день, строим для них векторные тайлы и т.п. пока не переберём все дни~~, за ~~которые есть данные. На следующем этапе начинаем формировать тайлы протяжённостью в,~~ например, неделю. Выбираем из исходных данных все объекты, относящиеся к первой неделе и строим для них тайлы как для простого векторного слоя. Затем берём данные за вторую неделю и т.п. Далее мы можем аналогично построить наборы тайлов за месяц, квартал, год и т.п. Описание всех полученных тайлов передаётся на клиент, где наш API уже сам решает, какие тайлы лучше запросить в зависимости от того, что пользователь захотел увидеть на экране.		Поскольку все тайлы имеют примерно одинаковый размер, основным критерием выбора в ГеоМиксере является общее количество запросов на сервер для получения всех нужных данных. Если протяжённости во времени всех тайлов кратны друг другу (скажем, 1, 4, 16, 64 дня), минимизировать эту величину можно за один проход по списку тайлов(например, при помощи какой-нибудь древовидной структуры).

	~~Такой подход~~ позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).		Описанное решение позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).

	== Банальное заключение ==		== Банальное заключение ==

Parshin: /* Как оно работает (скучный технический раздел :) */

2013-12-04T08:28:30Z

Как оно работает (скучный технический раздел :)

← Предыдущая версия		Версия от 10:28, 4 декабря 2013
Строка 77:		Строка 77:

	[[Файл:Geomixer_temporal_temporal_tiles2.png\|center\|500px]]		[[Файл:Geomixer_temporal_temporal_tiles2.png\|center\|500px]]
	<p style="text-align: center">''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл ~~имеет~~ примерно ~~одинаковый размер~~ данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''</p>		<p style="text-align: center">''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл содержит примерно одинаковое количество данных, так что при увеличении протяжённости во времени размер тайла в пространстве уменьшается.''</p>

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

Parshin: /* Как оно работает (скучный технический раздел :) */

2013-12-04T08:13:56Z

Как оно работает (скучный технический раздел :)

← Предыдущая версия		Версия от 10:13, 4 декабря 2013
Строка 70:		Строка 70:

	[[Файл:Geomixer_temporal_temporal_tiles1.png\|center\|700px]]		[[Файл:Geomixer_temporal_temporal_tiles1.png\|center\|700px]]
	<p style="text-align: center">''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый ~~квадратик~~ — отдельный тайл с данными. По горизонтальной оси условно показан размер тайла в пространстве, а по вертикальной — его протяжённость по времени.''</p>		<p style="text-align: center">''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый прямоугольник на графике слева — тайлы для данных за один конкретный день.''</p>

	Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!		Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Parshin: /* Как оно работает (скучный технический раздел :) */

2013-12-04T07:01:15Z

Как оно работает (скучный технический раздел :)

← Предыдущая версия		Версия от 09:01, 4 декабря 2013
Строка 63:		Строка 63:


	Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на ~~диск~~. Клиенту просто отдаём статические файлы. Степень разбиения ~~контролируется~~ размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.		Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

			Алгоритм построения тайлов для набора векторных объектов выглядит примерно так. Сначала вычисляется общий размер данных для всего набора. Если он меньше определённого порога, то всё записывается в один тайл, и процесс завершается. Если размер данных слишком большой, данные делятся на 4 части в соответствии со своим положением в пространстве. Для каждой части процесс повторяется.

	Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.		Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.
Строка 79:		Строка 81:
	Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).		Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

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

			Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).

	== Банальное заключение ==		== Банальное заключение ==

Denis Rykov в 08:21, 2 декабря 2013

2013-12-02T08:21:05Z

← Предыдущая версия		Версия от 10:21, 2 декабря 2013
Строка 63:		Строка 63:


	Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем ~~них~~ на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на диск. Клиенту просто отдаём статические файлы. Степень разбиения контролируется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.		Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на диск. Клиенту просто отдаём статические файлы. Степень разбиения контролируется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

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

Parshin: /* Примеры */

2013-12-01T14:41:05Z

Примеры

← Предыдущая версия		Версия от 16:41, 1 декабря 2013
Строка 45:		Строка 45:
	Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!		Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

	При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).		При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

			Так же мы экспериментируем с различными дополнительными элементами управления для анализа временно́й компоненты данных. [http://www.youtube.com/watch?v=VaPJFivbN7c Вот пример] работы с одним из таких инструментов - "таймлайном". Этот инструмент упрощает понимание того, как данные из некоторой пространственной области распределены во времени.

	[[Файл:Geomixer_temporal_ais.png\|700px\|center]]		[[Файл:Geomixer_temporal_ais.png\|700px\|center]]

Paleogis: /* Примеры */

2013-11-29T14:52:09Z

Примеры

← Предыдущая версия		Версия от 16:52, 29 ноября 2013
Строка 39:		Строка 39:
	В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.		В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

	Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89\| пожары за весь прошлый год на Московскую область].		Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89 пожары за весь прошлый год на Московскую область].

	[[Файл:geomixer_temporal_landsat8.jpg\|700px\|center]]		[[Файл:geomixer_temporal_landsat8.jpg\|700px\|center]]

	Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8\| Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9\| съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!		Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

	При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9\| доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).		При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

	[[Файл:Geomixer_temporal_ais.png\|700px\|center]]		[[Файл:Geomixer_temporal_ais.png\|700px\|center]]

Paleogis: /* Примеры */

2013-11-29T14:46:11Z

Примеры

← Предыдущая версия		Версия от 16:46, 29 ноября 2013
Строка 35:		Строка 35:
	[[Файл:Geomixer_temporal_hotspots.png\|700px\|center]]		[[Файл:Geomixer_temporal_hotspots.png\|700px\|center]]

	Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9\| любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].		Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9 любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

	В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.		В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Parshin в 12:40, 29 ноября 2013

2013-11-29T12:40:17Z

← Предыдущая версия		Версия от 14:40, 29 ноября 2013
Строка 84:		Строка 84:

	== (Бес)полезные ссылки ==		== (Бес)полезные ссылки ==
	* [http://gis-lab.info/qa/geomixer.html\| Краткий обзор GeoMixer WEB-GIS]		* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
	* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis\| Пользовательская документация GeoMixer]		* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
	* [http://geomixer.ru/api_reference\| GeoMixer API Reference]		* [http://geomixer.ru/api_reference GeoMixer API Reference]