GML, KML, GeoJSON - Скорость рендеринга 3109 полигонов?

Я работаю с Geoserver, обслуживая нижние 48 округов США для открытых слоев (3109 полигонов - намного больше вершин). Округа загружаются в базу данных postgis. Мне любопытно, что разработчик пытается передать это количество вершин клиенту.

С каким форматом WFS вы достигли лучших результатов? Была ли использована дополнительная настройка на Geoserver?

Я понимаю, что плиточный WMS будет быстрее, но я хочу учесть динамические изменения в картограмме с использованием openLayers, т.е. пользователь отправляет форму, вызывается скрипт на Python и новые корзины данных возвращаются для открытых слоев для перезагрузки карты div. Я также хочу попробовать это в полном разрешении, прежде чем уменьшать сложность многоугольников в openlayers.

Возможно, это вызывает некоторые новые идеи: у меня запущено приложение, в котором пользователи могут редактировать карту со многими элементами.

Вместо отправки всех данных в виде WFS я использую карты WMS, и когда пользователь щелкает или рисует выделенную область, я выбираю выбранные элементы как WFS .

После отправки обновления обратно на сервер я обновляю слой WMS.

Есть несколько примеров OpenLayers, которые демонстрируют, как вы можете это сделать. Возможно, вам придется немного его настроить, но OpenLayers + GeoServer решит сложную часть за вас. Данные отправляются в сжатом виде, поэтому оригинальный формат даже не так важен; это не узкое место. Позвольте OpenLayers и GeoServer выяснить, какой формат они используют для обмена информацией.

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

_{Наконец ... не по теме, но так как вы намерены делать что-то на стороне клиента с данными карты: имейте в виду, что IE7 и ниже будут проблематичными, если вы хотите рисовать полигоны с OpenLayers. OpenLayers использует SVG для рисования на стороне клиента, а IE7 и ниже не имеют встроенной поддержки. Этим пользователям потребуется загрузить старый дерьмовый плагин. Все остальные браузеры в порядке.}

GEOJSON, на мой взгляд, лучший формат, его легко читать, легко использовать в javascript и, как правило, он меньше по размеру, чем GML / KML. Он может даже содержать информацию о стиле, см. Здесь .

Это не официальный стандарт, но он поддерживается как для листовок, так и для openlayers, а также во многих приложениях gis-desktop, таких как qgis.

Использование GeoJSON - хорошее начало для ускорения вашей системы, но этого может быть недостаточно. Вам следует рассмотреть возможность создания нескольких версий слоя данных, по одной на слой масштабирования, и применять методы обобщения / упрощения к каждой версии. Клиент должен запросить соответствующий слой в зависимости от выбранного уровня масштабирования. Это обеспечит приемлемый уровень детализации данных, которыми обмениваются сервер и клиент, и это значительно повысит как передачу по сети, так и рендеринг. Чтобы пойти дальше, вы могли бы расширить свою систему с помощью векторных листов и пространственной индексации, как описано в этом документе , но я не уверен, что openlayers и геосервер могут справиться с этим ... пока!

Наверняка: забудьте о GML.

Почему бы не использовать скрипт Python для создания нового файла SLD и отправить его на сервер WMS с вашим запросом.

Существует пример здесь .

Я уже дважды шел по той же дороге, и рендеринг на стороне клиента для чего-то большего, чем небольшое количество точек или действительно простых полигонов, просто не очень хорошая идея. После того, как вы привязали себя к этой архитектуре, стоит отказаться, и в любом проекте вы, вероятно, увидите либо изменение требований, либо увеличение объема данных, поскольку различные заинтересованные стороны / супервизоры начинают видеть, на что способна ваша система. Подход на основе браузера на стороне клиента не масштабируется.

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

Даже если вы работаете с известной платформой - например, вы знаете аппаратное обеспечение, версию браузера и плагины всех клиентов - что маловероятно, вы не представляете, под какой нагрузкой находятся эти клиенты. Такой подход требует, чтобы браузер мог получить МНОГО времени ЦП, чтобы поддерживать удобство работы с пользователем, а все остальное будет раздражать ваших пользователей.