Adresses avec codes postaux multiples dans les exports

[amatissart]

Certaines adresses contiennent plusieurs codes postaux, séparées par un ; dans l'export .csv. Cela semble être un changement assez récent dans le format des exports.

Ainsi pour toutes les adresses situées à Nice:

060880010J-7,7,Rue de l'Abbaye,06000;06100;06200;06300,Nice,OD,43.69672,7.27552
060880010J-8,8,Rue de l'Abbaye,06000;06100;06200;06300,Nice,OD,43.696924,7.274846
060880020V-1,1,Chemin de l'Abbaye Saint-Pons,06000;06100;06200;06300,Nice,O+O,43.730649,7.276723
060880020V-5,5,Chemin de l'Abbaye Saint-Pons,06000;06100;06200;06300,Nice,O+O,43.730498,7.277908
...

ou dans Paris 16e:

751160603X-9,9,Square de l'Avenue Foch,75016;75116,Paris 16e Arrondissement,OSM,48.872976,2.277852
751160603X-9B,9B,Square de l'Avenue Foch,75016;75116,Paris 16e Arrondissement,OSM,48.872929,2.277925
751160669U-1,1,Place de Barcelone,75016;75116,Paris 16e Arrondissement,OD,48.847115,2.273129
751160669U-2,2,Place de Barcelone,75016;75116,Paris 16e Arrondissement,OSM,48.847834,2.273726
...

• Est-ce une limitation connue dans les sources de données ou le processus d'export ? Il me semblait pourtant que la distinction 75016 / 75116 (par exemple) était réalisée par le passé.

• Ce format avec le séparateur ; dans les fichiers .csv est-il attendu ? D'après ce que j'ai pu voir ce point n'est pas documenté, et le fichier lisezmoi-bano.txt précise même:
  

  bano/out/lisezmoi-bano.txt

  Line 77 in d21bf84

  - code_post : code postal sur 5 caractères

[vdct]

Bonsoir @amatissart , et merci du signalement.
A la fois rien n'a changé sur cette thématique récemment, aussi bien côté code que données, et à la fois je constate comme vous le changement dans le contenu exporté. Donc il y a un loup quelque part, j'essaie de regarder au cours de la semaine.

[amatissart]

Je me permets de relancer ce sujet. Je serais preneur de quelques précisions pour comprendre l'origine du problème, et éventuellement proposer une correction.

Si je comprends bien, le contenu de l'export .csv est déterminé par ce fichier:
https://github.com/osm-fr/bano/blob/packaging/bano/sql/export_csv_dept.sql

Et dans cette requête SQL, c'est le code postal tiré des polygones d'Openstreetmap qui est utilisé en priorité, en correspondance avec le code INSEE de l'adresse considérée, via le tag ref:INSEE:

bano/bano/sql/export_csv_dept.sql

Line 39 in 2a295f5

COALESCE(cp.postal_code, lp.cp, ca.code_postal) AS code_post,

bano/bano/sql/export_csv_dept.sql

Lines 83 to 84 in 2a295f5

	LEFT JOIN planet_osm_postal_code cp
	ON (cp."ref:INSEE" = u.insee_com AND ST_Contains(cp.way, ST_Transform(COALESCE(o.geometrie, od.geometrie, c.geometrie),3857)))

D'où l'utilisation des relations suivantes qui portent les tags postal_code et ref:INSEE.
pour Nice: https://www.openstreetmap.org/relation/170100 avec postal_code=06000;06100;06200;06300
pour Paris 16e: https://www.openstreetmap.org/relation/9517 avec postal_code=75016;75116

Ce qui expliquerait pourquoi les relations avec boundary=postal_code (mais sans ref:INSEE) sont ignorées.
Comme 75016 https://www.openstreetmap.org/relation/8145166
ou 75116 https://www.openstreetmap.org/relation/4548229

Plus dommage encore, le code postal provenant directement de la source d'adresses (a priori le plus fiable ?), ne semble donc jamais être utilisé. Est-ce qu'il y a une motivation particulière pour l'implémentation existante ?

Ne serait-il pas pertinent au moins d'utiliser la valeur code_postal associée aux adresses, tel que c'est déjà fait pour le numéro ou la position ?

