DBA.UCOZ.RU

Часто приходится читать и слышать разного рода высказывания, сводящиеся к единой мысли: «ESRI – это неплохо, но дорого и закрыто, а вот Oracle и его возможности по хранению и обработке данных – это замечательно во всех отношениях». Про хранение геометрии в MS SQL пока говорят мало, поскольку эта возможность появилась сравнительно недавно, только начиная с MS SQL 2008, но в будущем и про этот способ хранения данных будут, как мне кажется, говорить то же самое. Попробуем разобраться, что имеем на самом деле.

Если говорить кратко, то главные мысли можно сформулировать в следующих тезисах:

• ArcGIS позволяет использовать для хранения пространственных данных пространственные типы хранения самих СУБД, хорошо документированные производителями СУБД. Хранение данных в бинарном виде также документировано и имеет возможность доступа не через ArcGIS.
• Интеграция системы хранения на основе ПО ArcGIS с имеющимися информационными ресурсами предприятия возможна. Сложность интеграции зависят от необходимости совместного редактирования данных из ArcGIS и других систем, необходимости использования для этих данных объектной модели базы геоданных с присущей ей топологией, сетевыми наборами данных, правилами взаимосвязей и т.п. То есть чем меньше пересечений по совместному редактированию, чем меньше различного рода взаимосвязей в модели данных (?), тем проще.
• Не всегда решения от ESRI очень дороги, но они всегда открывают большой простор по внедрению в существующую структуру информационной системы предприятия или построению этой системы с использованием ПО от ESRI.

Если вас интересуют обоснования изложенных высказываний, то имеет смысл перейти к детальному техническому описанию.

В настоящее время все ведущие поставщики СУБД предусмотрели возможность хранения пространственной информации в этих СУБД. За ArcSDE приходится доплачивать довольно внушительную сумму. Специалисты по программам ESRI, конечно, скажут, что за эти деньги вы получите большие дополнительные возможности, но вы думаете про эти дополнительные деньги. На самом деле, затраты на ПО не всегда являются определяющим фактором. Очень часто СУБД уже давно развернута на предприятии, пространственные данные загружены в СУБД, и уходить на другую платформу никто не собирается. Довольно часто встречается ситуация, когда в системе уже работают другие ГИС и САПР системы, но по каким-то причинам есть желание добавить еще и решения от ESRI. Рассмотрим эти ситуации.

Ситуация первая.

СУБД уже есть, в системе присутствуют различные ГИС и САПР, пространственные данные хранятся в СУБД, от ПО ESRI требуется интегрироваться в существующую структуру.

Технология ArcSDE позволяет использовать данные, уже загруженные в СУБД и хранящиеся в ее родных пространственных типах (здесь и далее, говоря про хранение пространственных типов в общем, будем иметь ввиду пространственные типы в Oracle, MS SQL, Informix, DB2, то есть в СУБД, поддерживаемых ArcSDE). Не скажу, что всё проходит без проблем, но проблемы эти общие у всех ГИС. Проблемы, прежде всего, состоят в некорректности элементарной геометрии, в основном, для полигональных объектов. У ArcGIS (на самом деле, не только у ArcGIS) есть хорошее правило «внутренность - слева», это правило определяет направление обхода границы полигона – против часовой стрелки. Если полигон обходится по часовой стрелке, то это «дырка» в большем полигоне. Как следствие, появляется еще одно правило: граница полигона не должна пересекать сама себя. Последнее стоит пояснить. Если вы рисуете «8» не отрывая руки, то получившийся полигон имеет самопересечение границы, если рисуете «8» как две касающиеся, зеркально отраженные «З», то никакого самопересечения не будет. Встречая первый некорректный объект, ArcGIS отказывается отображать некорректный объект и может отказаться отрисовывать все последующие объекты. Другие ГИС имеют схожие проблемы. Самое непонятное состоит в том, как эти объекты появляются в СУБД, но они там могут быть. Это обстоятельство сильно мешает жизни.

Предположим, что пространственные данные в СУБД корректны, и все ГИС могут их нормально использовать. Действительно, совместное использование простых геометрических форм возможно, но оно часто сводит на нет многие преимущества ArcGIS, а именно, большинство преимуществ базы геоданных: объектные сущности геометрических форм – топологические правила, правила описания сети, а также репликацию и синхронизацию данных средствами ArcGIS. (Отстаивая возможность синхронизации средствами ArcGIS, автор отстаивает возможности более гибкой и удобной синхронизации данных, в частности, синхронизации конкретно взятых версий данных или синхронизации посредством переноса данных на флэш-носителях, ArcGIS позволяет это делать.) Среди «приятностей от ArcGIS» остаются только домены (ограничения на атрибуты) и подтипы (подмножества внутри большого набора данных). Причина состоит в том, что для того, чтобы не потерять указанные преимущества, необходимо не только зарегистрировать данные в служебных таблицах ArcSDE (что делается довольно просто), но и редактировать их из ArcGIS т.н. «версионным» способом. При этом клиентское приложение ArcGIS вносит изменения не в основные таблицы набора пространственных данных, а в специально создаваемые дополнительные таблицы, про которые «знает» только ArcGIS и приложения, созданные на основе ArcGIS SDK. Конечно, довольно легко предоставить возможность другим системам видеть в реальном времени результаты «версионного» редактирования ArcGIS, но ведь про эту задачу нужно еще вспомнить и знать, что она решается!

