#TeamOpenData

Guide Etalab "Utiliser les API à composante géographique"

Bonjour,

Avec la casquette Etalab, j’ai rédigé de la documentation pour utiliser les APIs Adresse, Découpage Administratif et OpenMapTiles Introduction | guides.etalab.gouv.fr (source sur https://github.com/etalab/guides.etalab.gouv.fr/tree/master/apis-geo)

N’hésitez pas à nous faire des retours sur le contenu.

Merci de vos retours

5 Likes

Bonjour Thomas.

Excellent ! En particulier le fait de ne plus dépendre de l’API de Google !
Savez-vous s’il est possible d’afficher avec ce même interface :

  • plusieurs points sur la carte en s’affranchissant de Google Maps, avec les coordonnées GPS par exemple ?
  • les parcelles telles que fournies en Open Data ?

Merci

Merci, c’est très intéressant.

Sur l’API adresses, une explication serait bienvenue sur le « score » qui peut quelques fois déterminer si l’adresse trouvée est bien celle recherchée ou bien si elle s’en rapproche seulement.
Des seuils à partir desquels c’est très approximatif, des explications sur son calcul…
Dans les ressources complémentaires, vous pouvez citer le MOOC : La gestion des adresses par les communes

Sur les tuiles, j’ai un besoin un peu différent et peut-être pourrez-vous m’aider.

Quelques éléments ici:

On ne peut malheureusement pas donner un score à partir duquel on peut considérer que l’adresse trouvée est bien celle cherchée, car cela dépend fortement de la qualité des deux adresses et de la façon dont elles sont libellées.

Avec la version 1.1 d’addok le mode de calcul a aussi un peu changé.

Merci @cquest . Très intéressant d’en savoir un peu plus sur ce qu’il y a sous le capot.

Sur le score, je suis bien conscient que c’est un challenge. Cependant sur des applications/services « à l’adresse », il est important d’avoir LA bonne adresse. Et on ne peut pas toujours proposer un autocomplete à l’utilisateur. Quelques fois on part d’adresses « normalisées » à partir de référentiels différents (Google, La poste) dont la nomenclature peut être différente de celle de la BAN. Ou d’adresse pas du tout normalisée issues de champs de saisie « libres » :nauseated_face:
En tout cas pour nous cette notion de score est très importante.

La « normalisation »… si il s’agit de la norme NF à destination de l’usage postal, elle ne s’occupe que de faire tenir l’adresse dans les fenêtres des enveloppes :wink:

De plus elle n’est même pas d’accès libre et même La Poste ne la respecte pas entièrement.

C’est sûr que l’approche d’addok était plutôt à l’origine l’autocomplétion, d’où ce mode de fonctionnement très orienté recherche full-text et le mode de calcul du score.

En tout cas, je suis preneur de suggestions pour améliorer ça !

Est-ce que fournir un forme structurée de l’adresse à chercher pourrait être une piste à suivre ?

Il faut aussi exploiter au maximum les filtres d’addok, qui permet de limiter la recherche à un sous ensemble de la base, par exemple en fournissant le code INSEE de la commune ou le code postal.
Ceci élimine le risque de résultats incorrects mais proches textuellement (exemple: Rue de Paris à St Mandé vs Rue de Saint-Mandé à Paris).
J’ai envisagé de fournir le score de l’adresse suivante car si il est trop proche de la première, c’est un bon indicateur de confusion possible.

Oui ! En découpant numéro / rue / CP / Ville, il est surement possible d’améliorer le matching et d’avoir un score plus exploitable.
Ça serait presque une autre API…

Une information du genre : l’API a trouvé la rue (dans la « bonne ville »), mais le numéro n’existe pas (encore) dans cette rue, pourrait être aussi intéressante.
Cela pourrait aider sur des cas ou l’adresse est récente (bâtiment neuf) ou la municipalité n’a pas fini de compléter son référentiel d’adresse.

C’est déjà le cas, si le numéro n’est pas trouvé, addok ne retourne que l’info sur la rue avec un type=street

Exemple: https://demo.addok.xyz/search?q=555+avenue+de+la+republique&citycode=94068

{
  "type": "FeatureCollection",
  "version": "draft",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          2.486021,
          48.802021
        ]
      },
      "properties": {
        "label": "Avenue de la République 94100 Saint-Maur-des-Fossés",
        "score": 0.7167318593171534,
        "id": "940688165Y",
        "citycode": "94068",
        "type": "street",
        "name": "Avenue de la République",
        "postcode": "94100",
        "city": "Saint-Maur-des-Fossés",
        "departement": "Val-de-Marne",
        "region": "Île-de-France",
        "importance": 0.4459,
        "street": "Avenue de la République"
      }
    },
...

Oui et oui

1000 mercis Thomas je vais regarder avec attention.

Peut-être des exemples sont plus parlants:
https://api-adresse.data.gouv.fr/search/?q=19%20rue%20Chappe%2063100%20CLERMONT%20FERRAND
retourne bien un
label": "19 Rue Chappe 63100 Clermont-Ferrand"
avec un bon score (0.977)

Mais https://api-adresse.data.gouv.fr/search/?q=19%20rue%20Chappe%2063000%20CLERMONT%20FERRAND
(avec un CP changé de 1 caractère) retourne une rue complètement différente :
"label": "19 Rue de Cotepet 63000 Clermont-Ferrand"
avec un score de 0.656

https://api-adresse.data.gouv.fr/search/?q=54%20BOULEVARD%20CLEMENCEAU%2035000%20RENNES
retourne bien le
label": "54 Boulevard Georges Clemenceau 35200 Rennes"
mais avec un score de 0.672

Et donc quand on a ces adresses en entrée, c’est difficile pour nous de les rattacher au bon endroit…