Я работаю с Geoserver, обслуживая нижние 48 округов США для открытых слоев (3109 полигонов - намного больше вершин). Округа загружаются в базу данных postgis. Мне любопытно, что разработчик пытается передать это количество вершин клиенту.
С каким форматом WFS вы достигли лучших результатов? Была ли использована дополнительная настройка на Geoserver?
Я понимаю, что плиточный WMS будет быстрее, но я хочу учесть динамические изменения в картограмме с использованием openLayers, т.е. пользователь отправляет форму, вызывается скрипт на Python и новые корзины данных возвращаются для открытых слоев для перезагрузки карты div. Я также хочу попробовать это в полном разрешении, прежде чем уменьшать сложность многоугольников в openlayers.
GEOJSON, на мой взгляд, лучший формат, его легко читать, легко использовать в javascript и, как правило, он меньше по размеру, чем GML / KML. Он может даже содержать информацию о стиле, см. Здесь .
Это не официальный стандарт, но он поддерживается как для листовок, так и для openlayers, а также во многих приложениях gis-desktop, таких как qgis.
источник
Использование GeoJSON - хорошее начало для ускорения вашей системы, но этого может быть недостаточно. Вам следует рассмотреть возможность создания нескольких версий слоя данных, по одной на слой масштабирования, и применять методы обобщения / упрощения к каждой версии. Клиент должен запросить соответствующий слой в зависимости от выбранного уровня масштабирования. Это обеспечит приемлемый уровень детализации данных, которыми обмениваются сервер и клиент, и это значительно повысит как передачу по сети, так и рендеринг. Чтобы пойти дальше, вы могли бы расширить свою систему с помощью векторных листов и пространственной индексации, как описано в этом документе , но я не уверен, что openlayers и геосервер могут справиться с этим ... пока!
Наверняка: забудьте о GML.
источник
Почему бы не использовать скрипт Python для создания нового файла SLD и отправить его на сервер WMS с вашим запросом.
Существует пример здесь .
источник
Я уже дважды шел по той же дороге, и рендеринг на стороне клиента для чего-то большего, чем небольшое количество точек или действительно простых полигонов, просто не очень хорошая идея. После того, как вы привязали себя к этой архитектуре, стоит отказаться, и в любом проекте вы, вероятно, увидите либо изменение требований, либо увеличение объема данных, поскольку различные заинтересованные стороны / супервизоры начинают видеть, на что способна ваша система. Подход на основе браузера на стороне клиента не масштабируется.
Если вы хотите динамический рендеринг, я использую второй подход @ iant. Ранее я описал несколько вариантов для другой, но связанной проблемы здесь . Я также использовал обобщение полигонов, чтобы помочь в рендеринге на стороне клиента, и, хотя он определенно помогает, он порождает более сложные проблемы, например, если вы хотите сбросить не обобщенный полигон по мере увеличения вашего пользователя.
Даже если вы работаете с известной платформой - например, вы знаете аппаратное обеспечение, версию браузера и плагины всех клиентов - что маловероятно, вы не представляете, под какой нагрузкой находятся эти клиенты. Такой подход требует, чтобы браузер мог получить МНОГО времени ЦП, чтобы поддерживать удобство работы с пользователем, а все остальное будет раздражать ваших пользователей.
источник