Produits Entr'ouvert » Passerelle

En fait ça y est, il y a eu inversion des pôles :
https://pyproj4.github.io/pyproj/stable/gotchas.html#why-does-the-epsg-code-return-when-using-epsg-xxxx-and-not-with-init-epsg-xxxx

via l'objet CRS (qui fait l'objet de #55285) on voit :

(Pdb) wgs84_deprecated = CRS(init='EPSG:4326')
(Pdb) wgs84_deprecated
<Geographic 2D CRS: +init=epsg:4326 +type=crs>
Name: WGS 84
Axis Info [ellipsoidal]:
- lon[east]: Longitude (degree)  ## <---
- lat[north]: Latitude (degree)
Area of Use:
- name: World.
- bounds: (-180.0, -90.0, 180.0, 90.0)
Datum: World Geodetic System 1984
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich

(Pdb) wgs84_new = CRS('EPSG:4326')
(Pdb) wgs84_new
<Geographic 2D CRS: EPSG:4326>
Name: WGS 84
Axis Info [ellipsoidal]:
- Lat[north]: Geodetic latitude (degree)  ## <--- !!
- Lon[east]: Geodetic longitude (degree)
Area of Use:
- name: World.
- bounds: (-180.0, -90.0, 180.0, 90.0)
Datum: World Geodetic System 1984
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich

Je suis bien content d'être tombé sur les tests de non régressions.
Ce patch ne me parait pas trivial du tout (et j'ai peur d'avoir fait n'importe quoi).

cf https://dev.entrouvert.org/issues/33458 "send as is but invert coordinates"
Non, c'est pas simple...
(j'ai l'impression que le jeu de tests inverse les coordonnées)

0001:
J'ai ajouté des tests pour couvrir les 4 projections proposées par le connecteur.
Mais pour la géolocalisation inversé, à défaut d'avoir un vrai jeu de donnée, je me hasarde à modifier les coordonnées à la volée, et sur les 2 projections qui n'étaient pas couvertes (EPSG:2154 et EPSG:3857), les tests sur le géocodage inversé retournent une adresse différente.

0002:
Le même patch que ci-dessus.

Pour un autre connecteur (https://dev.entrouvert.org/issues/55230) je vais devoir projeter vers EPSG:4326
et alors peut-être que je pourrais revenir ici avec les idées claires.

• Les projections :
  https://dev.entrouvert.org/issues/20826
  • EPSG:4326 (WGS 84) : format pivot du connecteur
    utilié par les GPS et j'imagine par aussi par nominatim
    https://nominatim.org/release-docs/develop/api/Reverse/#parameters
    https://dev.entrouvert.org/issues/21558#note-4
  • EPSG:3945 (CC45)
    Utilisé par Grenoble
    https://dev.entrouvert.org/issues/21101
    ex: https://geoflux.lametro.fr/geoserver/wfs?version=2.0.0&service=WFS&request=GetFeature&typenames=ref_ban_metro&outputFormat=application%2Fjson&propertyName=num_secteur_voirie%2Csecteur_voirie&cql_filter=strEqualsIgnoreCase(code_insee%2C+%2738185%27)+%3D+true+AND+strEqualsIgnoreCase(nom_voie%2C+%27Rue+du+Valbonnais%27)+%3D+true
  • EPSG:2154 (Lambert-93)
    Évoqué à Nanterre
    https://dev.entrouvert.org/issues/21850
  • EPSG:3857 (WGS 84 / Pseudo-Mercator)
    Utilisé à Lyon https://dev.entrouvert.org/issues/33133
    Souhaité par strasbourg https://dev.entrouvert.org/issues/25702
    ex: https://passerelle.guichet-recette.grandlyon.com/opengis/data-grandlyon-general/query/compostage/?orig=portail-citoyen.guichet-recette.grandlyon.com&algo=sha256&timestamp=2021-07-02T09%3A31%3A13Z&nonce=67414d3b13b042855258847f32b62ad6&signature=BXsjuHQhSto2CPQc17VbzMVrx/4rbVaPXDJrqc1zMUM%3D

ex: https://epsg.io/transform

EPSG:4326, lon: 4.784040,   lat: 45.796790 
EPSG:3945, x: 1838692.98,   y: 4290077.11
EPSG:2154, x: 838570.18,    y: 6523472.77
EPSG:3857  x: 532556.90,    y: 5747844.26

• Géocodage inverse (Code qui ne fait pas intervenir la bbox)
  https://dev.entrouvert.org/issues/21558
  Le jeu de donnée pour les tests sur la géolocalisation inversée n'a pas bougé depuis.
  Les coordonnées x,y du geojson correspondent à lat, lon (inversé).
  Il ne couvre que la projection EPSG::3945.

• Inversion coordonnées bbox
  https://dev.entrouvert.org/issues/33458
  pour Lyon, en WMS en EPSG:4326 (WGS 84)
  ex: https://passerelle.toodego.com/opengis/parcelle-cadastrale/
  Dans le test on valide le fait que la longitude et la latitude soit inversée dans la bbox pour EPSG:4326 seulement.