Как получить информацию по features из сервера в интранет?

[Barvetal]

Здравствуйте!

Есть интранет масштаба страны. В нем находится сервер от ESRI. Геоданные вроде как находятся в Oracle (используются возможности Oracle DB сервера для хранения геоданных). Задача: получать на локальных машинах информацию о features (геометрии) нужного слоя, попадающих в нужную пользователю прямоугольную область.

Есть возможность выбирать технологии как сервера, так и на локальных машинах.

Скажите, пожалуйста, как это лучше всего сделать?

P.S. Я нашел в интернете технологию WFS (Web Feature Service). Эта технология позволяет получать через http запрос данные xml в специальном геоформате (Geographical Markup Language - GML).

Не очень мне нравится идея работать с xml в данном случае. Насколько я знаю, у ESRI есть API-библиотеки для работы с ГИС.

Кроме того, подозреваю, что эти данные можно напрямую получать из базы данных Oracle. Может, это и есть самый быстрый вариант решения?

Так все же, что лучше использовать? Какие-нибудь библиотеки? Или брать данные из БД напрямую? Или все же WFS лучше? Или есть еще более красивое решение?

[mamont80]

Задача тривиальная, но не совсем понятно о чем идет речь. О толстом или тонком клиенте, о существующем или проектируемом сервисе. Что на клиенте: OpenLayers или какие-то ESRI решения. Вообще я не специалист по ESRI продуктам, по данным вопросам лучше лезть в соответсвующие форумы или сайты.
Раз уж никто ничего пока не сказал вставлю свои 3 копейки.
Думаю всё можно сделать на OpenLayers. Смотреть карту можно по WMS, а запрос по ректу можно делать через WFS. С WFS я лично не работал, но думаю там можно сделать нужное. Просто отображать большое количество данных оптимальней растром, вместо запроса и разбора WFS XML-а. Сервер ESRI должен поддерживать и то и другое.
Напрямую из Оракла брать тоже нормальный вариант. Но Оракл не самое быстрое хранилище для гео данных.

[Barvetal]

Задача тривиальная, но не совсем понятно о чем идет речь. О толстом или тонком клиенте, о существующем или проектируемом сервисе. Что на клиенте: OpenLayers или какие-то ESRI решения. Вообще я не специалист по ESRI продуктам, по данным вопросам лучше лезть в соответсвующие форумы или сайты.

Клиент толстый. Сервис только проектируется (ГИС-сервер на ESRI уже есть и работает для других проектов, клиентов по моему проекту еще никаких нет). У компании есть лицензии на ESRI и масштаб компании такой, что стоимость лицензий ESRI не имеет существенного значения. Если надо будет, можно будет купить все. В то же время за мной остается возможность выбора технологий (ESRI или OpenLayers, например).

Что касается вопроса по в соответствующие форумы... Возможно, мне действительно нужно было этот вопрос задать в форум по ESRI...

Думаю всё можно сделать на OpenLayers. Смотреть карту можно по WMS, а запрос по ректу можно делать через WFS. С WFS я лично не работал, но думаю там можно сделать нужное. Просто отображать большое количество данных оптимальней растром, вместо запроса и разбора WFS XML-а. Сервер ESRI должен поддерживать и то и другое.
Напрямую из Оракла брать тоже нормальный вариант. Но Оракл не самое быстрое хранилище для гео данных.

Дело в том, что мне данные нужно обрабатывать. Поэтому, конечно, WMS я планирую использовать для визуализации. Но еще нужна довольно сложная обработка координат узлов геометрии в программном коде клиента.
Естественно, для этого можно использовать WFS. При этом есть следующие накладные расходы: ESRI на сервере читает данные о геометрии фич из базы данных, обрабатывает их для того, чтобы сформировать xml, затем по сети передается xml (что больше по объему, чем бинарные данные), затем клиент принимает xml, и парсит его для получения данных.
Как мне кажется, если работать с базой данных напрямую, то не нужны накладные расходы на создание xml и дальнейший его парсинг на клиенте. Кроме того, объем данных для передачи по сети будет меньше.
Вот и вопрос: есть ли смысл для получения данных использовать WFS? Может, из Оракла все же оптимальней будет? Или как все-таки быстрей? Возможно, есть API какое-то от ESRI, которое обращается не к Ораклу, а напрямую к ESRI?

Напрямую из Оракла брать тоже нормальный вариант. Но Оракл не самое быстрое хранилище для гео данных.

А какое самое быстрое хранилище? Дело в том, что так работает существующий сервер: у него данные хранятся в Оракл...

[mamont80]

Клиент толстый. Сервис только проектируется (ГИС-сервер на ESRI уже есть и работает для других проектов, клиентов по моему проекту еще никаких нет). У компании есть лицензии на ESRI и масштаб компании такой, что стоимость лицензий ESRI не имеет существенного значения. Если надо будет, можно будет купить все. В то же время за мной остается возможность выбора технологий (ESRI или OpenLayers, например).

