Addok ne retourne pas toutes les adresses

Adresses addok - le géocodeur
1

Bonjour,

Je veux partager ici et analyser un comportement déroutant que l’on m’a remonté cette semaine et qui, du coup, bloque une saisie d’adresse dans une application qui va chercher les adresses sur la BAN / addok.

Dans la BAN, sur le toponyme “Clos du Peillac” nous avons 3 adresses :

  • 42 A bis
  • 42 B bis
  • 42 C bis

On a un souci de remontée car en vrai c’est 42 bis A, 42 bis B… mais ce n’est pas grave car la démonstration fonctionne aussi juste à côté avec le 38, 38 bis et 38 ter avenue de la gare.

Si on recherche “42 clos du peillac”, sans ou avec précision du type :

https://data.geopf.fr/geocodage/search?q=42%20clos%20du%20peillac&limit=20&lat=48.0457542&lon=-1.6011309

https://data.geopf.fr/geocodage/search?q=42%20Clos%20du%20Peillac&limit=20&lat=48.0457542&lon=-1.6011309&type=housenumber

Cela ne renvoie effectivement rien du tout !
C’est déroutant pour les utilisateurs.

Comment peut-on modifier ce comportement ?
Je poste ici avant de faire une issue sur github.

2

Je pense que le double suffixe pose un gros problème car c’est un cas encore jamais vu et pas du tout géré ou alors très très mal.

La première question c’est de savoir à quoi ressemblent ces données dans les fichiers BAN qu’on donne à manger à addok…

{
  "id": "35352_y1xzgk",
  "banId": "7bd7dffa-c2c7-412a-8e53-3982ba0fdfcf",
  "name": "Clos du Peillac",
  "postcode": "35770",
  "citycode": [
    "35352"
  ],
  "oldcitycode": null,
  "lon": -1.592059,
  "lat": 48.047316,
  "x": 358024.74,
  "y": 6781828.21,
  "city": [
    "Vern-sur-Seiche"
  ],
  "oldcity": null,
  "context": "35, Ille-et-Vilaine, Bretagne",
  "type": "street",
  "importance": 0.4652,
  "housenumbers": {
    "42a bis": {
      "id": "35352_y1xzgk_00042_a bis",
      "banId": "543875e7-96ec-4b5a-a537-ec56774ebcd3",
      "x": 358000.76,
      "y": 6781822.7,
      "lon": -1.592376,
      "lat": 48.047254
    },
    "42b bis": {
      "id": "35352_y1xzgk_00042_b bis",
      "banId": "4eeee75c-3101-45a0-b690-9bf68479e390",
      "x": 358032.21,
      "y": 6781824.54,
      "lon": -1.591956,
      "lat": 48.047287
    },
    "42c bis": {
      "id": "35352_y1xzgk_00042_c bis",
      "banId": "003df961-383c-41b9-9c3e-dca526a7b614",
      "x": 358041.16,
      "y": 6781837.16,
      "lon": -1.591846,
      "lat": 48.047405
    }
  }
}

Donc des “42a bis”, “42b bis”, “42c bis”

Une fois importé dans addok on a ceci (sur mon addok de la cave):

id 35352_y1xzgk
banId 7bd7dffa-c2c7-412a-8e53-3982ba0fdfcf
name Clos du Peillac
postcode 35770
citycode ['35352']
oldcitycode None
lon -1.592059
lat 48.047316
x 358024.74
y 6781828.21
city ['Vern-sur-Seiche']
oldcity None
context 35, Ille-et-Vilaine, Bretagne
type street
importance 0.4652
_id nG0BP
housenumbers 42a bis, 42b bis, 42c bis

Il ne sont pas modifiés par addok.

Quand on cherche avec “42a bis”, addok détecte le 42a comme étant le numéro… qu’il ne retrouve pas ensuite vu que c’est “42a bis”

Il n’y a aucun combinaison qui fonctionne.

Bref… un beau bazar qui commence par une numérotation farfelue.