К сожалению, невозможно предоставить возможность «версионного» редактирования сложных (объектных) данных из ArcGIS и простого редактирования тех же данных из других систем, поскольку ArcGIS будет писать изменения в дополнительные таблицы, а другие системы – в основные таблицы. К счастью, в принципе, это делать можно, но, как уже было сказано, при этом мы теряем многие преимущества БГД. И все же, как это сделать? ArcGIS позволяет редактировать данные и «неверсионно», при этом изменения вносятся сразу в основные таблицы наборов пространственных данных. Естественно, при таком ведении дел снимаются все вопросы по интеграции.

Про форматы хранения пока умолчим, дабы не перегружать этот раздел. Пока сделаю только два утверждения: интеграция возможна и ESRI не настолько закрыта, как вы думаете.

Выводы по первой ситуации:

Интеграция возможна

Возможна правильная интеграция, когда каждая система отвечает и вносит изменения только в свои данные и имеет все свои преимущества, но все системы видят результаты работы любой системы

Возможна интеграция с некоторым ущербом, если требуется изменение одних и тех же данных из различных систем.

Ситуация вторая.

СУБД уже есть, ГИС нет, есть мысль использовать в качестве настольного ПО ArcGIS, данные хранить в СУБД и неплохо бы сделать так, чтобы и другие, пока гипотетические системы смогли использовать эти данные. В данном случае все вроде бы просто, но возникает вопрос об открытости формата хранения данных с использованием ArcSDE. В данном случае придется рассмотреть каждый способ хранения пространственных данных и каждую СУБД в отдельности.

Вариант 1. Oracle. Самая многообразная по форматам хранения данных СУБД:

Формат хранения Oracle Spatial (SDO_Geometry). Для использования этого формата хранения необходимо использовать либо довольно дорогой модуль Oracle Spatial для довольного дорогого Oracle Enterprise, либо бесплатный модуль Oracle Locator для не очень дорогого Oracle Standard Edition (Enterprise также можно использовать с Oracle Locator). Отличие этих конфигураций состоит в том, что Oracle Locator не позволяет выполнять многие задачи обработки и анализа пространственных данных на сервере. Хранить данные можно и в той, и в другой конфигурации. Через ArcSDE клиенты ArcGIS имеют полнофункциональный доступ к данным, хранящимся в формате Oracle Spatial. Начиная с версии 9.4, ArcGIS имеет доступ к простым объектам, хранящимся в Oracle Spatial и без ArcSDE (но только к простым, без различных объектных свойств). Несмотря на то, что формат Oracle Spatial понимается многими поставщиками ГИС, но это не вполне стандартный формат, то есть он стандартный, но для Oracle. В мире существует организация OGC (Open Geospatial Consortium, www.opengeospatial.org), которая, в том числе, занимается стандартизацией форматов данных. Формат Oracle Spatial не полностью отвечает стандарту OGC.

Формат хранения ESRI Spatial for Oracle (ST_Geometry). Для обеспечения той же функциональности, что и Oracle Spatial, ESRI разработал и внедрил в Oracle свой собственный формат для работы с пространственными данными через SQL. Зачем, если уже есть Oracle Spatial, который позволяет делать то же самое? Чтобы обработка данных происходила быстрее, чтобы этот формат полностью отвечал стандарту OGC. Обе задачи были выполнены. Вот только формат ESRI Spatial for Oracle пока не так широко поддерживается, несмотря на свою скорость и стандартность. Через ArcSDE клиенты ArcGIS имеют полнофункциональный доступ к данным, хранящимся в формате ESRI Spatial for Oracle. Начиная с версии 9.3, этот формат хранения является форматом хранения по умолчанию для новых инсталляций ArcSDE. В недавно вышедшей версии Oracle появился формат ST_Geometry уже от Oracle, пока нет полной информации об этом формате.

