В этой статье продолжим тему картографического дизайна для веб-картографии.
Ранее в http://geomedia.com.ua/mapdesign.htm рассматривались специфические задачи GPS мониторинга и особенности карт для такого вида проектов. Там была краткая, но критика.
Эта статья посвящена картосоставлению и технологическим аспектам работы для проекта faeton.ua. Она позитивна и созидательна 
один из видов результата на момент публикации статьи
Термины, сленги и написания, которые я никогда исправлять не буду:
Машап – masup;
Паблишер — Geomedia WebMap Publisher;
Геоворкспейс, Документ – Geoworkspace;
Батник, джоб – способы пактеного выполнения срдствами ОС;
Зумин, зумаут, пан, отпанить, зазумить, отзумить — ZoomIn (+),ZoomOut(-) и глагольные производные на их основе.
Задача:
Создать веб-карту для визуализации содержимого БД Фаэтон из одноименного проекта по сбору навигационных даннях в Украине компании Арт-мастер. Это не сайт мониторинга, а скорее демонстрационный картографический веб-ресурс.
Предпосылки:
Проект Фаэтон существует давно, но БД Фаэтон используется в собственных продуктах компании Арт-мастер, т.е. только клиенты сервисов могут видеть данные. Сайт продукта БД Фаэтон (faeton.ua) ориентирован на крупных покупателей данных, содержит в основном описание принципов продукта и статистические данные о объеме составляющих данных. Картографическая визуализация выполнялась для каждого нового населенного пункта или территории добавляемой в очередную версию продукта. Визуализация схематичная, основной целью преследующая показать покрытие. При этом возникало очевидное противоречие: в описании продукта особый упор делается на бесшовность и полноту покрытия Украины, однако продемонстрировать это можно только в офисе компании, открыв всю базу в десктоп ГИС Geomedia. К слову сказать, БД Фаэтон в оригинале существует в полностью реляционнном виде в MS SQL Server 2005.
Предполагалось, что для покупателей из профессиональной сферы работы с геоданными такого подхода достаточно, но многочисленные живые переговоры показывают, что особенно иностранным клиентам недостаточно перечня населенных пунктов. Пришлось даже изобрести подарочный вариант настенной карты для демонстрации покрытия БД Фаэтон потенциальным клиентам.
Однако же очевидно, что легче один раз показать, чем 100 раз рассказать.
Итак, пришло время.
Матобеспечение и техоснащение:
Geomedia Professional 6.1, Geomedia WebMap Professional 6.1 (включает также Geomedia WebMap Publisher), GoogleMap API, SnagIt 8.0;
Сервер под. управлением Windows Server2003 R2: Pentium 3.40GHz D , 4.0 Gb RAM
Алгоритм технической части:
Новый сайт должен использовать БД Фаэтон, но не должен загружать вычислительные мощности существующих сервисов fleet.kiev.ua , delivery.com.ua .
Следовательно -
Создать mashup сайт с использованием GoogleMap API, с использованиемй тайлинга и кеширования картматериала. (сделать это можно в версиях 6.1 семейства Geomedia)
Следовательно -
Создать новый дизайн карт, построеный на возможностях версий 6.1 продуктов Intergraph и воссоздаваемый во всех продуктах и сервисах компании Арт-мастер в дальнейшем.
Требования к дизайну:
Новый оригинальный дизайн, более ориентированный на широкую публику , которой статья про http://geomedia.com.ua/mapdesign.htm неинтересна и непонятна.
Детали процесса и трудности, которые нужно было решать:
Все предыдущие версии картографического дизайна выполнялись в 6.0 версиях продуктов. Разработанная в десктоп ГИС карта публиковалась с помощью Паблишера в веб-проект, в специально измененном скрипте производилась запись методом прекомпиленного файла *cmdf.
После этого на файл напускали специальную самописаную программу, которая позволяла отстроить отображение по масштабам вручную, т.к. к Паблишер настройки масштабов игнорировал (хранил их своим собственным способомв Метабазе). Такая схема работ была довольно продуктивна, потому как позволяла создавать новый дизайн за несколько часов.
Все настройки отображения, масштабов и контента в целом были закомпилены в один единственный файл, что облегчало версионность и деплой.
В тоже время, постоянно изменяемые данные карты всегда подключали «вживую», т.е. апдейты данных вообще не требовали каких либо картосоставительских действий.
Деплой новой, заранее подготовленной версии картографии и ее использование в сервисах выполнялись за 5 минут!
В 6.1 кардинально изменились не только возможности визуализации (основной прорыв был еще в 6.0), но и способы переноса визуальных и картографических техник между десктоп- и веб-приложениями.
Произошел некоторый разрыв в технологиях. Быстро создавать новые дизайны с использованием прекомпиленых карт cmdf стало невозможно, изменился объектный состав Geomedia WebMap: уходят объекты DisplayRules, FeatureStyles, вместо них приходит Библиотека и Легенда (Хотя DisplayRules еще поддерживаются, из следующих версий их уберут)
Основным средством сейчас является Библиотека. Таким образом и декстоп и веб продукты семейства Geomedia используют одну и туже технику и даже напрямую одну и ту же базу данных для хранения всех настроек отображения. Это гарантирует абсолютное соответствие карты при проектировании в десктоп ГИС и в эксплуатации в веб-сайте.
Этой парадигме был в свое время посвящен курс см. http://am-gis.com.ua/mclass1ru/
Использвать одну и туже БД настроек могут программисты, когда разрабатывают сайт с использованием объектов Библиотека.
Техника подобная Библиотеке, на самом деле отработана еще с 5.1 версий в составе продукта Паблишер. Паблишер это продукт для НЕ программистов и он дает возможность создавать картографичсекие сайты вообще без программирования, руками, к примеру ГИС-аналитиков.
Для переноса настроек из десктопа в веб в 5.1 применялась специальная Метабаза (на основе Access или SQL Server) в структурах которой отражались все аспекты, как сайта (координатная система, размер окна, легенды, цвет фона, команды, иконки, лейаут окон), так и дизайна карт (цвета, стили, толщины, символы) всех фичеров, настройки слоев… т.е абсолютно ВСЕ!
Библиотека используемая в 6.1, по сути, является такой БД, но более продвинутой.
Паблишер и сейчас использует собственную Метабазу (построеную вокруг Библиотеки!) для публикации всех аспектов настройки веб-проекта. Типичный проект с использованием стандартного Паблишера можно увидеть http://am-gis.com.ua/mclass1ru/
В Европе и Америке существует множество муниципальных ГИС построенных с использованием стандартного Паблишера и некоторых модификаций скриптов.
Мы не стали менять основную парадигму: все что спроектировано в десктопе, можно 1:1 перенести в веб. Это действительно так и это несложно.
Тайлинг (tiling) и кеширование:
Но попутно нужно было решать еще одну задачу (см. п.2 алгоритма). Сам Паблишерный сайт по умолчанию не использует технику тайлинга, т.е. каждый запрос на генерацию карты живой и приводит к экстракту данных, подготовке визуализации и создании образа (растровой картинки или векторного набора) в виде файла, передаваемого на браузер посетителя сайта. Это отличное решение для динамической информации, и позволяет нам создавать высокопроизводительные системы GPS мониторинга (fleet.kiev.ua), однако карта-подложка по сути своей статична, и ее контент постоянный (до следующего апдейта). На самом деле мы конечно же используем высокоэффективные техники кэширования в продуктах Intergraph (DDC, cmdf, mss) — что это такое вы можете узнать из техдокументации к продукту Geomedia WebMap, но все эти технологи кешируют ЦЕЛОЕ, а не его части и ИСТОЧНИК, а не результат. Кроме того, это кеширование на серверной стороне, а неплохо бы использовать кеширование клиента, обыкновенного веб-браузера, который при настройках по-умолчанию не вытягивает контент, если он уже закеширован, что ускоряет работу на клиенте.
Но обычный сайт Паблишера, так или иначе, но приводит к выполнению основного процесса Geomedia WebMap сервера для генерации картинки для каждого клиента, в рамках которого из источника(-ов) генерируется результат (только один в рамках одного процесса).
Совсем другой механизм предоставляет этот же Паблишер для машап проектов. В версии 6.1 имеется возможность все также с 100% гарантией перенести весь картографический дизайн из десктоп ГИС Geomedia в веб-приложение в виде шаблонного (но сильно настраиваемого) сайта с использованием технологий Geomedia WebMap, Google Maps и Microsoft Virtual Earth. Для машап (mashup) проектов используются способы плиточного (тайлинг) отображения растров в виде PNG или JPEG. Соотвественно, необходимо сгенерировать такие плитки единожды, после чего они будут использоваться в качестве кеша.
Если разработать сайт вообще не на основе Паблишер шаблонов а на чистом Google Maps API, то не понадобиться даже чтение баз данных настроек (метабазы) при работе сайта. (Хотя и функциональность будет попроще, к примеру нельзя бутет манипулировать слоями Легенды).
Именно так и сделано в map.faeton.ua
Это будет не совсем машап, но близкое по сути произведение.
Мелкие детали, которые создают крупные проблемы
В самом Паблишере, условиях его работы, вспомогательных скриптах существует некоторое количество ошибок, которые вероятно не позволяют новичкам «сходу» создать веб-проект, а уж тем более машап, который все-таки сложнее в несколько раз. Трудности нужно преодолеть.
Прежде всего, автору не удавалось нормально отладить работу с Метабазой до тех пор, пока в качестве хранилища для оной использовался Аксесс. Постоянные ошибки с доступом, какие то непонятные блокировки и самое главное — необходимость постоянного рестарта IIS после каких либо изменений в метабазе делали работу невыносимой. Да, Аксесс легок в использовании и бесплатен, но работать с ним в качеcтве Метабазы вне технологии «один клик» невозможно.
Один клик — это технология создания сайта путем нажатиия на кнопку Паблиш Геоворкспейс (Publish Geoworkspace). Это действительно возможно, если все сделать с чистого листа. Как только у вас произойдет сбой, дальше сбои будут лавинообразными, и, если вы не имеете почти телепатического чувства для осознания причин сбоев, скорее всего вы запутаетесь.
Более менее дело наладилось после создания метабазы в SQL Server, хотя это процесс также непрост. В составе Geomedia WebMap есть скрипты создания базы и апдейты к ним, которые нужно выполнить. Сама Метабаза должна быть настоящим географическим Хранилищем (с таблицами GFeatures) о чем нигде не сказано явно , поcле наката всех скриптов все равно руками пришлось подправлять содержимое нескольких таблиц.
Все это можно делать только имея хоть какой то опыт работы с Метабазой. (Два года назад, когда собственно GUI Паблишера был настолько глючный, что работать с ним и с Аксессом было практически невозможно, мы в компании овладели ручным редактирование Метабазы, и успешно. Т.е после первого паблишинга все записи вставлялись вручную и за целостностью БД (связи) приходилось следить опять же вручную. Это было похоже на работу сапера — одна ошибка и все рухнуло. Однако процессом овладела даже наш редактор карт и вполне себе самостоятельно составила проект с 8 уровнями отображения и более чем 100 фичеров) delivery.com.ua
При подготовке использовались некоторые сведения, которые я почерпнул по ссылке. http://dominoc925.blogspot.com/2009/02/generate-google-maps-tiles-with.html
Самое главное — статья убедила в том, что все преодолимо и результат будет. По ссылке и в блоге dominoc925 вообще вы найдете техническую последовательность работы с Паблишером при генерации плиток для машапа, а также последовательность создания машап проекта по шаблону (хотя все это есть в документации, а Визард Паблишера создает проект за 3 минуты)
Я не буду повторять скриншоты, там все просто. Сконцентрируюсь на проблемах картосоставления и дизайна, их объяснении и решениях.
Итак, самое главное, что ставит с ног на голову весь процесс, это ошибка (скорее всего фича, т.к. идеология плавающих масштабов в ГИС и жесткая сетка зумов в Гугле слишком различны), проявляющаяся в том, что Паблишер игнорирует все настройки дисплей рендж сделанные в геомедия. Это значить, что всю красоту, которую вы сделали с помощью таких вот настроек придется потерять. Но ведь терять то не хочется!
Однажды мы уже спасали настройки КритерияРендж в предыдущей технологии Дисплейрул в 5.0, 5.1, 6.0 Вебмапах, поэтому сама по себе задача не остановила, а лишь добавила азарта.
Блог камрада dominoc925 убедил меня в том, что мне не мерещится и в Паблишере действительно есть особенность работы с группами и ее нужно учесть.
Решение: нужно сделать столько групп, сколько у вас масштабных рядов. На практике это приводит к тому, что количество фичеров в легенде умножается на это самое количество дисплейных рядов, вам придется просчитывть дискреты реальных масштабов и забыть о легкости автоматической подгрузки по масштабам. Забудьте про «Дисплей бай Скейл».
Отныне, при составлении веб-проекта только Дисплей ОН и ОФФ. Как же с этим разобраться?
Сначала – масштабы
Нужно признать, что между масштабами в ГИС или картографии (удобные нам 1:1000000, 1:200 000) и тем что использует Гугл нет никакой связи. Т.е конечно же математическая свять есть, но ее как нужно извлечь. Как это сделать?
Сначала я создал стандартный машап сайт с помошью Паблишера по методу «одного клика». По умолчанию Паблишер генерит плитки в реальном времени, когда вы ходите по сайту как пользватель (вкл/выкл легенды, зумин, зумаут).
Если вы внимательно посмотрите кэш, то увидите, как там появляются соответствующие файлы плиток. Вторая цифра в имени плитки это как раз гугловский зум. К примеру, faeton_220_14_9557_5492 — плитка на 14-м зуме соответствующая группе отображения (Легенде) с ID=220 (далее в статье это поясняется подробней). При этом в папке логов ВебМапа появляются логи, которые иногда полезно читать. ВебМап все генерирует в некотором реальном, вычисленном непосредственно в момент генерации масштабе. В логах ВебМапа ищите примерно такие строки:
…
Fri Aug 07 21:17:08 2009(12.675888) – Calculated Map Scale = 36111.981867
…
Вот 36111.981867 как раз и означает, что плитка, соответствующая этой записи в логе получилась в масштабе 1:36111
Составил такую таблицу.
Реальный масштаб ВебМапа Гугловский зум
- 4 622 333 — 16
- 2 311 166 — 15
1 155 583 — 14
577 791 — 13
288 895 — 12
144 447 — 11
72 223 — 10
36 111 – 9
18 055 — 8
9 027 – 7
Чтобы проверить реальность масштабов сопоставим изображения «лицом к лицу».
Все совпадает. (А что это за Макдоналдс? Об этом читайте тут
Итак, оценив правильность подхода, осталось методично все выполнить. И тут возникла сложность: процесс генерации при таких объемах и таком составе карты занимает много, очень много времени, особенно с экспериментами по пути . Учитывая, что задача выполнялась автором в фоновом режиме, да еще и на удаленном сервере, в несколько итераций, на протяжении двух недель, пришлось срочно изобрести велосипед в виде бланковки, на которой отображать состояния. Очень рекомендую, если ваш проект больше университетского городка
Кроме того нужно освоить постановку задач (джобов) в Виндоуз Сервер, и особенно уделить внимание планированию джобов на выходные дни и ночи будних.
О Гугле.
но можно и так: «О, Гугле!»
Прежде всего взглянем на ГуглМапс трезво. В модели отображения мира от Гугл 19 масштабов! Если бы пришлось составлять карты для каждого, от такого количества групп ум за разум зашел бы точно. Однако зачем нам мир? У меня в задаче конкретно Украина, простирающаяся от 22 до 41 по долготе и от 44 до 52.5 по широте. Все это, при проведении пробной генерации показало, что достаточно использовать 7-16 ряды зумов Гугла . На 6-м зуме на экране помещается вся Украина целиком (мне не нравиться такое отображение, когда по краям «молоко», поэтому я всегда отображаю на старте страну несколько выходящую за пределы экрана), т.е выбрал 7-й зум, сравните привлекательность:
На 7-м зуме супер классно!
На 6-м зуме погано 
Дело даже не в том, что на втором рисунке много подписей (хотя чтоб поправить ситуацию, пришлось бы делать еще один уровень отображения и отобрать только подписи областных центров), а в том, что Украина имеет такую форму, что при полном вписывании в прямоугольник карты, 50% площади это «молоко», что меня лично очень раздражает.
Вероятно сильно повезло картографам в штате Юта
На другом конце зумов выяснилось, что на 13-м на экране помещается в среднем 5 мелких населенных пунктов (села, поселки) или 30-60% крупного города.
13-й зум в сельской местности
13-й зум в городе
Это приемлемый, с точки зрениия юзабильности, результат, т.к. более подробный зум в сельской местности приводил бы к «молоку» (не смейтесь, у нас был случай с клиентом, который отпанаромировал карту далеко на Марс и утверждал, что «все пропало». Думаю каждый, кто реально внедрял ГИС сталкивался с такими случаями).
Следовательно, в общем, для территории Украины хватило бы ряда в 7-13 гугловских зумов, но в БД Фаэтон множество городов, а для отображения дорожных развязок, одностороннего движения, подписей улиц, адресов, кварталов и домов необходим более подробный зум. Скрипя сердцем я добавил в проект необходимость 14-16 зумов, но твердо решил не доходить до гугловского края в 19, т.к. мне это точноне нужно.
Город на 14-м зуме
Город на 15-м зуме
На 16 зуме пришла пора включить все подписи, которых явно не хватает на картинке выше, поэтому этот уровень отображения будет в проекте отдельным и будет переделан:
Вот так и будет выглядеть карта на 16-м зуме
Итого: начинаем с 7-го и заканчиваем на 16-ом. Это в общей сложности 10 зумов, что кажется многовато, так как нужно спроектировать бесконфликтное и читабельное отображение фактически 10 карт! При этом ничего не перепутать и не забыть. Хотелось бы еще сделать слой подписей отдельно, т.е. на самом деле карт нужно вдвое больше (все масштабы с подписями и без).
Захотелось соптимизировать
Полдня экспериментов с масштабами показали, что эти 10 Гугловских зумов реально, с минимальным ущербом для читабельности нашей карты разбить на такие скомплексированные воедино ряды [7-9], [10-13],[14-16]. Итого мы имеем 3 ряда, т.е три масштаба отображения. Нужно составить три карты (сравните с изначальной задачей в 19 карт согласно формальных Гугловских возможностей!).
Логика примерно такая: для каждого ряда существует масштаб в ряду в котором все идеально, масштаб в котором все неплохо, и масштаб в котором как-то «не очень», но не ужасно :-) Понятное дело, что это, во многом компромисс, и подписи идеально читабельные на 9-м зуме будут толкаться и несколько мешать друг другу на 7-м. Но это и называется — компромисс
Наиболее критичным объектом, который портит технику комплексирования масштабов являются подписи населенных пунктов (забегая вперед скажу, что они порождают и другую проблему, решить которую не удалось).
Кроме того Украина довольно густонаселенная страна, и плотность нас.пунктов велика. Это означает что во всех выбранных 3-х картах техника отображения населенных пунктов была разной.
На рядах 7-9 т.е. начиная с масштаба 1:4 622 333 и крупнее до 1:1155583 отображались областные центры и города областного подчинения пунсонами и подписями к ним. Всего было 4 стиля подписей, соответствующие 4-м уровням административного подчинения населенных пунктов в Украине.
Список…
На зумах 10-13 все населенные пункты уже отображались полигонами, но возникло 4 стиля отображения полигонов (цветом заливки) и 4 стиля подписей к ним. На 10-13 зумах дополнительно пришлось уменьшить размер некоторых классов подписей в абсолютном выражении, т.к плотность нас.пунктов сильно возрасла и конфликтов подписей было много.
На всех рядах также пришлось повозиться с гидрографией, т.к. рек в Украине тоже много. Все они условно разделяются на 3 класса. Забавный эффект возник, когда я не отключил реки, и они на карту вышли все.
красивый эффект случайно
Картинка понравилась, т.к. страна стала «полнокровной» и объемной, но после некоторых колебаний этот эффект все таки устранил.
Осталось придумать как отобразить уровень с домами и адресами: идеальным был бы 18-й, как у Гугла, но я счел приемлемым 16-й (М 1:8789), на котором все очень даже прилично читается, а работы по генерации соответственно уменьшилось на порядки. Здесь и далее везде, помнить нужно о поистине титаническом объеме вычислительной работы сервера по генерации. Каждая плитка это всего-лишь 256 на 256 пикселей, а один «квадратный градус» на [14-16] зумах содержит 57 845 плиток. Площадь Украины 171 «квадратный градус»! (см. раздел Производительность генерации)
три основные группы: Бейс, Эджес и Лейблс
Моя задача (отображения данных БД Фаэто(тм)) допускала такой принцип картосоставления: три условных группы: Бейс (вся топографическая основа: реки, леса, острова, населенные пункты, административное деление: области,районы), Эджес (все линейные объекты автодорожной сети, которые и составляют сеть БД Фаэтон), к ним были добавлены слои железных дорог, отобранные и упрощенные и, наконец, Лейблс — все виды подписей (населенных пунктов, гидрографии, улиц, номеров домов, направлений одностороннего движения, POI, станции и т.д.), которые в любой карте должны быть сверху и по возможности отдельно (для создания гибридов со спутниковыми снимками). На рисунке. можно увидеть все группы, которые мне пришлось создать. Нужно понимать, что в каждой группе состав фичеров практически одинаков, за исключением тех, которые нецелесообразно отображать на соответствующих масштабах. Такую работу лучше проводить сверху вниз:
1. Делаем легенду в которой сначала есть абсолютно все фичера и все стили. Отрабатываем основные стили, что потом не переделывать во множестве легенд. Ввиду месива на экране постоянно что-то выключаем и включаем, чтобы разглядеть детали карты
2. Формируем разбиение на группы Бейс, Еджес и Лейблс перетаскивая драг-н-дропом, следим чтобы не было дублей (потом их будет так много, что пришлось придумать специальный сценарий поведения при работе с ними)
3. Сохраняем легенду Name Legend как нечто базовое, к примеру NewDesign
4. Создаем на базе именованной легенды новое окно карты, называем его по имени ряда, к примеру 10_14, создаем именованную легенду с этим же именем 10_14
5. настраиваем отображение выбрасывая или добавляя фичера, играемся с толщинами линий и проверяем читабельность строк в выбранных масштабах (см. таблицу)
6. постоянно боремся с желанием увеличить число рядов, чтобы разнести масштабы и улучшить визуализацию
7. каждый новый ряд делаем повторяя пункты 1-6
8. в итоге в документе будет столько окон карты, сколько у вас масштабных рядов, а в каждом окне будет своя легенда. Все это должно быть грамотно поименовано, т.к. смотреть в Паблишере вы будет именно на эти названия, а при генерации вообще будет оперировать ID, которые соответствуют группам.
Публикация с помощью Паблишера
О! это самый волнующий момент, ибо до сих пор все действия означали только игру в картографический дизайн, а с этого момента появляются надежды на создания продукта, т.е. в нашем случае машап сайта.
Паблишер устроен так, что позволяет постоянно синхронизировать содержимое Документа.gws и Метабазу, причем в обоих направлениях. (Это значит, что при имеющейся Метабазе документ вообще уже не нужен, его можно воссоздать одним кликом) Это, кстати, чудесный способ обмена картографическими настройками в рабочей группе, которым мы пользовались еще в 5.1 когда не было такого понятия как Библиотека.
Есть, однако, ложка дегтя. Точно не знаю по какой причине (слишком уж много факторов), однако в моей конфигурации среды невозможно было пользоваться только кнопками синхронизации: постоянно вылазили баги копирования какого то объекта легенды. Чтобы вы только представили объем действий Паблишера с Метабазой, посмотрите SQL логи, которые он ведет. Зрелище не для слабонервных. Естественно лечить его у меня не было времени и натхнення (чисто укр.:-), поэтому эмпирическим путем было найдено золотое правило: Паблишер нужно юзать в режиме «одной кнопки», т.е. полностью готовый документ с помощью «Паблиш геоворкспейс» загонять в метабазу. Каждый раз Паблишер спрашивает: затирать предыдущую информацию? Я говорю- ДА! (поначалу затаив дыхание) И натужно скрипя скриптами Паблишер загоняет всю мою жуткую каскадную картографию в Метабазу.
Единственное, что я после этого делаю, это захожу в легенду Паблишера и проставляю комплексирование групп (чекбоксом). Это как раз самый важный момент. Все, что подлежит ветке с ID, который вы чекбоксом замыкаете выйдет в виде единого слоя, т.е PNG картинки. Итак ГРУППЫ это единственный способ создания слоев для машапов.
Применительно к моей задаче, я сначала генерировал PNG разрозненно для Бейс, Эджес и Лейблс в надежде поиграть с ними уже в Google Maps API и создавать шикарные гибриды:
• спутник+Эджес+Лейблс
• Бейс+Эджес+Лейблс
(опять же забегая вперед, скажу, что с некоторого момента я эту идею отбросил и упростил генерацию до 2- типов: все с подписями и все без подписей. Это тоже называется — компромисс.)
Проверить целостность Метабазы после публикации лучше всего с помощью скрипта Mashup Tile Management, который в оригинале предназначен для создания управляющего генерацией плиток XML-файла. Он находится по адресу
http://localhost//admin/mashups.asp
Машап проект с точки зрения скрипта подготавливающего управляющий XML-файл. (открыт стандартный Демо проект, создать который можно за 1 минуту)
Снова забегая вперед, скажу, что с помощью Mashup Tile Management я только убеждался что база не навернулась и цела-невредима, а XML-файл я успешно правил руками и переименовывал под планирование запуска опять же переименованых bat в Джобах в Windows Server. Когда вам нужно сгенерить 1 млн. плиток в 9 джобах умноженных на 3 ряда, в течение 2-х недель, некоторая оптимизация не навредит
Генерация плиток
Выполняется запуском tilegen.bat из состава Паблишера, который я модифицировал следующим образом:
net stop “GeoMedia WebMap”
net start “GeoMedia WebMap”
cscript tilegen.vbs //NoLogo “(1)14_16.xml”
pause
Опять же опыт показал, что в моей среде без перегрузки ВебМапа каждый следуюший процесс Паблишера по генерации плиток не стартует, а заваливается (иногда) или просто ничего не делает молча (чаще). Если вы одновременно выполняете кучу действий с Паблишером, ISS, ВебМапом и Геомедией..потом уходите с ремоута на свой комп, возвращаетесь через 20 минут, то вдруг понять что-же это за ерунда такая с ошибками бывает непросто.
Сразу же приклею и соответствующий XML:
“
<?xml version=”1.0″ encoding=”utf-8″?><tilegen appname=”faeton” minzoom=”14″ maxzoom=”16″ overwrite=”no” autorange=”no” xmin=”30″ ymin=”51″ xmax=”31″ ymax=”50″>
<le>220</le>
</tilegen>
“
Обратите внимание на то, что 220 это собственно все, что нужно — это ID мега-группы содержащей все другие группы. Т.е. в результате выполнения конкретно этого XML будет один слой картинок-плиток. На картинке будут все мои тематические слои сразу согласно порядку отображения спроектированному в десктоп ГИС Geomedia.
Еще один трюк, который задолбал меня совершенно, но в итоге я с ним смирился. Обратите внимание, что ymin=”51″,а ymax=”50″, странно не правда ли? Если вы будет пользоваться страничкой для генерации XML: Mashup Tile Management в первый раз вы долго будете мучаться «что же оно хочет», и как же так!
Я изменил и сам файл tilegen.vbs, отладил его, чтобы понять как же пределы координат используются самим методом:
set tileGen = WScript.CreateObject(“GWMPub.TileGen”)
if rangeProvided then
trace “Calling GenerateTiles with range”
tileGen.GenerateTiles appName, legendEntries, minZoom+1, maxZoom+1, overwrite, autorange, xmin, xmax,ymin,ymax,
В итоге пришел к выводу, что интерпретация такая: в XML первая пара это нижний левый, а вторая пара это верхний правый углы географического пространства, которое нужно замостить плитками. Это совершенно не то, что ожидаешь от переменных с названиями Ymin и Ymax, ну да ладно.
То, что красным, я тоже изменил, ибо обнаружил, что при задании в XML пределов 10-13 в итоге генрируется 9-12. Я как то люблю следующее обозначение пределов [ ] и так мыслю, с включеним граничных. Не знаю был ли этот баг раньше, но в итоге я достиг состяния: все работает.
Вот пример из проекта Демо (стандартные неизмененные скрипты). Видно, что при запросе на генерацию зумов [1-2], получаемые файлы имеют нумерацию зумов 0-1.
С другой стороны Гул использует 1-19 нумерацию, что можно проверить, сделав отладочный инфо-бокс. Когда вы задаете 13-й зум, то именно 13-й зум и есть!
Возможо разработчики Интерграф в шаблонах Паблишерного сайта машап где-то незаметно сдвигают эту индексацию. У них то все работает! Быстрый поиск пока не дал результата, но перекапывать чужой код как то не хочется. Anyway, проблему решил!
О производительности:
Эмпирически вычисленная производительность на достаточно загруженном сервере (очень часто другие процессы загружают от 50 до 70% процессоров) была вычислена по логам Вебмапа.
Один из кусков сериала генерации составил:
….
Fri Aug 07 21:16:55 2009
Sat Aug 08 13:52:12 2009 (59712.184285) секунд
…….
За это время WebMap сгенерил 57 845 плиток, т.е. 0.96 плиток в секунду.
Опять же, на моем сервере довольно сложные условия, там работает SQL Server, который периодически занимает 60% процесора и выжирает 1.5 гигабайта памяти. Поэтому у меня при генерации плиток возможны и такие обломы:
Утешает только то, что при этом успел сгенерировать
Tue Aug 11 19:56:20 2009(0.000003)
Wed Aug 12 11:37:33 2009(56469.581204)
46698 плиток, т.е. 0.82 плиток в секунду.
Очевидно, что производительность несколько упала. Теперь понятно, что весь процесс генерации необходимо вынести в идеальные условия и разбить на гарантированно «съедобные» куски.
На самом деле ничего необычного в таких проблемах нет, т.к. сам по себе процесс генерации такого количества чего-либо впрок рискован и выполняется с любыми ухищрениями, т.к. результат того стоит — ведь в эксплуатации тайловая картография вообще не будет использовать вычислительные мощности сервера. Упрощая, можно считать, что нагружаться будет только дисковая подсистема, пулеметом выдающая плитки по запросу веб приложения. А IIS (веб-сервер) как раз и оптимизирован под такого вида задачи.
Сама идеология подготовки плиток для тайловой веб-картографии как нельзя лучше иллюстрируется пословицей «Любишь кататься, люби и саночки возить»
Все мои ноу-хау одним списком:
1. Отдельные легенды, отдельные окна для каждой карты в Геомедия
2. Публикация Паблишером методом «одного клика»
3. Пробивание чекбокса групп вручную после публикации, выписываие ИД, который при этом отображается
4. Самопальные XML (меняю только ИД легенды и пределы координат)
5. Рестрат вебмапа перед генерацией (занес в батник)
6. Разобраться с пределами (править можно в XML, а можно и в tilegen.vbs, без разницы, главное чтобы в метод tileGen.GenerateTiles приходило: нижний_левый, верхний_правый)
7. Всегда задавать пределы в четких градусах и отмечать на бланковке каждую партию генерации
8. Следить все ли сгенерировалось или произошел сбой
9. Спасать плитки перед изменениями в Документе и последующей ре-публикацией (Паблишер стирает все плитки из кеша, когда происходит публикация). Я спасаю результаты перименовывая папку tilecache набитую файлами, к примеру в tilecache14_16.
Долгожданное удовольствие
После того как вы успешно все настроите и запустите tileGen.bat, в папке tilecache вашего проекта (дословно: веб приложения (сайта) машап для Google Maps, созданного с помошью публикации Geomedia WebMap Publisher-ом карт, в свою очередь, составленных в десктоп ГИС Geomedia Professional) будут образовываться такие чудные плитки:
Меня этот процесс завораживает, как, в общем-то, любой конвейер, который «как бы» работает сам. В этот момент я забываю сколько усилий нужно приложить, чтобы он все таки заработал.
Примерно такой же восторг я получаю от телепрограмм цикла «How it’s made» на канале Discovery.
————конец 1-й части————–, продолжение следует.