diff --git a/bano/sql/export_csv_dept.sql b/bano/sql/export_csv_dept.sql
index 408327b..d330267 100644
--- a/bano/sql/export_csv_dept.sql
+++ b/bano/sql/export_csv_dept.sql
@@ -36,7 +36,7 @@ AS
             '"',CHR(39)), 
           ', ',' '), 
         ',',' ') AS voie, 
-        COALESCE(cp.postal_code, lp.cp, ca.code_postal) AS code_post,
+        COALESCE(o.code_postal, od.code_postal, c.code_postal, cp.postal_code, lp.cp, ca.code_postal) AS code_post,
         COALESCE(cn.libelle,initcap(ca.nom_com)) AS ville, 
         CASE 
             WHEN u.num=o.num THEN 'OSM' 

[vdct]

Je me permets de relancer ce sujet. Je serais preneur de quelques précisions pour comprendre l'origine du problème, et éventuellement proposer une correction.

J'ai totalement laissé le sujet de côté suite à votre message de décembre, désolé

Plus dommage encore, le code postal provenant directement de la source d'adresses (a priori le plus fiable ?), ne semble donc jamais être utilisé. Est-ce qu'il y a une motivation particulière pour l'implémentation existante ?

Ne serait-il pas pertinent au moins d'utiliser la valeur code_postal associée aux adresses, tel que c'est déjà fait pour le numéro ou la position ?

Oui je suis d'accord, et c'est bien dans la logique de privilégier la donnée attachée directement aux adresses. Le code actuel ne le fait pas, et en fait ne l'a jamais fait. Je viens d'ouvrir #237 pour tracer l'évolution. Ca devrait assécher le souci de valeurs multiples dans le sens où la BAN propose pour chaque adresse un CP. Le CP OSM, associé à l'adresse OSM, sera toujours prioritaire dans le CSV. Pour les endroits où le CP BAN est erroné (comme typiquement dans le XVI où ne figure pour la BAN que le CP 75016) il s'agira donc de correctement renseigner les adresses OSM avec le CP 75116 sur environ la moitié de l'arrondissement.

[vdct]

@amatissart
Mon commit de ce soir donne la priorité aux CPs directement connus des adresses, en cherchant d'abord le CP des adresses OSM puis celui de la BAN. Je pense que ça règle pas mal de cas, mais ça en ouvre d'autres, quand le CP OSM est (a priori) erroné. Merci pour votre retour

[amatissart]

@vdct
merci pour le fix. La majorité des cas semblent en effet résolus dans les datasets exportés aujourd'hui 👍

Pour moi, la seule question en suspens reste l'utilisation ou non des polygones boundary=postal_code pour déterminer le code postal d'une adresse, quand il n'est pas explicité à la source et ne peut pas être déduit du code INSEE. Mais là aussi, si je comprends bien, cela peut être résolu en renseignant si besoin addr:postcode dans OSM.

Quant aux codes 75016 et 75116 dans la BAN, savez-vous si le problème a déjà été signalé pour être résolu à la source ?

[vdct]

Merci pour votre retour

Le souci est qu'on dispose d'au moins 2 sources de CP qui couvrent intégralement le territoire : les polygones postaux d'OSM et les CPs placés sur chaque adresse de la BAN. On considère que les CPs placés à l'adresse sur OSM sont prioritaires, via en effet le tag addr:postcode. Mais il est peu présent, environ 1 million d'occurrences. Si en seconde priorité on choisit le CP des polygones postaux, par croisement spatial, alors c'est cette source qui va remplir la quasi intégralité des valeurs de CPs. A l'inverse si on priorise la source de CPs BAN, alors on n'utilisera pas du tout les polygones postaux.
Cette logique vaut tant qu'on utilise chaque source intégralement.
En affinant, au prix d'un peu de "dentelle", il faudrait disposer d'une couche de polygones postaux issue d'OSM mais limitée aux CPs infra-communaux (Meudon la Forêt, La Varenne Saint-Hilaire, Paris XVI, etc) et appliquer l'ordre de priorité suivant :

1. CP issu du point d'adresse OSM
2. CP issu des polygones de CP OSM infra-communaux même si l'adresse elle même vient de la BAN
3. CP de la BAN, en fallback
   Comme vous le dites on peut remplacer le 2. par l'ajout systématique du tag addr:postcode sur les adresses OSM incluses dans les zones de CP infra-communaux mais c'est bien sûr plus fastidieux que de gérer un polygone englobant

