Владимир Андрианов, старший эксперт DATA+
Есть такое мнение, что ESRI всех нас «кинул»: вместо того, чтобы и дальше развивать очень даже неплохие продукты ARC/INFO и ArcView GIS, нас заставляют изучать новую архитектуру, напичканную зубодробительной терминологией и крышесносящими концепциями, и полностью переделывать приложения, написанные (можно сказать, кровью 😉 на Avenue и AML. А в это время проповедники от ESRI вещают о новых горизонтах геопроцессинга, всеобщем скрещивании ГИС с Интернетом, объектах, компонентах и прочих новомодных ужасах компьютерных технологий. Windows правит бал, UNIX забыт. O tempora, o mores! Кошмар! (оратор падает со сцены, уносят)
В таком мнении есть своя доля правды, но о-о-очень небольшая, а полуправда часто оказывается от истины дальше, чем чистая ложь. Правда здесь в том, что ESRI действительно создал новую архитектуру ГИС, и в том, что Интернет всё большим числом людей рассматривается как среда распространения пространственных данных и предоставления вычислительных услуг, и в том, что новая архитектура дает больше возможностей работы с геоданными и моделирования реального мира, чем всё, что было до того. Но из этого не следует, что вам нужно срочно переделывать все свои старые приложения, а простым смертным пользователям обкладываться томами компьютерной литературы, чтобы научиться грамотно нажимать на кнопки интерфейса.
Вспомним, чем была первая версия ArcView. Всего лишь вьюером покрытий ARC/INFO. Во второй версии появился собственный открытый формат данных (шейп-файл), и с добавлением инструментов редактирования в третьей версии продукт стал достаточен для построения самостоятельной ГИС. Что и было отражено добавлением в название слова GIS. Мы получили ArcView GIS 3.0, ставшую вскоре самым популярным ГИСпакетом. А между прочим, продукт был разработан в среде UNIX, и жил он в Windows благодаря межплатформенному интерфейсу компании Neuron Data.
Примерно в то же время можно было наблюдать стремительное распространение Windows 95 и развитие объектноориентированных сред разработки приложений. Какой-нибудь скромный студент теперь мог «одной левой» сотворить очень даже приличное приложение, на создание которого прежде потребовалась бы целая команда программистов, опытных в разработке сложных приложений. Этот качественный скачок оказался возможен благодаря тому, что появился новый фундамент — компонентная модель построения программ, а многие рутинные (хотя и сложные в реализации) функции приложений взяла на себя операционная система.
Первым продуктом ESRI, испытавшим на себе прелести нового подхода, был MapObjects — набор картографических программных компонент для встраивания в приложения пользователя. Все, кто с ним работал, отмечали его существенно более высокое быстродействие по сравнению с ArcView GIS под Windows. Объясняется это тем, что MapObjects изначально разрабатывался в среде Windows на основе Microsoft Foundation Classes — компонентов для создания Windows-приложений. MapObjects быстро развивался и скоро стало понятно, что на нем вполне возможно создать собственный (упрощенный) вариант ArcView GIS. Что, в общем-то, и было сделано — появился ArcExplorer. Но это был еще только одинокий лучик в темном царстве (на черном экране) командной строки и специализированных языков разработки. А тем временем…
Бурное развитие Интернета породило спрос на средства представления карт во Всемирной паутине (WWW). Ответом ESRI был выпуск картографических Интернетсерверов (Internet Map Server, IMS) — MapObjects IMS и ArcView IMS. Почему два? Потому что оба продукта имеют средства визуализации карт, запросов и навигации по ним, и нужно просто добавить программный блокпосредник, который будет пересылать картинку из Вида веббраузеру пользователя, а от него получать инструкции по управлению базовым продуктом. Скажем, нажал пользователь на вебстраничке с картой кнопку «Увеличить» — IMS виртуально «нажимает» кнопку «Увеличить» на панели кнопок ArcView GIS, картинка обновилась — IMS отсылает ее пользователю. В общем-то любой опытный программист мог бы создать свой IMS. (Тем, кто хочет таким образом заменить IMS от ESRI, нужно иметь в виду, что эти IMS умеют передавать и векторные данные, а также организуют многопользовательскую работу на однопользовательском по сути продукте.) Можно было бы сделать и ARC/INFO IMS, но держать мощный продукт только для визуализации карт и выполнения простейших к ним запросов — бессмысленно, а создавать посреднические блоки ко всем функциям ARC/INFO — это затевать отдельную дорогостоящую разработку. К тому же, было бы полезно передавать по Интернету не только готовую картинку, но и выборку исходных данных, как это делает SDE.
С SDE — тоже интересная история. Совершенно очевидно, что в крупных компаниях (да и во многих средних тоже) все информационное обеспечение строится вокруг центральной базы данных, из которой сотрудники всех подразделений могут брать информацию для выполнения своих задач и куда отправлять результаты своей работы, чтобы их коллеги также могли ими воспользоваться. Повсеместное распространение коммерческих многопользовательских реляционных СУБД типа Oracle, Informix и т.д. стало признанием идее корпоративного хранилища данных, а внедрение Интернеттехнологий в локальные сети компаний (под шифром «Интранет») позволило обеспечить простой интерфейс к этим БД, так что пользоваться ими стало так же просто, как бродить по просторам Всемирной паутины. А как же географические данные? Их сложная структура и большие объемы приводили к неэффективности реализаций традиционными путями, что долго было камнем преткновения в попытках разместить пространственные данные в стандартных СУБД. Но вскоре пришло решение — СУБД начали хорошо работать с большими двоичными объектами (BLOB), а к ним самим стало возможно создавать серверные расширения. Таким расширением и стал сервер пространственных данных SDE. Естественно, что к каждой СУБД нужно создавать свое расширение — свой вариант SDE, но зато на выходе мы получаем стандартный, не зависящий от базовой СУБД, интерфейс для работы с пространственными данными. Причем ESRI не стал ограничиваться данными ГИС, но и предусмотрел возможность хранения под SDE другого большого класса пространственных данных — данных систем автоматизированного проектирования (САПР). Этот факт важно отметить потому, что пакеты САПР (AutoCAD, MicroStation) какое-то время использовались в качестве основы для построения ГИС, и такие данные до сих пор используются, другой момент — приложения управления инфраструктурой, в которых данные исходно создаются в САПР при проектировании, и остаются в таком виде при эксплуатации (именно для этих ситуаций в свое время создавался ArcCAD).
Для управления сетевой инфраструктурой ESRI (совместно с Miner&Miner) выпустил отдельный продукт ArcFM, созданный на AML в среде ARC/INFO. В этом продукте были реализованы идеи, многие из которых перешли в модель данных Базы геоданных (БГД). Здесь мне хочется упомянуть две из них — межслойную топологию и правила. Допустим, вы моделируете водопроводную сеть. Очевидно, что при перемещении вентиля (при редактировании сети) он не должен отрываться от труб. Есть множество причин, по которым трубы и вентили размещают в разных покрытиях (да и связанных покрытий практически всегда — больше двух), но в результате разрывается топологическая связь между ними, и приходится писать специальный программный код, чтобы такие связи поддерживались автоматически. Та же проблема — в связывании железнодорожных путей и станций, остановочных пунктов и дорог, мостов, дорог и рек и т.д. Вторая идея — правила — состоит в том, чтобы смоделировать в ГИС существующие в реальной жизни ограничения. Совершенно очевидно, что нельзя напрямую соединить трубу и вентиль с разными резьбами. Программа должна дать пользователю соответствующее сообщение или же автоматически вставить переходник. Моделируются такие ситуации с помощью системы правил, где для каждого используемого элемента указывается, с какими и в каком числе он может соединяться. В ГИС никогда не было встроенного механизма для реализации правил, но всё большему числу пользователей он оказывался нужен. Можно, конечно было бы реализовать эти идеи в ядре ARC/INFO, но тогда пришлось бы менять формат покрытия, писать соответствующий код для ArcView GIS и MapObjects, то есть выполнять тройную работу, поскольку продукты запускались в разные годы и основаны на разных программных архитектурах. И так — с каждым нововведением.
Что же получается? Когда-то мы говорили ESRI — подразумевали ARC/INFO, говорили ARC/INFO — подразумевали ESRI. А теперь из однопартийной (простите, однопрограммной) компании получился целый Вавилон продуктов, каждый из которых по-своему хорош, но все вместе они как-то не очень дружат (хотя и живут не совсем врозь). Хорошо бы добавить поддержку шейпфайлов в ARC/INFO, а ArcView — научить понимать библиотеки символов ARC/INFO. Хорошо бы добавить топологию в SDE, да и сделать топологические связи между покрытиями было бы неплохо… В общем, получилось то, что обычно получается в результате экстенсивного развития — кризис роста: старые концепции программирования не позволяют эффективно развивать продукт. Единственный выход — привести все продукты к одному знаменателю — общей программной архитектуре и единой среде разработки.
Оптимальной технологией оказалась модель объектовкомпонент, из которых, как из стандартизованных кирпичиков, можно складывать различные продукты. Четкое разделение функций программных компонент и формализация их взаимодействий позволяют развивать каждую без скрытого (и всегда негативного) влияния на другие компоненты, а использование в разных продуктах общих компонент устраняет необходимость дублировать работы. Кроме того, фирмаразработчик может просто предоставить эти компоненты в распоряжение самого пользователя — вот вам готовое средство разработки прикладных систем. ESRI так и поступил, дав доступ к программным компонентам ArcObjects, из которых состоят продукты нового поколения. Кстати, теперь уже говорить об этих продуктах как об отдельных сущностях не совсем корректно, ведь и ArcView 8 и ArcInfo 8 имеют много общих компонент. Этим и объясняется появление нового термина ArcGIS, обозначающего общую основу всех новых продуктов ESRI. Теперь общность продуктов выражается не только в возможности обмена данными в общих форматах, но и в использовании общей основы их построения — программных компонент семейства ArcGIS.
Разработка новой архитектуры продолжается, но уже сейчас мы можем наблюдать многие интересные последствия. Во-первых, произошло четкое разделение продуктов ESRI на две ветви — серверную (ArcSDE и ArcIMS) и пользовательскую (ArcGIS Desktop, она же клиентская). Теперь очень просто решить, из чего собирать свою ГИС: если вы монопольно используете данные на локальном или сетевом диске, то можно ограничиться приложением ArcGIS Desktop; если вы хотите иметь многопользовательский доступ к базе геоданных по сети, то вам нужен ArcSDE; если хотите получать доступ к данным через Интернет или создавать картографические Интернетприложения, то вам нужен ArcIMS.
Во-вторых, компонентная структура ArcGIS позволяет относительно легко формировать приложения с любой функциональностью. Наряду с привычными ArcInfo и ArcView появился новый продукт ArcEditor и скоро выйдет еще один — ArcReader. ArcEditor занимает промежуточное положение между ArcInfo и ArcView, имея все возможности формирования структуры и редактирования данных ArcInfo (прежде всего, баз геоданных), но не обладая аналитической мощью последней. По сути, ArcEditor — наследник Data Automation Kit (DAK), использовавшегося только для полноценного ввода, редактирования и построения топологии покрытий ARC/INFO, цена которого составляла лишь часть цены ARC/INFO.
ArcReader должен стать неким аналогом известного продукта Acrobat Reader, позволяющим просматривать готовые карты, записанные в специальном упакованном формате базы геоданных (некий аналог PDF). По сути, ArcReader будет вариантом ArcMap, в который не будут включены функции редактирования.
На вебсерверах можно хранить не только наборы данных, на и программные модули, выполняющие определенные функции, причем данные и программы могут храниться не просто на разных компьютерах, а в разных точках планеты. Одна компания может выставлять в Интернете данные, например, уличную сеть города, а другая, пусть даже в другой стране, — модуль маршрутизации. Приложение же пользователя может обратиться к модулю маршрутизации, указав сервер с данными, чтобы узнать оптимальный маршрут между двумя точками города. Таким образом мы приходим к концепции распределенных вычислений в среде Интернет.
Сегодня уже есть примеры распределения обработки научных данных по миллионам компьютеров, подключенных к Интернет. Для геоинформатики первыми шагами в область распределенной обработки данных является создание объектной технологии ArcGIS и серверных продуктов ArcSDE и ArcIMS, а также запуск Geography Network (Географической сети) — инициативы ESRI по глобальному обмену геоданными. Сегодня многие ведущие мировые поставщики пространственной информации уже присоединились к Geography Network, представляя в ней свою продукцию.
Важнейшей составляющей доступа к геоданным через Интернет является их стандартное описание, реализуемое в виде метаданных. Метаданные указывают, к какой теме относится набор геоданных, какую территорию покрывает, какую он имеет детализацию, когда составлен, в какой системе координат представлен и т.д. Метаданные являются единственной стандартной основой для поиска геоданных в Интернет. Но они полезны не только для представления геоданных в Интернет, но и для работы с геоданными внутри организации, — это удобный механизм информирования пользователей о пространственноинформационных ресурсах организации и основа для поиска ими нужных данных.
Возникновение ArcGIS не означает моментальный отказ от всего того, что развивалось ESRI и его пользователями многие годы. В состав ArcInfo 8 входит ArcInfo Workstation — старый добрый вариант ARC/INFO, соответственно, продолжается поддержка AML-приложений пользователей, и вы можете продолжать работать в знакомой вам среде, постепенно осваивая новые возможности . Кстати, можно заметить, что несколько изменилось написание названия системы: если раньше это был гибрид из графической подсистемы ARC и атрибутивной СУБД INFO (с гибридной моделью данных, прошу прощения за каламбур), то теперь используется интегрированная модель данных БГД, соответственно слово пишется слитно. Прежнее название писалось большими буквами, как это было принято в языке ФОРТРАН, с которого система начиналась 30 лет назад, новое — соответствует стилю современных языков объектноориентированного программирования.
ESRI продолжает поддержку ArcView GIS 3.2 — вы можете и дальше использовать свои наработки на Avenue, хотя новые уже имеет смысл делать средствами Visual Basic for Applications (VBA). VBA — стандартная среда в Windows для расширения и настройки приложений. Небольшие начальные усилия по освоению этой среды окупаются универсальностью ее использования. Написание макросов для ArcView 8, по сути, ничем не отличается от написания макросов для Microsoft Word. Синтаксис, среда, средства отладки — те же, различие — лишь в использовании одних объектов вместо других.
На последней конференции в Сан-Диего президент ESRI пообещал, что командная строка возвратится и будет поддерживаться в ArcInfo и дальше. Успешно прошли испытания ArcObjects 8.0, портированных в среду Sun Solaris. Новые приложения ArcGIS 8.1 будут поддерживаться на UNIX-платформах с помощью Mainwin — системы эмуляции объектнокомпонентной модели COM в среде UNIX. Уже в этом году ожидается версия ArcView 8 для Windows 98, а также реализация ArcGIS для Windows XP. Серверные продукты ArcSDE и ArcIMS в этом году будут поддерживаться на платформах HP-UX, SGI IRIX и Linux (Intel 32), в следующем — ожидается поддержка 64-битных версий СУБД на HP-UX, SGI IRIX и Linux (Intel 32), в следующем — ожидается поддержка 64-битных версий СУБД на HP/SGI/Sun 64 bit.