Двоичный формат хранения (BLOB). Как раз именно вокруг этого формата хранения появилось много мифов. Один из них – полная закрытость этого формата. На самом деле, все просто, пары координат хранятся в виде байтов. Первая пара координат хранится в явном виде, дальше идут приращения по Х и У, есть стартовый бит в каждом байте присутствует либо стоповый бит , либо бит, сигнализирующий о продолжении числа в следующем байте. А если не хочется разбираться в этих битах, то есть C API и JAVA API для ArcSDE, либо ArcObject (ArcGIS SDK). По производительности этот формат совпадает с ESRI Spatial for Oracle. Ранее основным форматом хранения был LONGRAW (сейчас он не поддерживается), который является разновидностью двоичного формата хранения, но он имел некоторые проблемы по поддержке со стороны СУБД.

Двоичный формат хранения, стандартизованный по OGC. Это некая вещь в себе. Да, отвечает стандарту, но на этом все преимущества заканчиваются. Производительность этого формата далека от максимума, никаких пространственных SQL-запросов. Так что, не очень понятно, в каких случаях он полезен.

Вариант 2. Microsoft SQL Server 2008.

Пространственные форматы хранения (Geometry и Geography). Оба формата очень похожи и отличаются плоским и сферическим представлением мира при выполнении операций обработки данных. Форматы полностью отвечают стандарту OGC. В основе разработки этих стандартов лежали технологии ESRI. Форматы позволяют производить обработку и анализ пространственных данных через TSQL. Через ArcSDE клиенты ArcGIS имеют полнофункциональный доступ к данным, хранящимся в форматах Geometry и Geography.

Двоичный формат хранения (IMAGE). Ситуация полностью повторяет состояние дел с форматом BLOB для Oracle.

Двоичный формат хранения, стандартизованный по OGC. См. тот же пункт для Oracle.

Вариант 3. INFORMIX, DB2.

Пространственные форматы хранения (ST_Geometry). Обе СУБД очень схожи и по администрированию, и по подходу к хранению пространственных данных. Обе требуют установки т.н. «пространственных расширителей», по сути, являющихся кусками кода ArcSDE. Ситуация с этими форматами практически полностью повторяет состояние дел с форматом ESRI Spatial for Oracle, производительность этих СУБД, как обещает ESRI, даже чуть выше Oracle.

Вариант 4. PostgreSQL.

Пространственный формат хранения (ST_Geometry). Ситуация полностью повторяет состояние дел с форматом ESRI Spatial for Oracle. Производительность в этом случае, как обещает ESRI, выше, чем у Oracle.

Пространственный формат хранения (Geometry). Требуется модуль расширения POSTGIS для PostgreSQL. Поддерживается ArcGIS и MapInfo, активно используется как хранилище в бесплатных и дешевых ГИС (Viewport, KOSMO, Quantum GIS и др). Отвечает стандартам OGC. Позволяет производить обработку и анализ пространственных данных через SQL. Но вряд ли он вам понадобится. Хотя повторю, что через ArcSDE клиенты ArcGIS имеют полнофункциональный доступ к данным, хранящимся в формате POSTGIS Geometry.

Выводы по второй ситуации:

Не так уж ESRI и закрыта, как многие думают, просто не всегда формат описан на флаге, которым размахивает производитель системы. Приходится читать справку.

Интеграция с другими системами возможна, если на этапе построения системы и загрузки данных озаботиться этим вопросом. 

Ситуация третья.

Деньги являются определяющим фактором. В этом случае советую обратить свое внимание на связку бесплатной СУБД PostgreSQL с ArcSDE. Получается довольно бюджетное решение. Если денег еще меньше, то, вполне возможно, вас устроит ArcGIS Server Basic Workgroup, который, правда, имеет ограничения и на объем хранимых данных (4 ГБ), и на количество одновременно подключенных клиентов (до 10). ArcSDE Workgroup работает на MS SQL Express. А если хочется сделать распределенную систему обработки данных, но клиентов в мелких офисах совсем мало, то, возможно, подойдет бесплатная ArcSDE Personal, правда у этой версии может быть всего три подключения из которых только один редактор. ArcSDE Personal также работает на MS SQL Express.

В данном случае не будем забывать и о не-ArcSDE-хранении. Это файловая и mdb базы геоданных. Внутрь mdb-базы можно легко зайти через access и вполне законно через его интерфейс просматривать и редактировать данные. С файловой БГД все будет прозрачно начиная с версии 9.4. Именно, начиная с этой версии ESRI будет поставлять открытый API для доступа к данным этой БГД без использования ArcGIS.

Выводы по третье ситуации:

Нет никакого разговора про интеграцию, хотя и в этом случае она возможна, ведь MS SQL Express 2008 также поддерживает Geometry и Geography,  и про возможности PostgreSQL\POSTGIS тоже не надо забывать.

17/11/2009

Стрельцов И.В., гл. консультант ООО «ДАТА+»