Produits Entr'ouvert » Passerelle

Hold on.

When the SRS parameter specifies a Geographic Coordinate Reference System, e.g., "EPSG:4326", the returned image is implicitly projected using a pseudo-Plate Carree projection that plots Longitude along the X-axis and Latitude along the Y-axis. The BBOX request parameter (Section 7.2.3.6, BBOX) values for such a coordinate reference system shall be specified in the order minimum longitude, minimum latitude, maximum longitude, maximum latitude. The BBOX parameter values shall use the coordinate reference system units.

Some Projected Coordinate Reference Systems, e.g., "EPSG:30800" ("RT38 2.5 gon W", used in Sweden), have axes order other than X=East, Y=North. The BBOX request parameter values for such a coordinate system shall be specified in the order minimum Easting, minimum Northing, maximum Easting, maximum Northing. The BBOX parameters shall use the coordinate reference system units.

— http://cite.opengeospatial.org/OGCTestData/wms/1.1.1/spec/wms1.1.1.html

Ce document contient aussi la note "Section 6.5.5.1 has been clarified regarding the order of values in the BBOX request parameter." comme quoi ça a pu ne pas être bien clair à un moment.

Mais pour la spec 1.3, d'après https://docs.geoserver.org/stable/en/user/services/wms/basics.html#axis-ordering

The WMS 1.3.0 specification mandates that the axis ordering for geographic coordinate systems defined in the EPSG database be latitude/longitude, or y/x. This is contrary to the fact that most spatial data is usually in longitude/latitude, or x/y. This requires that the coordinate order in the BBOX parameter be reversed for SRS values which are geographic coordinate systems.
...
Note that the coordinates specified in the BBOX parameter are reversed.

C'est un peu le carnage, OpenGIS, mais le matin c'est plus clair; en gros l'histoire c'est qu'ils ont voulu faire valider tout ça par l'ISO qui a dit que dans leurs autres standards l'ordre des coordonnées était latitude/longitude, qu'il fallait changer ça, mais qu'en fait attention c'était plus compliqué que ça suivant les projections l'ordre est différent (mais les projections sont "standardisées" donc tout va bien), etc.

Ce qui donne un truc genre https://github.com/pyproj4/pyproj/issues/225 pour ajouter des options à pyproj, mais c'était il y a deux semaines seulement. (et il semble y avoir un sacré saut dans pyproj 2.x, c'est d'ailleurs dispo uniquement dans experimental).

Bref, patch pour unifier les deux endroits où on calcule des bbox, et là on profite du fait que EPSG:4326 soit notre format d'entrée et qu'on n'a pas besoin de conversion pour lui, pour court-circuiter le code et intervertir les valeurs. (à la base j'avais tapé un dictionnaire PROJECTION_OPTIONS, me disant que ça pouvait être nécessaire pour d'autres projections, mais les quelques projections qu'on expose n'ont pas besoin de ça).

C'est testé en vrai, les deux endpoints (tile et feature info), avec les deux projections, en utilisant data.grandlyon.

Le connecteur opengis est également utilisé à Grenoble mais pour un endpoint "reverse" qui n'utilise pas de bbox.

Le changement SRS -> CRS c'est lié à quoi dans tout ce que tu dis ?

commit 61bb06b14359ab206e8f1fbf16bf389690603820
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Tue May 28 08:03:52 2019 +0200

    opengis: compute bbox according to opengis 1.3 rules (#33458)