Comme il n’y a que trois adresses dans ce “Clos”, elles auraient pu avoir une numérotation propre et pas un numéro sûrement rattaché à une autre voie (l’Avenue de la Gare).

42bis/ter/quater ou A/B/C sans ce bis superflu et rattachés Avenue de la Gare aurait été tellement moins problématique (et plus logique).

3

Alors je ne vais pas commenter sur l’adressage car il est ainsi et on doit faire avec.
Et je redis que ici on devrait avoir “42 bis a” et que ce pb est de notre côté. Mais que ça ne marche pas mieux au “38 rue de la Gare” juste à côté.

J’ai omis de dire que dans les fichiers BAL en téléchargement on a :

image

qui est donc correct par rapport aux données originelles.

En revanche : ce n’est pas bon côté fichier addok (je n’avais pas pensé à le regarder) :

{
    "id": "35352_y1xzgk",
    "banId": "7bd7dffa-c2c7-412a-8e53-3982ba0fdfcf",
    "name": "Clos du Peillac",
    "postcode": "35770",
    "citycode": ["35352"],
    "oldcitycode": null,
    "lon": -1.592059,
    "lat": 48.047316,
    "x": 358024.74,
    "y": 6781828.21,
    "city": ["Vern-sur-Seiche"],
    "oldcity": null,
    "context": "35, Ille-et-Vilaine, Bretagne",
    "type": "street",
    "importance": 0.4652,
    "housenumbers": {
        "42a bis": {
            "id": "35352_y1xzgk_00042_a bis",
            "banId": "543875e7-96ec-4b5a-a537-ec56774ebcd3",
            "x": 358000.76,
            "y": 6781822.7,
            "lon": -1.592376,
            "lat": 48.047254
        },
        "42b bis": {
            "id": "35352_y1xzgk_00042_b bis",
            "banId": "4eeee75c-3101-45a0-b690-9bf68479e390",
            "x": 358032.21,
            "y": 6781824.54,
            "lon": -1.591956,
            "lat": 48.047287
        },
        "42c bis": {
            "id": "35352_y1xzgk_00042_c bis",
            "banId": "003df961-383c-41b9-9c3e-dca526a7b614",
            "x": 358041.16,
            "y": 6781837.16,
            "lon": -1.591846,
            "lat": 48.047405
        }
    }
}

Il manque clairement un espace : le ‘a’ est collé au 42.
Je remonte ça à l’IGN.

Mais même en mettant l’adresse entière : addok ne renvoie rien :

https://api-adresse.sig.rennesmetropole.fr/search/?q=42a%20bis%20Clos%20du%20Peillac&limit=20&lat=48.0457542&lon=-1.6011309&type=housenumber

https://api-adresse.sig.rennesmetropole.fr/search/?q=42%20a%20bis%20Clos%20du%20Peillac&limit=20&lat=48.0457542&lon=-1.6011309&type=housenumber

Ce qui semble confirmer aussi un souci côté addok comme tu l’évoquais plus haut.
Donc j’ouvre une issue ?

4

Le 38 est bien trouvé, si tu met Avenue et pas Rue : https://data.geopf.fr/geocodage/search?q=38%20avenue%20de%20la%20gare&limit=20&lat=48.0457542&lon=-1.6011309

La préférence géographique ne prendra pas le pas sur un mot incorrect (rue au lieu d’avenue), elle ne sert qu’à départager ce qui est identique.

Le probème pour les “42 A bis” c’est la présence d’espace dans le suffixe qui fout la pagaille.

Le code ne peut pas corriger des choix farfelus (et sûrement pas tous). Il faudrait à minima qu’addok élimine à l’import ce qui est après un espace dans le suffixe et ici ça permettrait de retomber sur les pieds.

5

On doit faire avec l’existant, Christian…

Je pense que le problème est décrit dans cette issue ?

Il faudrait à minima qu’addok élimine à l’import ce qui est après un espace dans le suffixe

En voilà une bonne idée ! Pas l’idéal mais ça semble opportun.