Produits Entr'ouvert » Passerelle

On est d'accord que ça change le comportement des connecteurs actuels ? On est d'accord aussi que c'est une mauvaise idée de faire ça ?

Et le code n'est pas correct, il y a un peu plus haut la conversion des coordonnées reçues/calculées vers ce système de coordonnées, et celui-ci n'est pas mis à jour par le patch. (et donc on va se trouver à filer des coordonnées en epsg:3857 en les déclarant comme EPSG:4326….

Et pourquoi ce paramètre n'est pas utilisé dans l'endpoint feature_info ?

    query_layer = models.CharField(_('Query Layer'), max_length=256)
    projection = models.CharField(_('Preferred projection'), default='EPSG:3857', max_length=256)

Je ne sais pas si on est uniforme dans la capitalisation ailleurs dans Passerelle mais ici on ne l'est visibliement pas. Et peut-être "SIG Projection" pour bien noter qu'on parle de la projection de ce côté-là ?

Aussi, je me suis demandé un peu si on ne limiterait pas la liste, pour permettre en plus des libellés aux projections, genre ('EPSG:2154', 'EPSG:2154 (Lambert 93)').

('epsg:3857', _('EPSG:4171 (Pseudo-Mercator)')),

3857 vs 4171 ?

('epsg:3857', _('EPSG:3857 (Pseudo-Mercator)')),

Pour suivre https://epsg.io/3857 , plutôt avoir : EPSG:3857 (WGS 84 / Pseudo-Mercator). Et trier.

EPSG:4171 qui était la valeur utilisée, n'est même plus disponible. ?

On passait EPSG:XXXX, on passe epsg:XXXX, on est sûr que derrière les serveurs vont accepter ce changement ?

Dans les exemples de doc de geoserver je vois que les noms des paramètres et leur valeurs sont insensible à la case:

• http://docs.geoserver.org/latest/en/user/services/wms/basics.html#axis-ordering * http://docs.geoserver.org/stable/en/user/services/wms/reference.html#getmap

Je ne comprends pas le code.

Avant on envoyait toujours 'EPSG:4171' ou 'EPSG:3857' selon le endpoint. Maintenant on va envoyer self.projection, très bien. Mais pourquoi fais-tu alors une conversion dans tile ? Justement on n'a plus à la faire, c'est le service wms qui va s'en charger... non ?

Vu en direct avec Serghei, ma lecture c'est que je ne comprends même pas le code existant.

• Combo ou wcs vont interroger avec des coordonnées 3857 (le truc utilisé par les cartes en ligne), et feature_info fait comme si c'était du 4171... ie le code actuel me semble bugué. De même, le retour de feature_info sera en 4171.
• Ensuite, si on applique le patch, feature_info doit convertir en self.projection avant d'interroger le système en face. Et celui-ci renverra des coordonnées en self.projection, qu'il faudrait repasser en 3857.

• Pour les tuiles, le patch ne semble pas bon, sauf si j'ai raté quelque chose le endpoint reçoit du 3857 (et pas du 4326).

• endpoint_projection : une projection attendue pour les x/y reçus par les endpoints, qui serait 3857 par défaut ; modifiable lors de l'appel avec un ?proj=...
• gis_projection : une projection pour interroger le SIG en face, 4326 par défaut (le format des SIG de base, semble-t-il) [ce que propose ce patch]
• feature_info_gis_projection : une projection pour feature_info si différente (?)
• tile_gis_projection : une projection pour les tuiles si différente (?)

... parce que sinon on va lutter sans fin en fonction du/des logiciels en face et de leurs possibilités.

La difficulté pour moi c'est de reconvertir les résultats reçus du SIG (le build_dict_from_xml étant pour l'instant très kiss)

Je n'ai pas suivi l'historique des devs, notamment de feature_info, mais en reprenant l'exemple de l'url donnée dans #15431 et en changeant le système de projection en 3857 le résultat est le même, y compris les coordonnées.
Mais je n'ai pas l'impression que les coordonnées sont utilisées.

Sinon c'est EPSG:3857 qui est utilisé par les cartes, j'ai foiré mon patch.

Frédéric, tu peux nous rafrachir la mémoire du pourquoi tile et feature_info ont été implementées initialement avec des systèmes de projection différents?

Je n'ai pas suivi l'historique des devs, notamment de feature_info

C'est toi qui a développé ça.

Mes deux contributions au connecteur sont la séparation des urls pour les flux wms et wfs, et le endpoint features.

Ok désolé j'ai lu trop rapidement un git blame et visiblement ma mémoire étant ce qu'elle est, je n'ai pas plus de contexte que les tickets (#15431 puis #19603), juste que sans doute derrière ça attendait des trucs différents et voilà.

Ok.

Je propose d'interroger en self.project=4326 par défaut, avec conversion des inputs en 3857 vers en self.projection.

Et tant pis pour l'instant pour les coordonnées de retour ? On laisse passer build_dict_from_xml et c'est tout ? Ça me semble problématique, même si j'ai l'impression qu'on pinaille pour au final des histoires de quelques pixels (ça serait à vérifier, c'est juste mon impression au vu du code existant... qui marche ?).

En tout cas, difficile de pousser cela en recette maintenant (bascule en prod dans 3 jours). Plutôt début de semaine prochaine.

Oui, rajouter la conversion des coordonnées dans feature_info vers la projection choisie.
Je vais zapper pour l'instant la conversion des coordonées de retour.

Par rapport à l'existant: il y a déjà quelque part le connecteur deployé, ou les 2 endpoints: feature_info et tile sont utilisés. Après les changements de ce ticket il faudrait instancier un connecteur supplémentaire avec un autre système de projection.

Je vais m'arranger pour décaler l'arrivée en recette.

 # convert only when projection system is other than WGS84
 if self.projection != 'EPSG:4326':

WGS84 c'est EPSG:3857 non ? donc le commentaire match pas avec le code ?

Aussi 'EPSG:4326' est utilisé à plusieurs endroits et semble avoir un statut particulier (projection par défaut ?), bref le mettre dans une variable globale avec un nom qui permette à ignorant comme moi de comprendre ce que c'est, ce serait bien.

Emmanuel Cazenave a écrit :

[...]

WGS84 c'est EPSG:3857 non ? donc le commentaire match pas avec le code ?

Oublie ça, my bad.

ack