Disparition des entités ponctuelles dans Geoserver à l'aide de WMS

10

J'ai un fichier de formes avec environ 6 500 points dans le monde que j'essaie de servir avec Geoserver 2.2.1 en utilisant WMS. Tout s'est apparemment bien passé jusqu'à ce que j'implémente une fonction de filtrage sur mon application cliente qui utilise la brochure. Lorsque j'ajoute un CQL_FILTER (filtre d'attribut, pas spatial) dans la requête WMS, j'ai remarqué des fonctionnalités manquantes lors d'un zoom arrière. Lorsque je zoomais en arrière, elles réapparaissaient parfois, mais pas toujours. Voir l'image ci-dessous -

Comparaison côte à côte

Au niveau du zoom à gauche, Atlanta ne s'affiche pas. Quand je fais un zoom avant, ça l'est. Cependant, parfois même le point de Tampa n'est pas affiché au niveau de zoom sur la gauche. Si je fais un zoom arrière de 3 niveaux supplémentaires, aucun point ne sera affiché. Je ne suis pas sûr que le problème soit le paramètre CQL_FILTER, car avec 6500 points, il est difficile de remarquer quelques points manquants à l'échelle mondiale, mais le filtre particulier que je montre ici à titre d'exemple ne filtre que sur 3 fonctionnalités, et quand 1 à 3 d'entre eux manquent en fonction du niveau de zoom c'est particulièrement visible.

Je peux recréer ce même comportement dans l'aperçu des couches de geoserver en utilisant le filtre CQL dans les options de carte avancées, donc je suis assez certain que ce n'est pas mon application client.

En ce qui concerne mes propres étapes de débogage de ce problème, j'ai essayé le fichier style / sld Points par défaut pour exclure mon propre style de calque. J'ai désactivé toute la mise en cache que je connais. J'ai revérifié que mes projections sont correctes - j'ai créé le fichier de formes dans ArcGIS 10 en utilisant WGS_1984_Web_Mercator_Auxiliary_Sphere comme projection, et la couche est définie sur EPSG: 3857 dans le géoserveur, qui je pense est équivalent. J'ai également mis à niveau de geoserver 2.2 vers 2.2.1 et j'ai eu le même problème dans les deux. J'ai également supprimé le fichier d'index spatial de geoserver (.qix) et je l'ai laissé recréer car j'ai vu des problèmes similaires dans Arc avec des index spatiaux corrompus, mais évidemment cela n'a pas fonctionné non plus.

Voici un instantané de l'aperçu de la couche de Geoserver avec le filtre CQL activé et zoomé dans la même zone comme indiqué ci-dessus. Le cercle rouge est approximativement là où je devrais voir un autre point (Atlanta).

Exemple d'Openlayers

J'ai essayé de peaufiner tous les autres paramètres auxquels je peux penser, mais je n'ai pas de chance. J'ai également regardé de haut en bas les journaux du géoserveur et activé la journalisation détaillée, et je ne vois aucune erreur / exception. Je ne vois pas non plus de mauvaises demandes dans les outils de développement de Chrome.

Si je manque des informations critiques, je fournirai ce que je peux, mais il s'agit d'une application interne / non publique.

MWrenn
la source
1
Éliminer l'évidence: avez-vous, par hasard, des styles dépendants de l'échelle? (c'est-à-dire qu'un point n'est affiché qu'entre certaines échelles)
unicoletti
1
Pouvez-vous vérifier que les valeurs de VENUE_TYPE sont valides / cohérentes? Les résultats incohérents que vous voyez peuvent être dus au fait que les fonctionnalités sont retournées dans un ordre différent (en raison de légères différences dans la bbox) et l'une d'entre elles est `` mauvaise '' d'une manière ou d'une autre, provoquant l'arrêt du rendu avant qu'il ne frappe Atlanta. Il pourrait être judicieux de tester l'exportation de vos données vers un format différent, puis 1) de vérifier tout ce qui a été déplacé comme prévu, puis 2) de tester à nouveau votre filtre / rendu
tomfumb
1
@unicoletti Sur le calque affiché dans la capture d'écran, il y a des dépendances d'échelle, mais je vois le même résultat lorsque j'utilise le style de «point» par défaut fourni par Geoserver, qui n'a pas de dépendances d'échelle, je vois les mêmes points disparaître exactement aux mêmes échelles .
MWrenn
1
@tomfumb J'ai regardé les valeurs dans la colonne VENUE_TYPE et elles sont toutes en alphanumérique anglais à l'exception d'une barre oblique "/" ou d'une esperluette "&". Je vais retirer les disques avec les barres obliques et les esperluettes et voir si cela fait une différence. En remarque, le DBF de ce fichier de formes est encodé en UTF-8 que j'ai également défini dans le géoserveur. Cela pourrait-il faire une différence?
MWrenn
4
@MWrenn Je ne suis pas sûr, donc je ne tenterai pas de réponse, mais l'exportation des données vers un autre format devrait aider à déterminer si le magasin / format actuel est le problème. Essayez peut-être d'ouvrir votre Shp dans ArcMap ou QGIS, en restreignant la zone à la bbox de votre exemple, puis inspectez les attributs des entités contenues - cela inclut-il des caractères spéciaux qui pourraient être affectés par l'encodage?
tomfumb

Réponses:

1

La «solution» que j'ai implémentée était d'importer les fichiers de formes dans une base de données postGIS à l'aide de shp2pqsql, ce qui a résolu la disparition des fonctionnalités de point lors de l'utilisation d'un filtre CQL. Je peux faire exactement la même demande de filtre CQL et voir tous les points à tous les niveaux de zoom maintenant. J'ai ensuite dû modifier quelques processus automatisés pour mettre à jour la base de données postGIS au lieu des fichiers de formes, mais cela n'a pris que quelques heures.

Je ne suis toujours pas sûr de la cause première de la disparition des entités ponctuelles. J'ai essayé différentes projections et rédacteurs de fichiers de formes (QGis, ESRI, shapefile.py ou pyShape ou quelque chose) avec le même résultat exact à chaque fois. Je ne suis pas un expert en géoserveur, donc j'hésite à l'appeler un bug, et c'est probablement quelque chose de particulier à ma configuration, mais j'ai pu reproduire sur deux instances différentes fonctionnant sur deux ordinateurs différents de géoserveur exécutant 2.2 et 2.2. 1, à la fois sur Windows (One Xp, sur Server 2003).

Je ne peux pas non plus publier les fichiers de formes source, donc je suppose que la cause profonde restera un mystère.

MWrenn
la source