[AghilasMessara]

Bonjour,
Y a t-il eu du changement depuis le dernier commentaire?
Nous venons de remarquer le même problème dans le 63. Par example

631132583L-14,14,Square des Laminés,63000;63100,Clermont-Ferrand,OSM,45.798824,3.115221
631132583L-16,16,Square des Laminés,63000;63100,Clermont-Ferrand,OSM,45.798822,3.115414
631132583L-20,20,Square des Laminés,63000;63100,Clermont-Ferrand,OSM,45.798821,3.115793

Merci pour votre aide.

[vdct]

Bonsoir,
Il n'y a pas eu de changements récents non, à part ceux faits ce soir et sans lien avec le souci que vous remontez. Je constate en effet encore un paquet de CPs doubles. Le cas est mieux géré dans le format JSON, je vais essayer de transposer ça au CSV.

[AlexandreMarcq]

Bonjour @vdct , j'ai remarqué la même chose dans le format JSON :

{"id":"674824020","citycode":"67482","type":"street","name":"Rue Livio","postcode":"67000;67100;67200","lat":48.552213,"lon":7.740345,...}
{"id":"060884805","citycode":"06088","type":"street","name":"Rue Parmentier","postcode":"06000;06100;06200;06300","lat":43.713811,"lon":7.259219...}
{"id":"060882370","citycode":"06088","type":"street","name":"Avenue de Fabron","postcode":"06000;06100;06200;06300","lat":43.689717,"lon":7.220905,...}

Je ne sais pas si cela a un rapport, mais ces rues sont présentes deux fois avec le même id mais des housenumbers différents :

{"id":"060884805","housenumbers":{"10":{"lat":43.713939,"lon":7.260622},"11":{"lat":43.713805,"lon":7.26026},"13":{"lat":43.713727,"lon":7.260071},"14":{"lat":43.714072,"lon":7.260385},"15":{"lat":43.713715,"lon":7.259868},"16":{"lat":43.714068,"lon":7.260087},"17":{"lat":43.713713,"lon":7.259658},"18":{"lat":43.713957,"lon":7.259879},"2":{"lat":43.713969,"lon":7.261298},"20":{"lat":43.714006,"lon":7.259772},"22":{"lat":43.714083,"lon":7.259521},"24":{"lat":43.713884,"lon":7.259405},"25":{"lat":43.713721,"lon":7.258279},"25 A":{"lat":43.713469,"lon":7.258273},"26":{"lat":43.713845,"lon":7.258142},"27":{"lat":43.713708,"lon":7.257952},"28":{"lat":43.713843,"lon":7.257883},"29":{"lat":43.713419,"lon":7.257861},"3":{"lat":43.713648,"lon":7.261191},"30":{"lat":43.713836,"lon":7.257725},"31":{"lat":43.713695,"lon":7.257674},"32":{"lat":43.713798,"lon":7.257596},"33":{"lat":43.713683,"lon":7.257452},"35":{"lat":43.713676,"lon":7.257296},"4":{"lat":43.713968,"lon":7.261162},"6":{"lat":43.713937,"lon":7.260912},"8":{"lat":43.71413,"lon":7.260881},"8 bis":{"lat":43.71394,"lon":7.260761},"9":{"lat":43.713816,"lon":7.260551}}}
{"id":"060884805","housenumbers":{"12":{"lat":43.713904,"lon":7.2605}}}

[vdct]

j'ai remarqué la même chose dans le format JSON :

Merci pour le signalement, c'était une regression que je viens de corriger, ça devrait profiter aux exports de cette nuit.

Je ne sais pas si cela a un rapport, mais ces rues sont présentes deux fois avec le même id mais des housenumbers différents :

Il n'y a pas de rapport non. Le doublon vient du fait que le paradigme ici rattache les CPs à la rue et non au numero, or dans OSM et dans la BAN les CPs sont rattachés potentiellement au numéro. En l'occurence ici, tous les numeros sauf le 12 proviennent d'OSM, où ils héritent de la liste de CPs trouvés dans OSM aussi. Le 12 provient de la BAN qui lui associe uniquement le CP 06100. Ce CP est conservé jusqu'au bout, d'où une entrée distincte. dans le JSON. Si le 12 existe sur le terrain, alors il aurait sa place dans OSM où ce serait l'occasion d'harmoniser les CPs de cette rue