GML, KML, GeoJSON - Швидкість надання 3109 багатокутників?

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

З яким форматом WFS ви досягли найкращих результатів? Чи була використана додаткова настройка на Geoserver?

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

Можливо, це викликає нові ідеї: у мене працює програма, в якій користувачі можуть редагувати карту з багатьма елементами.

Замість того, щоб надсилати всі дані у вигляді WFS, я використовую WMS-карти, і коли користувач натискає або малює виділення, я отримую вибрані елементи як WFS .

Після відправлення оновлення на сервер я оновлюю рівень WMS.

Є кілька прикладів OpenLayers, які демонструють, як ви можете це зробити. Можливо, вам доведеться трохи підправити це, але OpenLayers + GeoServer розробить складну для вас частину. Дані надсилаються gzipped, тому оригінальний формат навіть не такий важливий; це не вузьке місце. Дозвольте OpenLayers та GeoServer розібратися, який формат вони використовують для обміну інформацією.

Такий підхід масштабує досить добре. Навіть люди з повільним зв’язком і повільними комп'ютерами можуть використовувати його для редагування карти. Збір сотень елементів дуже швидкий, і вам, ймовірно, не потрібно буде одночасно більше, ніж редагувати.

_{Нарешті .. поза темою, але, як ви маєте намір робити інформацію на базі клієнта з картографічними даними: майте на увазі, що IE7 і нижче будуть проблематичними, якщо ви хочете намалювати багатокутники з OpenLayers. OpenLayers використовує SVG для малювання на стороні клієнта, а IE7 та нижчі версії не мають вбудованої підтримки. Цим користувачам потрібно буде завантажити старий плагін. Усі інші браузери чудово.}

На мій погляд, GEOJSON - найкращий формат, його легко читати, простий у використанні у JavaScript та загалом менших розмірів, ніж GML / KML. Він навіть може містити інформацію про стиль, дивіться тут .

Це не офіційний стандарт, але він підтримується як на листівках, так і на відкритих програмах, а також у багатьох додатках gis-desktop, таких як qgis.

Використання GeoJSON - це гарний початок для прискорення роботи вашої системи, але це може бути недостатньо. Вам слід розглянути можливість створення декількох версій рівня даних, по одному на рівень масштабування, та застосувати узагальнення / спрощення методів до кожної версії. Клієнт повинен запитувати відповідний рівень залежно від вибраного рівня збільшення. Це забезпечило б рівень деталізації даних, що обмінюються між сервером та клієнтом, і це значно збільшить як передачу мережі, так і рендерінг. Щоб піти далі, ви можете розширити свою систему за допомогою векторної плитки та просторової індексації, як описано в цьому документі , але я не впевнений, що відкриті шари та геосервер можуть із цим впоратися ... ще!

Напевно: забудьте GML.

Чому б не використовувати сценарій python для створення нового файлу SLD та надіслати його на WMS-сервер із запитом.

Існує приклад тут .

Я вже двічі спускався по схожій дорозі, і візуалізація на стороні клієнта для нічого більшого, ніж невелика кількість точок або дійсно простих багатокутників, просто не є хорошою ідеєю. Після того, як ви прив'язані до цієї архітектури, дорого відмовитися, і в будь-якому проекті ви, швидше за все, побачите або зміну вимог, або збільшення обсягу даних, оскільки різні зацікавлені сторони / контролери починають бачити, на що здатна ваша система. Підхід візуалізації на базі браузера не має масштабу.

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

Навіть якщо ви працюєте з відомою платформою - наприклад, ви знаєте апаратне забезпечення, версію браузера та плагіни всіх клієнтів - що малоймовірно, ви не знаєте, під яким типом завантажуються ці клієнти. Такий підхід вимагає, щоб веб-переглядач міг отримати багато процесорного часу, щоб зберегти користувальницьку роботу, і все інше буде дратувати користувачів.