Что-то мы помоему путаем понятия. Так клиент толстый или тонкий? Толстый клиент - это гурбо свой EXE файл в котором делай как хошь, тонкий - когда всё по WEB работает из браузера. OpenLayers - это JS библиотека для браузеров - тогда клиент тонкий.

Вот и вопрос: есть ли смысл для получения данных использовать WFS? Может, из Оракла все же оптимальней будет? Или как все-таки быстрей? Возможно, есть API какое-то от ESRI, которое обращается не к Ораклу, а напрямую к ESRI?

На прямую конечно быстрее будет. XML - тормоз. У WFS плюсом является то, что это стандарт и много чего его понимает, и много чего уже написано. Взять тот же OpenLayers. Если всё это не критично, программисты имеются, стороннего софта не ожидается, скорость критична, то лучше конечено самому писать на прямую. Как вариант отдельный web сервис сделать который будет отрабатывать хитрые запросы, ну тут много вариантов может быть - ограничено только вашей фантазией и квалификацией.

А какое самое быстрое хранилище? Дело в том, что так работает существующий сервер: у него данные хранятся в Оракл...

Думаю "самого быстрого" не бывает. Всё зависит от разных вещей, одно из них - частота обновлений и требования по надежности. Как вариант - просто shape файлы. А вообще если смотреть именно по СУБД и на ESRI я бы потестил и сравнил. С точки зрения производительности по моему опыту быстрее оракла ВСЁ. Точнее ничего медленее Оракла я не видел. Дело тут в том как Оракл работает с БЛОБами и структурами.

Если вы пишите select blob_field from table1 вы получаете на клиенте только ссылки на эти блобы, но не сами данные. И при обходе блобов клиент делает отдельные запросы по каждому блобу каждой записи, что ни есть хорошо. С геометриями лежащими в оракле не в блобах, а в SDO формате (не помню точно как это называется, спец. известный формат OGC консорциума для хранения геометрий), то там дело обстоит ещё хуже. ESRI сами советуют для скорости использовать в оракле БОЛБы, вместо него. Я просто сам разработчик ГИС и вопросы быстродействия оракла детально ковырял. Если SDO формат общеизвесный, то формат хранения в БЛОБах думаю закрыт или фиг найдешь. Так что напрямую работать с ним думаю будет либо тяжело, либо не возможно (всмысле добраться до координат конкретных точек). Наверняка у ESRI есть какой-то API для самостоятельной работы с геометриями в БД, но я здесь не подсказчик что и как.
Либо выбрать некую СУБД с известным бинарным форматом хранения геометрий. POSTGIS, MySQL, у MS SQL Server что-то подобное есть, но я сам пока не интересовался. В MySQL тоже есть проблемы: для правильного хранения БД с геометриями надо использовать myisam хранилище, которое не очень-то надежно.

Ещё раз скажу что я не специалист по ArcServer, немного посмотрел и забыл. Незнаю какие ещё СУБД там поддерживаются.
Просто у большинства людей есть стереотип: лучшая ГИС - ESRI, лучшая СУБД - Oracle. Стереотипы менять сложно, да и мне это параллельно.
Думаю у вас вопрос выбора ПО сделан и ковырять будете что есть.

[Barvetal]

Что-то мы помоему путаем понятия. Так клиент толстый или тонкий? Толстый клиент - это гурбо свой EXE файл в котором делай как хошь, тонкий - когда всё по WEB работает из браузера. OpenLayers - это JS библиотека для браузеров - тогда клиент тонкий.

Клиент толстый. Мы пишем большую корпоративную клиент-серверную систему, которая будет использовать данные от ГИС. То-бишь, данные по геометрии будет запрашивать наш Application Server.


Также спасибо за все остальное по Вашему ответу!
Честно говоря, удивляюсь, что Оракл медленный получается... А я надеялся...
У ESRI я нашел такую штуку, как ESRI SDE SDK. Есть надежда, что этот SDK умеет работать с нижележащей Оракловой базой быстро (например, промежуточный слой кеширования...) Нужно будет посмотреть...

[Mavka]

Давайте разделим вопросы хранения и транспортировки.

Допустим, данные хранятся в Oracle SDO или PostGIS. Тогда процесс извлечения данных будет обычным подключением к БД и передаче sql-запросов. Клиент должен уметь общать с конкретной БД, т.е. в дальнейшем будет привязан.

Есть продукты, которые позволяют работать с различными источниками данных (не только БД, но и файлы, интернет сервисы) по единообразному протоколу - например, WFS и протокол-ArcSDE (не знаю его названия). Специализированные протоколы лучше подходят для передачи данных по "медленным" и ненадежным сетям.

С точки зрения системного администратора их легче контролировать и они более безопасные. Протокол WFS это по сути html-запросы, а формат xml можно строго проверить на корректность. Для WFS обычно (в зависимости от сервера) можно настроить упрощенную ролевую систему доступа.

Проблема "жирного xml" есть и, к сожалению, озарений в этой области не видится.