[OSM-talk-fr] Codes Fantoir erronés

Philippe Verdy verdy_p at wanadoo.fr
Lun 26 Jan 17:23:07 UTC 2015


pour tester le rapport; j'ai juste essayé sur une correction sur une seule
voie avant de voir si le rapport se mettait à jour.
Mais on dirait qu'il faut encore attendre je ne sais co,bien de temps pour
voie la moindre modification à la liste; sqns doute le délai de remontée de
la base OSM.ORG à la base .FR.
Cette iste ne semble pas longue avec 149 codes détectés encore (148 en
tenant compte de ma modif invisible; ou moins s'il y en a d'autres).
Bref ça peut être fait très rapidement; mais j'attends de voir.

Question: ce rapport tient-il compte des codes FANTOIR formés du code
commune, suivi de 0000 et de la lettre rivoli, utilisé par endroit pour
prolonger voiries privées (essentiellement des voies de service dqns des
entreprises ou centres commerciaux) où l'accès public reste toléré et n'est
pas réellement fermé par des portails ? Ces voies sont nommées par endroit
du même nom que la voirie publique auxquelles elles sont connectées et ont
aussi des noeuds d'adresse associés; mais comme on ne peut as mettre ce
code FANTOIR privé dans la relation associatedStreet pour la voie publique
(qui utilise un vrai code voie non nul), il y a des relations séparées (les
codes FANTOIR ne sont pas tous sur les chemins, parfois il y en a trop
quand ils sont très découpés, c'est la relation associatedStreet qui les
porte; et on les met rarement sur les noeuds; sauf en hqbitat dispersé pour
les lieux-dits et tous petits hameaux autour d'une ferme; les adresses ne
pouvant être atteintes que par une voie privée avec droit de passage pour
les résidents).

Est-ce que ce rapport considère en erreur les codes écrits simplement en
minuscules  (il ne semble pas que la casse soit réellement signifiante pour
la lettre du code rivoli ou les départements de Corse).

Le rapport tient-il compte aussi des codes des communes associées
(différent de celui de la commune de regroupement de la fusion-association;
et qu'on trouve aussi dans les codes des principales divisions cadastrales
avant la lettre et le numéro code de la zone pour les communes rattachées)
? (il semble que oui puisqu'on a dans le FANTOIR un code "type de commune".

Enfin tient-il compte des segments de voies qui ont 2 codes FANTOIR
distincts quand la rue sert de frontière séparant deux communes
(normalement pour ça il faut deux relations, une put chaque commune;
chacune avec son code FANTOIR, même si la rue a le même nom des deux côtés;
ce qui n'est pas non pus toujours le cas, et le même numéro de référence,
ce qui n'est pas toujours le cas non plus pour de nombreux chemins ruraux).

Ces relations distinctes ont de l'intérêt pour répartir les noeuds
d'adresse propre à chaque commune selon le côté, et pour leur assigner
aussi le bon code postal (on a de nombreux cas dans la base où le chemin
mentionne un code postal ou la commune avec un tag addr:* alors que ce
n'est bon que d'un seul côté; les deux relations référencent alors le même
segment de chemin OSM et par souci de clarté entre les deux relations il
serait bon que le nom indiqué pour la relation dans name=* ne soit pas
juste le nom de la rue quand c'est le même des deux côtés, mais qu'il soit
suffixé par le nom de la commune. La relation associatedStreet fait le tri
en indiquant addr:city et addr:postalcode effectif appicable aux noeuds
d'adresse membres).

Dernier problème : de nombreux commerces et entreprises qui sont tagués
dans OSM par uniquement par un noeud doivent se partager le même numéro et
la même rue et même le même nom de batiment (cas des immeubles de bureaux).
Comment mentionner leur adresse de "contact" autrement que par des tags
addr:* qui pourtant mentionnent une adresse différente de celle de la
position physique du noeud ? Ne faudrait-il pas alors utiliser
"contact:*=*" au lieu de "addr:*=*" ?

Ce qui permet alors de placer plusieurs noeuds distincts groupés autour du
noeud d'adresse principal; même si pour chacun d'eux il faut aussi les
mêmes valeurs "addr:*" pour pouvoir tous les associer à la même rue
"associatedStreet" relative aux adresses physiques, plus des tags diférents
pour les noms des établissements, et la typologie des services qu'ils
rendent.

Mais alors doit-on inclure ces noeuds groupés dans la relation
associatedStreet pour qu'ils restent associés à la bonne rue physique et
que le rapprochement BANO ne tente pas de les grouper selon les adresses de
contact indiquées si elles le sont par les tags "addr;*" et non contact:" ?
(note: les adresses de contact sont plus libres que les rues physiques du
FANTOIR, puisqu'on y trouvera notamment des CEDEX, des adresses en poste
restante ou boites postales, ou l'adresse d'un autre établissement ou même
d'une autre société gérant le courrier telles que des sociétés de
domiciliation et de secrétariat; ou des assos d'entreprises, ou bien encore
l'adresse personnelle de son gérant ou administrateur légal; le nom du
contact étant alors différent du nom du lieu à l'emplacement du noeud ou
polygone physique ainsi marqué).


Le 26 janvier 2015 15:49, Vincent de Château-Thierry <osm.vdct at free.fr> a
écrit :

>
> > De: "Frédéric Rodrigo" <fred.rodrigo at gmail.com>
> >
> > Pas tout a fait. Les codes FANTOIR ne sont rendu public via le
> > FANTOIR
> > annuellement, mais les communes le reçoivent avant et peuvent le
> > diffuser.
>
> Oui il ne faut pas l'exclure. Mais le sondage que j'ai pu faire sur les
> ~150 codes remontés jusque là montre une majorité de cas où la différence
> entre un code connu de Fantoir et le code connu d'OSM est sur 1 caractère :
> un 8 compris comme un 3 ou le contraire, etc. Donc plutôt sur des codes pas
> forcément tous neufs, et entrés à la main en relisant le calque BANO, par
> ex.
> Après, si on ne parvient pas à tout corriger, avec le Fantoir actuel
> (millésime 2014), ça n'est pas un souci. Ça donnera l'étendue des codes
> dont tu parles, plus récents.
>
> vincent
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150126/3136e288/attachment.html>


Plus d'informations sur la liste de diffusion Talk-fr