Produits Entr'ouvert » Passerelle

Ici je pense partir sur le même principe que les loaders des formats des fichiers dans le connecteur famille générique.
Si un format est choisi, le endpoint reverse va utilier le loader pour résoudre les coordonées, sinon ça ne retourne rien.

Uh ? Un format de quoi ?

Le retour devrait se faire au format de la BAN.

Le format pour le géocodage est celui de nominatim.

Frédéric Péters a écrit :

Uh ? Un format de quoi ?

Un format ou loader: ça serait un module qui s'occuperait à faire la requete vers GeoServer, avec conversion des coordonées au système utilisé dans la base derrière et retourner les données au format nominatim.

On est dans un connecteur standard interrogeant des services compatibles opengis, on n'a pas besoin de couche d'abstraction.

Qu'on puisse préciser la projection "préférée" à utiliser par le serveur, bien sûr, ça peut être paramètre. (il y a même d'ailleurs un ticket… #20826).

Tout à fait d'accord, sauf que la couche intérrogée (typeName) peut nommer les attributs différemment et pour les formater nominatim il faut un post traitement un peu "spécifique".

Franchement hostile; on doit arriver à discuter avec les équipes SIG pour obtenir quelque chose qu'on puisse interroger de manière standard. Sinon on passe par la BAN ou OSM.

Ou alors faire ça dans un autre connecteur dans contrib auquel je ne m'intéresserai pas.

Pour revenir quand même sur ce ticket, des pistes évitant du code spécifique à Grenoble (ni dans ce connecteur ni dans un autre) :

• ajouter au connecteur un paramétrage des noms des propriétés à utiliser
• tirer cette information de paramètres à l'URL (cela nécessiterait l'ajout côté w.c.s. de la possibilité de paramétrer ça)
• avoir des séries de possibilités (ex: attributes = {'road': ['road', 'street', 'rue', 'voie', 'nom_rue', 'nom_voie'], 'city': ['city', 'city_name', 'ville', 'commune', 'nom_ville', 'nom_commune'] ...})

_~~

À côté de ça, attention, côté wcs il est attendu que le service "nominatim" puisse faire géocodage et géocodage inversé, faire uniquement le géocodage inversé ça cassera l'action de géocodage.

Ok, donc on partirait sur l'usage de la méthode DWITHIN disponible dans le flux WFS. En plus des paramètres que tu mentionnes il faudrait rajouter un champ pour spécifier le rayon de recherche.
Il manque également #20826, je prend.

D'accord c'était cité dans "ajouter au connecteur un paramétrage des noms des propriétés à utiliser" mais quand même, à chaque fois qu'on demande du paramétrage en json dans un ui, je pleure.

Ok, alors un champ text pour chaque attribut: road, housenumber, etc avec une liste de propriétés à chercher dans les données retournées.

tirer cette information de paramètres à l'URL (cela nécessiterait l'ajout côté w.c.s. de la possibilité de paramétrer ça)
avoir des séries de possibilités (ex: attributes = {'road': ['road', 'street', 'rue', 'voie', 'nom_rue', 'nom_voie'], 'city': ['city', 'city_name', 'ville', 'commune', 'nom_ville', 'nom_commune'] ...})

Elles puent ces propositions ?

Non, mais ça m'embête de devoir faire des devs dans wcs pour passer des paramètres à un webservice pour lui indiquer comment formater les données. Ce paramètrage doit rester dans passerelle, imo.

Et :

avoir des séries de possibilités (ex: attributes = {'road': ['road', 'street', 'rue', 'voie', 'nom_rue', 'nom_voie'], 'city': ['city', 'city_name', 'ville', 'commune', 'nom_ville', 'nom_commune'] ...})

Oui, et c'est possibilités je les vois définies dans le connecteur, si c'est pas un jsonfield, alors un attribut du connecteur pour chaque attribut nécessaire pour le service de geocodage.

Oui, et c'est possibilités je les vois définies dans le connecteur, si c'est pas un jsonfield, alors un attribut du connecteur pour chaque attribut nécessaire pour le service de geocodage.

Et au contraire, plutôt que demander une configuration à l'usager (dans un textarea avec du json ou du csv dedans), cette approche était la mise en dur dans le connecteur d'une série de possibilités, comme on a pu avoir dans auquotidien quelque chose de cet ordre :

