Новую версию ждали с особым нетерпением. Еще бы, ведь в анонсах значились коренные изменения в таких фундаментальных механизмах как отображение данных, впервые серьезно менялся пользовательский интерфейс такого центрового для продукта объекта как Легенда, систематизировались средства экспорта данных, а также, что наверное самое ценное, Geomedia должна была стать полностью корпоративным продуктом- поддерживать не только данные в единых базах предприятий(в этом GeoMedia первопроходец), но и такие методы работы с ними как стили отображения, запросы, соединения с данными.

И действительно, для такого «датабейс-центристского» продукта как Geomedia , который с рождения в далеком 1996 году использовал невиданные для того истинно реляционные понятия в геоинформатике, абсолютно логичным и давно ожидаемыми были функции по полной централизации b "утабличивании" всего, что может быть использовано в коллективной работе в пределах организации. Тем более, что исторически все продукты корпорации Integraph предыдущих поколений и были рассчитаны на организации, коллективную работу профессионалов различных отраслей.

И мы дождались!

Library (Библиотека)- впечатляющее средство по сохранению и повторному использованию всех компонент документов (GWS) Geomedia. Теперь реально можно использовать результаты труда ваших коллег и с каждой новой реализованной задачей по картосоставлению или геоинфорационному анализу вам все меньше времени придется тратить на опостылившие уже задачи раскраски базовых карт и раскодирования фичеров. По-просту говоря, у вас теперь появилась возможность перейти с документоориентированой среды в ориентированную на базы данных среду.

Стоит вспомнить, что и документоориентированые среды были очередным, возможно и достаточно важным шагом для ГИС. Различные ГИС по разному реализовывали концепцию документа, для некоторых это были просто «файлы проекта», собирающие пути на файлы данных в директории и именующие некоторую проектную сущность, а также хранящие способы раскраски объектов и прочие «изобразительные» особенности; для Геомедия - документ всегда было более сложное понятие, хотя бы из-за уникальных динамических особенностей Pipes-механизмов и принципиально «коннектной», а не файловой основы доступа к данным. Все цепочки Pipes хранились в Документе (GWS-файл) и при открытии Документа отрабатывались «вживую».

Все это конечно очень удобно для геоинформационного анализа с созданием динамических моделей, так называемого what if («что будет, если…») анализа.

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

Геомедия безропотно выполняет все цепочки Pipes в памяти и после напряженного творчества в течение нескольких часов,я создавал сложнейшие «колена» из Pipes, в некоторых случаях даже утратив полное понимание того что и как, в какой последовательности и за что цепляется в этих цепочках.

Не особенно спасает даже возможность именовать на родном языке и достаточно длинными фразами все промежуточные наборы данных. Нехватает технарской лексики :-) После четырех-пяти колен, вы уже живете результатом, а не промежуточными данными, а назавтра и подавно можете не вспомнить что такое, например «AQ_MainRoad - Buf_AQ_MainRoad - SQ_L4L and Buf_AQ_MainRoad - SI_Buf_AQ_MainRoad - Buf_SI_Buf_AQ_MainRoad - SD_Buf_SI_Buf_AQ_MainRoad - SD_SD_Buf_SI_Buf_AQ_MainRoad». (кстати, если вам интересно-а что это такое-кликните здесь)

Дальше- больше, назавтра с утра при открытии документа, Геомедия честно отрабатывает все запросы, которые как матрешка содержат другие и так далее .. куда моя фантазия завела вчера. Классно! Мне нравится подход «живой динамики», но… Как и любой человек, я создаю невообразимое количество промежуточных, пробных и просто ошибочных результатов.. не всегда удаляя их из памяти (и соответственно Документа) ГИС Геомедия.

Мой рекорд - 5-8 минут открытия Документа, правда на стареньких еще версиях Геомедия 2.0,4.12 и машинах с 256 Мб памяти и 800 МГц процессорами(ок.2000 г.). Но все же- немного перегружено, не так ли?

Народная мысль откликнулась, и вскоре появились команды «Выгрузить запросы из памяти …» для 5.1 версии (сейчас эта команда- часть стандартной Geomedia 6.0), да и я, поумнев, стал использовать опцию «Не загружать данные в Легенду» при открытии Документа. Но это все как-то близко, но все еще не то, что нужно. Ведь в Легенде обычно находится то, что нужно видеть, а значит вы обязательно догрузите эти данные, хоть и не сразу. Да и проблема моя в общем-то не в неуемной фантазии, а в желании воспользоваться результатами своего труда не один раз и поэтому- в хранении многослойных результатов в одном документе. А вот это уже чистая концепция Повторного Использования(ПИ). Ох, как же близка моей, тогда программистской душе, была эта концепция. Мечта- сделать однажды и использовать многократно! (Лень- двигатель прогресса).

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

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

Но вернемся к Геомедия 6.0…

Легенды, Динамические запросы, Пространственные фильтры, Стили, Соединения с базами данных - все это теперь можно "переливать" из документов в базу данных Библиотек и обратно. Воплощенная концепция Повторного Использования в многопользовательской среде.

Итак Library (Библиотека) это и есть вожделенная мечта моих руководителей в прошлом :-).Только невпример круче, хотя и только для Геомедия. Да, кстати, а зачем другие ГИС? :-)

Чем же круче? Ну, во-первых тем, что в библиотеке можно хранить не только символику (покраску) объектов, но и сами структурные едиицы карт- Легенды(упорядоченные по отображению, масштабу и проч. списки объектов), а также абсолютно любые Pipes, т.е. любые запросы и цепочки оных, поименованные как вам угодно и в любом количестве. Так как библиотека это по сути реляционная база данных, то досткп к ней можно организовать с любого рабочего места Геомедия, а значит и воплотить концепцию ПИ не только в индивидуальном порядке, но и для целого коллектива!

Прощайте файлы, нечаянно удаленные и забытые, промежуточные и версии типа «самая_последняя», «самая_самая_последняя»,неоткрывающиеся (было и такое) и перегруженые!

Теперь у меня в основном логика работы такая:

1.Открываю пустой файл(точнее создаю налету по шаблону)

2. Подключаюсь к библиотеке

3. Закачиваю все, что нужно

4. Творю

5. Если создал нечто полезное и несиюминутное- закачиваю в библиотеку.

Ну и само приятное (правда, это в случае, если у вас есть подчиненные): Я могу поручить ведение корпоративной базы геоданных и единой библиотеки одному человеку – администратору (и это буду не я! :-)  Абсолютно без злорадства: это воплощение другой, весьма уважаемой мною концепции - локализация ответственности(ЛО). ЛО позволяет поднять эффективность и надежность любого производства, в том числе и проектирования ГИС, ведения банков данных. Есть один источник данных, один ответственный за них и всегда понятно и известно с кого спрашивать за беспорядок и(или) кого поощрять за консолидацию усилий коллектива.

Итак, мы имеем теперь возможность создавать как личные так и копоративные хранилища Библиотек

Личные вполне выживут и на Access,  а вот корпоративные лучше создавать на  MS SQL Server (хватит и бесплатной версии  MS SQL Server  DE ) - MS SQL-ная база данных технологичней в вопросах  администрирования доступа, бэкапирования и  производительности. Корпоративные Библиотеки- реальный срособ повысить производительность труда за счет ПИ, соблюсти  стандарты и устранить неразбериху версий на предприятии.

Ed~