GML, KML, GeoJSON - Vitesse de rendu de 3109 polygones?

Je travaille avec Geoserver, servant les 48 comtés inférieurs des États-Unis aux couches ouvertes (3109 polygones - beaucoup plus de sommets). Les comtés sont chargés dans une base de données postgis. Je suis curieux de connaître l'expérience des développeurs lorsque j'essaie de pousser cette quantité de sommets vers le client.

Avec quel format WFS avez-vous obtenu les meilleurs résultats? Un réglage supplémentaire de Geoserver a-t-il été utilisé?

Je me rends compte que le WMS en mosaïque serait plus rapide, mais je veux permettre des changements dynamiques dans une carte choroplèth en utilisant openLayers, c'est-à-dire. l'utilisateur soumet un formulaire, un script Python est appelé et de nouveaux bacs de données sont retournés pour que les openlayers rechargent la carte div. Je veux également essayer cela en pleine résolution avant de réduire la complexité des polygones dans les couches ouvertes.

Peut-être que cela déclenche de nouvelles idées: j'ai une application en cours d'exécution où les utilisateurs peuvent modifier une carte avec de nombreux éléments.

Au lieu d'envoyer toutes les données au format WFS, j'utilise des cartes WMS et lorsque l'utilisateur clique ou dessine une sélection, je récupère les éléments sélectionnés au format WFS .

Après avoir renvoyé une mise à jour au serveur, je rafraîchis la couche WMS.

Il existe des exemples d'OpenLayers qui montrent comment vous pouvez le faire. Vous devrez probablement l'ajuster un peu, mais OpenLayers + GeoServer résoudra la partie difficile pour vous. Les données sont envoyées au format gzip, donc le format d'origine n'est même pas si important; ce n'est pas le goulot d'étranglement. Laissez OpenLayers et GeoServer déterminer le format qu'ils utilisent pour échanger des informations.

Cette approche évolue assez bien. Même les personnes ayant des connexions lentes et des ordinateurs lents peuvent l'utiliser pour modifier la carte. La récupération de centaines d'éléments est très rapide, et vous n'aurez probablement pas besoin de plus que cela en même temps pour éditer.

_{Enfin .. hors sujet, mais comme vous avez l'intention de faire des trucs côté client avec des données cartographiques: Gardez à l'esprit que IE7 et inférieur vont être problématiques si vous voulez dessiner des polygones avec OpenLayers. OpenLayers utilise SVG pour le dessin côté client, et IE7 et les versions inférieures n'ont pas de support intégré. Ces utilisateurs devront télécharger un ancien plugin merdique. Tous les autres navigateurs fonctionnent bien.}

GEOJSON est à mon avis, le meilleur format, il est facile à lire, facile à utiliser en javascript et généralement de plus petite taille que GML / KML. Il peut même contenir des informations sur le style, voir ici .

Ce n'est pas une norme officielle, mais il est pris en charge à la fois par dépliant et openlayers et sur de nombreuses applications gis-desktop comme qgis.

L'utilisation de GeoJSON est un bon début pour accélérer votre système, mais cela peut ne pas être suffisant. Vous devez envisager de créer plusieurs versions de votre couche de données, une par couche de zoom, et appliquer des méthodes de généralisation / simplification à chaque version. Le client doit demander la couche appropriée en fonction du niveau de zoom sélectionné. Cela garantirait que le niveau de détail des données échangées entre le serveur et le client est approprié, et augmenterait de manière plus significative à la fois le transfert réseau et le rendu. Pour aller plus loin, vous pouvez étendre votre système avec le pavage vectoriel et l'indexation spatiale comme décrit dans ce document , mais je ne suis pas sûr que les openlayers et le geoserver puissent le gérer ... pour le moment!

Pour sûr: Oubliez GML.

Pourquoi ne pas utiliser votre script python pour créer un nouveau fichier SLD et l'envoyer au serveur WMS avec votre demande.

Il y a un exemple ici .

J'ai déjà emprunté une route similaire deux fois et le rendu côté client pour autre chose qu'un petit nombre de points ou de polygones vraiment simples n'est tout simplement pas une bonne idée. Une fois que vous vous êtes lié à cette architecture, il est coûteux de revenir en arrière et dans tout projet, vous verrez probablement un changement dans les exigences ou une augmentation du volume de données alors que divers intervenants / superviseurs commencent à voir de quoi votre système est capable. L'approche de rendu côté client basée sur un navigateur n'est pas évolutive.

Si vous voulez un rendu dynamique, j'appuie l'approche de @ iant. J'ai décrit précédemment un certain nombre d'options pour un problème différent mais connexe ici . J'ai également utilisé la généralisation des polygones pour aider au rendu côté client et, bien que cela aide certainement, cela génère des problèmes plus difficiles, comme si vous souhaitez abaisser le polygone non généralisé lorsque votre utilisateur effectue un zoom avant.

Même si vous travaillez avec une plate-forme connue - par exemple, vous connaissez le matériel, la version du navigateur et les plugins de tous les clients - ce qui est peu probable, vous n'avez aucune idée du type de charge de ces clients. Ce type d'approche nécessite que le navigateur obtienne BEAUCOUP de temps CPU pour garder l'expérience utilisateur fluide et tout le reste va ennuyer vos utilisateurs.