GML, KML, GeoJSON - Velocità di rendering 3109 poligoni?

Sto lavorando con Geoserver, servendo 48 contee inferiori degli Stati Uniti agli openlayer (3109 poligoni - molti più vertici). Le contee vengono caricate in un database Postgis. Sono curioso dell'esperienza degli sviluppatori quando provo a inviare quella quantità di vertici al client.

Con quale formato WFS hai ottenuto i migliori risultati? È stata utilizzata un'ulteriore ottimizzazione su Geoserver?

Mi rendo conto che WMS piastrellato sarebbe più veloce, ma voglio consentire cambiamenti dinamici in una mappa coropletica usando openLayers, vale a dire. l'utente invia un modulo, viene chiamato uno script Python e vengono restituiti nuovi bin dati per gli openlayer per ricaricare il div della mappa. Voglio anche provare questo in piena risoluzione prima di ridurre la complessità dei poligoni negli openlayer.

Forse questo innesca alcune nuove idee: ho un'applicazione in esecuzione in cui gli utenti possono modificare una mappa con molti elementi.

Invece di inviare tutti i dati come WFS, utilizzo le mappe WMS e quando l'utente fa clic o disegna una selezione, prendo gli elementi selezionati come WFS .

Dopo aver inviato un aggiornamento al server, aggiorno il livello WMS.

Ci sono alcuni esempi di OpenLayer che dimostrano come farlo. Probabilmente dovrai modificarlo un po ', ma OpenLayers + GeoServer risolverà la parte difficile per te. I dati vengono inviati gzip, quindi il formato originale non è nemmeno così importante; non è il collo di bottiglia. Consenti a OpenLayers e GeoServer di capire quale formato utilizzano per scambiare informazioni.

Questo approccio si adatta abbastanza bene. Anche le persone con connessioni lente e computer lenti possono usarlo per modificare la mappa. Recuperare centinaia di elementi è molto veloce e probabilmente non avrai bisogno di più di questo allo stesso tempo per modificarlo.

_{Infine .. off-topic, ma mentre intendi fare cose sul lato client con i dati delle mappe: tieni presente che IE7 e inferiori saranno problematici se vuoi disegnare poligoni con OpenLayers. OpenLayers utilizza SVG per il disegno sul lato client e IE7 e versioni precedenti non hanno il supporto integrato. A quegli utenti verrà richiesto di scaricare un vecchio plugin scadente. Tutti gli altri browser vanno bene.}

A mio avviso, GEOJSON è il formato migliore, è facile da leggere, facile da usare in javascript e generalmente di dimensioni inferiori rispetto a GML / KML. Può anche contenere informazioni sullo stile, vedi qui .

Non è uno standard ufficiale, ma è supportato sia su opuscoli che su openlayer e su molte app desktop gis come qgis.

L'uso di GeoJSON è un buon inizio per accelerare il sistema, ma potrebbe non essere sufficiente. Dovresti prendere in considerazione la creazione di diverse versioni del tuo livello dati, una per livello di zoom e applicare metodi di generalizzazione / semplificazione a ciascuna versione. Il cliente dovrebbe richiedere il livello pertinente in base al livello di zoom selezionato. Ciò garantirebbe che il livello di dettaglio dei dati scambiati tra il server e il client sia adeguato e aumenterebbe in modo più significativo sia il trasferimento di rete che il rendering. Per andare oltre, potresti estendere il tuo sistema con la piastrellatura vettoriale e l'indicizzazione spaziale come descritto in questo documento , ma non sono sicuro che openlayer e geoserver possano gestirlo ... ancora!

Di sicuro: dimentica GML.

Perché non usare lo script Python per creare un nuovo file SLD e inviarlo al server WMS con la tua richiesta.

C'è un esempio qui .

Ho già percorso due volte una strada simile e il rendering sul lato client per qualcosa di più di un piccolo numero di punti o poligoni davvero semplici non è una buona idea. Una volta che ti sei legato a quell'architettura è costoso tornare indietro e in qualsiasi progetto probabilmente vedrai un cambiamento nei requisiti o un aumento del volume di dati mentre vari stakeholder / supervisori iniziano a vedere di cosa sono capaci i tuoi sistemi. L'approccio di rendering lato client basato su browser non viene ridimensionato.

Se si desidera il rendering dinamico, l'approccio di second @ iant. In precedenza ho descritto una serie di opzioni per un problema diverso ma correlato qui . Ho anche usato la generalizzazione dei poligoni per facilitare il rendering sul lato client e, anche se sicuramente aiuta, genera problemi più difficili, come se si desidera ridurre il poligono non generalizzato man mano che l'utente ingrandisce ulteriormente.

Anche se stai lavorando con una piattaforma nota, ad esempio conosci l'hardware, la versione del browser e i plug-in di tutti i client, il che è improbabile, non hai idea di quale tipo di carico si trovino. Questo tipo di approccio richiede che il browser possa ottenere MOLTO tempo CPU per mantenere fluida l'esperienza dell'utente e qualsiasi altra cosa infastidirà i tuoi utenti.