...
                ('streetAddress', ('streetAddress', 'address', 'adresse', 'street',)),
                ('street', ('streetAddress', 'address', 'adresse', 'street',)),
                ('postalCode', ('postalCode', 'codepostal', 'cp',)),
                ('telephoneNumber', ('telephoneNumber', 'telephonefixe', 'telephone',)),
...

L'idée étant que ça juste marche.

result['address'] = {'country': 'France'}

Pas fan; je préférerais que ça soit l'appelant qui décide quoi faire sur une valeur manquante. (mais bon)

1. return first found point

Plus fondamental, plutôt retourner le point le plus proche que celui qui par hasard va se trouver en premier.

Ok. Donc si on peut spécifier dans la requete genre: ?country=France pour qu'elle soit utilisée comme valeur de l'attribut.

Non, déjà noté plus haut aujourd'hui on ne peut pas ajouter de paramètres. (mais pourquoi vouloir le pays ?)

Aussi, par rapport à une utilisation dans w.c.s., déjà noté également, ça va foirer d'avoir géocodage inversé mais pas géocodage, si on veut deux services différents, là aussi ça va demander patch w.c.s.

Pas réussi à appliquer ton patch.

Ça retourne None si tu ne trouves pas de closest_feature, je ne sais pas ce que ça va donner comme réponse pour l'appelant du connecteur, ie peut être être plus explicite (voir même raiser une API error, parce que pour l'appelant, un service de géocodage inverse qui renvoie rien, ça fait un peu erreur quand même), je te laisse voir.

Il m'a fallu un moment pour comprendre le bloc ci-dessous, donc peut-être l'encapsuler dans une fonction avec un joli nom (ce qui te permettra de la tester) ou au moins mettre un commentaire.

min_delta = None
        for feature in response.json().get('features'):
            if not feature['geometry']['type'] == 'Point':
                continue  # skip unknown
            lon_diff = abs(float(lon) - float(feature['geometry']['coordinates'][0]))
            lat_diff = abs(float(lat) - float(feature['geometry']['coordinates'][1]))
            delta = math.sqrt(lon_diff * lon_diff + lat_diff * lat_diff)
            if min_delta is None:
                min_delta = delta
            if delta <= min_delta:
                closest_feature = feature

Tu gères pas du tout les erreurs éventuelles que peux te renvoyer le service pointé par wfs_service_url, à mon avis il faut au moins utiliser response.raise_for_status ou un truc comme ça et l'encapsuler dans une APIError.

Emmanuel Cazenave a écrit :

Pas réussi à appliquer ton patch.

Ça retourne None si tu ne trouves pas de closest_feature, je ne sais pas ce que ça va donner comme réponse pour l'appelant du connecteur, ie peut être être plus explicite (voir même raiser une API error, parce que pour l'appelant, un service de géocodage inverse qui renvoie rien, ça fait un peu erreur quand même), je te laisse voir.

Ça fonctionne de la même façon que nominatim. Quand il n'y a pas de données, on renvoie null (le None en json).

Il m'a fallu un moment pour comprendre le bloc ci-dessous, donc peut-être l'encapsuler dans une fonction avec un joli nom (ce qui te permettra de la tester) ou au moins mettre un commentaire.

Tu veux dire le calcul de l'hypothenuse ? Je préfère rajouter un commentaire au dessus des 3 lignes.

Tu gères pas du tout les erreurs éventuelles que peux te renvoyer le service pointé par wfs_service_url, à mon avis il faut au moins utiliser response.raise_for_status ou un truc comme ça et l'encapsuler dans une APIError.

Effectivement il manque le check du statut, je vais rajouter ça.

Ça fonctionne de la même façon que nominatim. Quand il n'y a pas de données, on renvoie null (le None en json).

En l'espèce nominatim semble plutôt répondre "{"error":"Unable to geocode"}". ex : https://nominatim.openstreetmap.org/reverse.php?format=json&lat=22.26895268313282&lon=-18.632978796958927&zoom=18 (je n'ai pas trouvé d'autre endroit que le milieu de l'océan pour un tel résultat).

Je me suis embrouillé avec notre connecteur base_adresse dont le endpoint reverse ne retourne rien quand il ne trouve pas l'adresse.

ack