[OSM-talk-fr] Questions FANTOIR / BANO
Christian Quest
cquest at openstreetmap.fr
Mar 26 Aou 11:45:01 UTC 2014
Ah si seulement... un exemple au hasard (presque):
1403270910XRTE DE LION R 0 00000000000000
00000001987001 001221 LION
1403270678VAV DU GEN DE GAULLE R 0 00000000000000
00000001992309 002021 GAULLE
0910 est devenu 0678 :(
Par contre, FANTOIR contient des informations sur la date d'apparition dans
la base.
Il faudrait plutôt s'orienter je pense sur l'ajout dans FANTOIR
d'informations de regroupement et d'évolution de ce type, une sorte de
colonne "alias" pour indiquer quel est le code FANTOIR actuel qui vient
remplacer cet ancien code toujours actif.
C'est typiquement un truc à mettre en place dans le backend de BANO via le
futur guichet unique !
Le 26 août 2014 13:32, Christophe Merlet <redfox at redfoxcenter.org> a écrit :
> Le 26/08/2014 13:20, Christian Quest a écrit :
> > Le 26 août 2014 11:43, Jean-Christophe Groult <jcgroult at gmail.com
> > <mailto:jcgroult at gmail.com>> a écrit :
> >
> > Bonjour,
> >
> > En corrigeant les rues de la commune d'Hérouville-st-Clair (14200)
> > je suis tombé sur plusieurs problèmes que je ne sais pas résoudre.
> >
> > 1er problème : 1 voie = 2 noms = 2 FANTOIR
> > La D60 qui traverse la commune a longtemps était appelée << route de
> > Lion >>. La mairie l'a renommée en << Avenue du Général de Gaulle >> il
> > y a quelques années, mais le nom d'origine est encore largement
> utilisé.
> > Sur le calque Bano, la route de Lion est indiquée manquante, (depuis
> > j'ai ajouté << Route de Lion >> en old_name, mais je ne pense pas que
> > cela change grand chose).
> > Le problème est que dans le fichier des références FANTOIR les 2
> > noms apparaissent avec chacun sa référence. Donc si j'utilise la
> > référence FANTOIR de la route de Lion, c'est l'avenue du général de
> > Gaulle qui sera en erreur.
> > Est-il possible de mettre 2 références séparées par un point virgule
> > ? La bonne solution est-elle autre chose ?
> >
> > 1403270910XRTE DE LION R 0
> > 00000000000000 00000001987001 001221
> > LION
> > 1403270678VAV DU GEN DE GAULLE R 0
> > 00000000000000 00000001992309 002021
> > GAULLE
> >
> >
> >
> > old_name=* est la meilleure option à mon avis.
> >
> > La pire option est d'ajouter des tags pour compenser un manque côté
> > logiciel (scripts de rapprochement de BANO par exemple).
> > Un old_ref:FR:FANTOIR pourrait être envisagé pour décrire ce genre de
> > cas, c'est à discuter.
>
> Est-ce que les codes FANTOIR sont incrémentaux ? Afin de déterminer quel
> est l'ancien et le nouveau nom ?
>
>
> >
> >
> > 2ème problème : la numérotation par quartier
> > Hérouville a un système d'adressage postal original. La numérotation
> > ne se fait pas par rue mais par quartier. Ce système est en train
> > d'être remplacer par le modèle classique, mais cela prend du temps.
> > Par exemple << 10.14 le Bois >> est une adresse parfaitement valide :
> > << le Bois >> est le nom du quartier >>, << 10 >> est le numéro de porte
> > (dans le sens anglais de << gate >> pas << door >>) et << 14 >> est le
> > numéro d'immeuble au sein de la porte.
> > Si on veut << 10 >> est le nom de la rue, sauf qu'elle n'a pas
> > d'existence propre ni dans le cadastre, ni dans FANTOIR.
> > À la place on a la référence suivante dans FANTOIR:
> >
> > 1403271195GVC QUARTIER DU BOIS R 0
> > 00000000000000 00000001987001 001591
> > BOIS
> >
> > Le problème est qu'il n'y a aucune voie qui s'appelle << quartier du
> > bois >> (il y a bien un << boulevard du bois >> qui fait le tour du
> > quartier mais il a son propre n° FANTOIR)
> > Donc quel est la bonne solution ?
> > Je mets la référence au niveau de la relation qui définit le
> > quartier ? (elle n'existe pas encore mais ce n'est pas un problème)
> > Ou est-ce que je crée une relation associatedStreet avec la liste de
> > toutes les portes et c'est cette relation qui porte la référence ?
> > Une autre idée ?
> >
> >
> > Cas très particulier !
> >
> > On est plutôt dans le cas d'un lieu-dit, d'une résidence. Ce n'est pas
> > encore traité par BANO... là aussi ça mérite réflexion et discussion.
> >
> > En attendant le plus adapté me semble, d'utiliser le addr:place évoqué
> > il y a peu de temps ici même:
> > addr:housenumber=10
> > addr:place=le Bois
> >
> >
> >
> > J'ai encore 2 petites questions supplémentaires.
> > En ajoutant le nom d'une rue composée de plusieurs way, je n'ai mis
> > le nom que sur la relation associatedStreet et pas sur les way, car
> > je trouvais cela redondant.
> > Du coup dans les rendus le nom n'apparait pas du tout.
> > Est-ce normal ?
> > Le rendu ne devrait-il pas utiliser les relations quand les way
> > n'ont pas de nom ?
> >
> >
> > Les relations associatedStreet permet de lier les adresses à la voirie,
> > pas à décrire la voirie.
> > Une description trop relationnelle des données n'est vraiment pas
> > souhaitable car cela complique énormément leur utilisation.
> > Met toi de l'autre côté... et tu verra que c'est un casse tête de
> > retrouver le nom sur les tronçons... il peut même y en avoir plusieurs
> > (rues limitrophes de communes).
> >
> >
> >
> > À l'inverse, de nombreuse pistes cyclables d'Hérouville portent le
> > nom de la rue qu'elles longent (utile pour le guidage par GPS pour
> > les cyclistes) mais apparaissent aussi sur la carte en doublon du
> > nom de la rue pour automobiles.
> > Considère-t-on cela comme normale ?
> > ou est-ce qu'il ne faut pas mettre de nom sur les pistes cyclables
> > (un peu gênant pour les cyclistes) ?
> > ou est-ce qu'il faut créer une relation associatedStreet qui réunit
> > la rue et la piste cyclable sous le même nom, ce qui permet de
> > l'enlever de la piste cyclable ?
> > ou est-ce au calque de ne pas afficher ce nom ?
> > une autre solution ?
> >
> >
> > associatedStreet a été créé à l'origine dans un but d'adressage, pas
> > dans le but de regrouper les éléments composant une rue (voie
> > principale, contre allée, pistes cyclables, voies de bus séparées,
> > trottoirs filaires et surfaciques, etc). En fait, si on modélisait la
> > rue en surfacique tout se qui se trouve à l'intérieur ferait partie de
> > la rue. Par contre sur les intersections ça risque d'être un beau
> > challenge !
> > On n'en est pas encore là (mais on y arrivera un jour ou l'autre).
> >
> > D'ici là... un autre type de relation pourrait servir à cette
> > description car pour l'instant pour trouver la lien entre ces objets il
> > faut le faire sur name=* + proximité géographique ce qui est assez
> > aléatoire en terme de fiabilité et peu efficace en obligeant à mettre
> > des name=* partout. La piste cyclable a-t-elle vraiment un nom ? Pas
> > vraiment... elle passe par la "rue machin", mais elle n'est pas la "rue
> > machin".
> >
> > --
> > Christian Quest - OpenStreetMap France
> >
> >
> > _______________________________________________
> > Talk-fr mailing list
> > Talk-fr at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
> --
> Christophe Merlet (RedFox)
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
--
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140826/3ae7850b/attachment.htm>
Plus d'informations sur la liste de diffusion Talk-fr