Re: [OSM-talk-fr] Du Fantoir
Allez, un petit travail de comparaison : Fantoir sur Orange : 1000 objets dont : - 711 voies - 112 lotissements ou résidences - 118 lieux-dits - 7 parkings - 5 zones d'activité - 9 divers (canal, équipement, limite commune, ...) Il y a déjà 68 doublons. Notre référentiel communal comprend - 792 voies contre 679 correspondances avec la DGFIP. Il manque donc dans le fantoir au moins 113 voies. - 241 lotissements ou résidences - 30 parkings - 7 zones d'activité Donc, je confirme que le fichier fantoir est une bonne base de départ pour la voirie. Mais il y a un gros travail de vérification à faire et pour le reste, il faut faire très attention. Par contre, est-il envisageable, à terme, que l'on puisse collaborer avec la DGFiP pour améliorer leur Fantoir ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Du-Fantoir-tp5778578p5793197.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Tu es très bien placé pour répondre justement à une question que je me pose. Ce n'est pas justement les communes qui donnent l'information à la DGFip pour tenir le Fantoir à jour ? Le 15 janvier 2014 11:52, Tony Emery tony.em...@yahoo.fr a écrit : Allez, un petit travail de comparaison : Fantoir sur Orange : 1000 objets dont : - 711 voies - 112 lotissements ou résidences - 118 lieux-dits - 7 parkings - 5 zones d'activité - 9 divers (canal, équipement, limite commune, ...) Il y a déjà 68 doublons. Notre référentiel communal comprend - 792 voies contre 679 correspondances avec la DGFIP. Il manque donc dans le fantoir au moins 113 voies. - 241 lotissements ou résidences - 30 parkings - 7 zones d'activité Donc, je confirme que le fichier fantoir est une bonne base de départ pour la voirie. Mais il y a un gros travail de vérification à faire et pour le reste, il faut faire très attention. Par contre, est-il envisageable, à terme, que l'on puisse collaborer avec la DGFiP pour améliorer leur Fantoir ? - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Du-Fantoir-tp5778578p5793197.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
J'ai également compléter les ways avec ref:FR:FANTOIR en 4 caractères vers 10 et passé les les rations ref:FR:FANTOIR de 11 à 10. Ça doit faire environ 10 000 modifications en tout. Mais là je viens de tomber sur des ways avec ref:FR:fantoir sur 4 et ref:FR:INSEE. Je me demande si ce n'est pas finalement plus intelligent d'avoir le ref insee a part. Votre avis ? Frédéric. Le 7 janvier 2014 22:12, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 03/01/2014 19:04, Frédéric Rodrigo a écrit : Le 01/01/2014 11:07, Frédéric Rodrigo a écrit : Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo,mais probablement ceux de Toulouse)) Le nouvelles stats donnent : 58 009 ref:FR:fantoir (dont 55 755 nœuds) 23 959 ref:FR:FANTOIR (dont 14 218 relations, 6 121 ways et 3 620 nœuds) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Je viens de les passer à ref:FR:FANTOIR, les codefantoir étaient en très grande partie déjà migré. Prochaine étapes aligner les codes sur 11 caractères : - dans l'outil d'aide à l'intégration Voilà toutes les données disponibles à l'intégration avec une ref fantoir sont au format sur 10 caractères (sauf si la ref n'a pas de correspondance dans le fichier fantoir, c'est la valeur d'origine). Au passage les données sur Bordeaux ont été mise à jour (+300 rues en 6 mois). - dans la base Reste à faire ça ! Il faut reverse géocoder les adresses pour identifier la commune de l'adresse, c'est d'un pratique... Je viens d'en faire un premier lot, sur 4200 relations avec le tag ref:FR:FANTOIR (en majuscule) et avec un code sur 4 caractères : http://www.openstreetmap.org/changeset/19870698 Comment j'ai procédé : - reverse géocodage d'un point du way de la relation associatedStreet, mais la qualité du résultat ne garanti pas d'avoir la bonne commune à tous les coups. Sur mes tests : 8 erreurs sur 500. - validation que pour la commune reverse-géocodé le code fantoir (sur 4) donne une rue dont le dernier mot (concept du fantoir) est le même dans le fantoir et dans osm. 100 rues sur 4200 non pas matché sur le dernier mot. - mise a jour des codes si la version de la relation n'a pas changé entre temps et upload. Allez, plus que 75000... Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 15/01/2014 14:12, Frédéric Rodrigo a écrit : J'ai également compléter les ways avec ref:FR:FANTOIR en 4 caractères vers 10 et passé les les rations ref:FR:FANTOIR de 11 à 10. Ça doit faire environ 10 000 modifications en tout. Mais là je viens de tomber sur des ways avec ref:FR:fantoir sur 4 et ref:FR:INSEE. Je me demande si ce n'est pas finalement plus intelligent d'avoir le ref insee a part. Ben le ref:INSEE sur la relation communale et le ref:FANTOIR au plus court sur les éléments concerné. Lors des fusion/défusion de communes, comment réagissent les ref:FANTOIR ? Sont ils tous renumérotés ? Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
L'unicité d'un ref* le rend bien plus facile à exploiter et cohérent. Pensez aussi aux voie en bord de commune... On n'avait pas déjà parlé de tout ça et trouvé un consensus ? Le 15 janvier 2014 14:44, Christophe Merlet red...@redfoxcenter.org a écrit : Le 15/01/2014 14:12, Frédéric Rodrigo a écrit : J'ai également compléter les ways avec ref:FR:FANTOIR en 4 caractères vers 10 et passé les les rations ref:FR:FANTOIR de 11 à 10. Ça doit faire environ 10 000 modifications en tout. Mais là je viens de tomber sur des ways avec ref:FR:fantoir sur 4 et ref:FR:INSEE. Je me demande si ce n'est pas finalement plus intelligent d'avoir le ref insee a part. Ben le ref:INSEE sur la relation communale et le ref:FANTOIR au plus court sur les éléments concerné. Lors des fusion/défusion de communes, comment réagissent les ref:FANTOIR ? Sont ils tous renumérotés ? Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/15 Christian Quest cqu...@openstreetmap.fr: On n'avait pas déjà parlé de tout ça et trouvé un consensus ? Je ne crois pas que l'import des codes fantoir ait jamais été vraiment discuté, ni fait l'objet d'un consensus. Ce qui est vrai, c'est qu'on était d'accord sur le fait que c'est une source utile pour comparer avec les voies déjà présentes dans OSM. Mais ton outil prouve aussi qu'on peut très bien le faire sans importer les codes FANTOIR dans OSM. Personnellement, je m'en fous un peu même si je trouve que ça pollue un peu la base (c'est un tag de plus que 99.99% des contributeurs ne comprennent pas). J'attend de voir une application concrète. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Il faut quand même savoir que c'est un peu le bazar dans les fichiers Fantoir. Il y a un peu à boire et à manger (voies, lotissements, résidences, quartier, parking, zone d'activité, square, ...). De plus, il y a beaucoup de doublons dans les voies. Du coup, une même voie peu être recensée avec plusieurs identifiants sous différentes orthographe (ou pas). Exemple :ANC RTE D ORANGE A JONQUIE . Je l'ai 3 fois dans la base, donc 3 codes rivoli A176, A881, 0086. Alors c'est sûr que c'est mieux que rien. Mais il faut être très vigilent et essayer d'abord de nettoyer le fichier Fantoir avant de l'utiliser. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Du-Fantoir-tp5778578p5792468.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
A confirmer, mais il m'a semblé que les fichiers FANTOIR étaient extrait du cadastre (données du SIG du cadastre, si il existe bien). J'ai retrouvé dans le FANTOIR de ma commune des résidus de rues disparues mais dont j'ai retrouvé des numéros qui sont encore visibles sur le cadastre. C'est pas très clair... mais moi je me comprends ! A+ Le 10 janvier 2014 10:27, Tony Emery tony.em...@yahoo.fr a écrit : Il faut quand même savoir que c'est un peu le bazar dans les fichiers Fantoir. Il y a un peu à boire et à manger (voies, lotissements, résidences, quartier, parking, zone d'activité, square, ...). De plus, il y a beaucoup de doublons dans les voies. Du coup, une même voie peu être recensée avec plusieurs identifiants sous différentes orthographe (ou pas). Exemple :ANC RTE D ORANGE A JONQUIE . Je l'ai 3 fois dans la base, donc 3 codes rivoli A176, A881, 0086. Alors c'est sûr que c'est mieux que rien. Mais il faut être très vigilent et essayer d'abord de nettoyer le fichier Fantoir avant de l'utiliser. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Du-Fantoir-tp5778578p5792468.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Attention aussi à bien lire le descriptif de FANTOIR. Il y a un champs qui indique si une voie a été supprimée ou pas. Le 10 janvier 2014 15:02, Marc SIBERT m...@sibert.fr a écrit : A confirmer, mais il m'a semblé que les fichiers FANTOIR étaient extrait du cadastre (données du SIG du cadastre, si il existe bien). J'ai retrouvé dans le FANTOIR de ma commune des résidus de rues disparues mais dont j'ai retrouvé des numéros qui sont encore visibles sur le cadastre. C'est pas très clair... mais moi je me comprends ! A+ Le 10 janvier 2014 10:27, Tony Emery tony.em...@yahoo.fr a écrit : Il faut quand même savoir que c'est un peu le bazar dans les fichiers Fantoir. Il y a un peu à boire et à manger (voies, lotissements, résidences, quartier, parking, zone d'activité, square, ...). De plus, il y a beaucoup de doublons dans les voies. Du coup, une même voie peu être recensée avec plusieurs identifiants sous différentes orthographe (ou pas). Exemple :ANC RTE D ORANGE A JONQUIE . Je l'ai 3 fois dans la base, donc 3 codes rivoli A176, A881, 0086. Alors c'est sûr que c'est mieux que rien. Mais il faut être très vigilent et essayer d'abord de nettoyer le fichier Fantoir avant de l'utiliser. - Tony EMERY Administrateur OpenStreetMap.fr Mandataire Grand Sud-Est Géomaticien chef de projets -- View this message in context: http://gis.19327.n5.nabble.com/Du-Fantoir-tp5778578p5792468.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
D'un point de bue SGBD, la relation ssociatedStreet ne sert essentiellement qu'aux adresses. Si la rue est partagée en deux entre deux communes ce sont bien deux relations avec des ensembles d'adresses sur deux communes dfférentes. Bref deux relations c'est parfaitement justifié, et chaque partie peut avoir son code FANTOIR. LA relation associatedStreet de teoute façon ne représente *pas* toute la rue, seulement un sous-ensemble consitué d'un parcours (qui évite dans OSM souvent de réutiliser la frontière communale alors que cette frontière passe bel et bien au milieu de la rue !!! Si on fait un codage géométrique pur, alors il fait remettre les rues sur la frontière communale, même si son axe de circulation n'est pas exactement la frontière. Et je ne vois strictement rien contre, dans le cas des rues tracées avec plusieurs axes parallèles, à ce que la relation associatedStreet contienne en membre plusieurs axes dnas les tronçons propres à chaque commune. C'est parfaitement cohérent... Logiquement ce n'est pas parce que les 2 rues ont les mêmes noms entre deux communes et son mitoyennes que ce ne sont pas deux rues distinctes. Seul problème: si un chemin de la rue est partagé entre 2 relations qui référence le même tronçon (y compris quand le tronçon est en fait tracé sur le territoire de l'autre commune car on n'a pas représenté toute la largeur mais seulement l'axe central), ce tronçon sera membre de 2 relations. Si on veut représenter la rue entière en tant que chemin unique pour la circulaton (et non pour les adresses), on a un autre type de relation pour ça : route (qui représente un itinéraire complet). la relation associatedStreet ne sert en effet strictement à rien pour les calculs d'itinéraires, au contraire des relations route. Un même rue d'ailleurs peut faire partie aussi de plusieurs routes (itinéraires) selon - le moyen de transport (en voiture, à pied, à vélo, bus, trams...) et le sens du parcours (si pour la topologie du parcours les segments de l'itinéraires ne sont pas tous bidirectionnels ni tous unidirectionnels, - il est plus pratique de créer deux relations route dictinctes (avec les chemins membres tous en sens forward sur les voies à sens unique, et en forward dans une route, et backward dans l'autre. - et de réunir les routes de chaque sens (ou les variantes d'itinéraires d'une même ligne) dans une relation route_master Si on veut ensuite représenter la surface de la rue avec des contours, on a intérêt à le faire commune par commune et mettre ces contours dans des membres de rôle outer (voire inner parfois pour les ilots). Mais pour l'instant on ne le fait car on se contente encore de représenter les rues en mode filaire (comme les rivières, qui ont aussi une représentation surfacique avec le type water=riverbank dans des relations de type=multipolygone insérées ensuite dans la relation de la rivière en tant que membre unique de rôle riberbank contenant tous les polygones ou le multipolygone de surfaces en eau) On peut donc prendre le schéma hydrographique en modèle où les deux cohabitent (et les rivières ont aussi leurs itinéraires dans des relations séparés pour le transport fluvial dans des relations type=route à part, ces type=route pouvant eux aussi reprendre des segments communs de chemins de la représentation filaire). Le 8 janvier 2014 13:28, HELFER Denis denis.hel...@rff.fr a écrit : C’est toujours la question sempiternelle : faut-il tout décrire y compris les relations spatiales (was « is_in »)? D’un point de vue sgbd, plusieurs adresses mais une seule rue. Nous n’avons jamais indiqué que telle rue appartient à telle commune (il faudrait une relation de l’ensemble des voies de la commune). On se base sur la relations spatiale, non ? Le vrai problème, c’est hétérogénéité des méthodes et, donc, la réutilisation des données pour tout type de public (du lambda à l’expert). *De :* Frédéric Rodrigo [mailto:fred.rodr...@gmail.com] *Envoyé :* mercredi 8 janvier 2014 13:23 *À :* Discussions sur OSM en français *Objet :* Re: [OSM-talk-fr] Du Fantoir Le problème c'est que du coup il est moins facile déterminer dans qu'elle commune est la rue ! Le 8 janvier 2014 13:17, HELFER Denis denis.hel...@rff.fr a écrit : Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que les numéros sont cohérents ; il n'y a pas de doublons sinon la question eût été résolue. -Message d'origine- De : Tetsuo Shima [mailto:tets...@gmail.com] Envoyé : mercredi 8 janvier 2014 13:04 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Du Fantoir C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux communes. Parfois le nom change un tout petit peu, genre rue de machin chose, puis route de machin chose, mais souvent le nom reste, seul la numérotation change. Et effectivement a chaque fois je fais deux relations, de toutes façon sinon les numéro se chevauche et on a des doublons. Le 8 janvier 2014 12
Re: [OSM-talk-fr] Du Fantoir
Bonjour, On fait comment quand une même rue possède 2 ref Fantoir différents? Romain Le 7 janvier 2014 22:12, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Un exemple ? Une rue commune a deux communes :-) ? -- Marc m...@sibert.fr Le 8 janv. 2014 11:56, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, On fait comment quand une même rue possède 2 ref Fantoir différents? Romain Le 7 janvier 2014 22:12, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 8 janvier 2014 12:14, Marc SIBERT m...@sibert.fr a écrit : Un exemple ? Une rue commune a deux communes :-) ? cf. http://addr.openstreetmap.fr/nancy/?zoom=19lat=48.68871lon=6.15494layers=BTitem=100 Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même nom de rue. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
La même chose entre Zillisheim et Flaxlanden ici : http://tile.openstreetmap.fr/?zoom=19lat=47.69681lon=7.30695layers=B000FF J'ai pris le parti d'une seule relation. Denis De : Romain MEHUT [mailto:romain.me...@gmail.com] Envoyé : mercredi 8 janvier 2014 12:23 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Du Fantoir Le 8 janvier 2014 12:14, Marc SIBERT m...@sibert.frmailto:m...@sibert.fr a écrit : Un exemple ? Une rue commune a deux communes :-) ? cf. http://addr.openstreetmap.fr/nancy/?zoom=19lat=48.68871lon=6.15494layers=BTitem=100 Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même nom de rue. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Les adresses d'une partie de la rue doivent correspondre à une commune et le reste à l'autre commune, non ? Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Le 8 janvier 2014 12:26, HELFER Denis denis.hel...@rff.fr a écrit : La même chose entre Zillisheim et Flaxlanden ici : http://tile.openstreetmap.fr/?zoom=19lat=47.69681lon=7.30695layers=B000FF J’ai pris le parti d’une seule relation. Denis *De :* Romain MEHUT [mailto:romain.me...@gmail.com] *Envoyé :* mercredi 8 janvier 2014 12:23 *À :* Discussions sur OSM en français *Objet :* Re: [OSM-talk-fr] Du Fantoir Le 8 janvier 2014 12:14, Marc SIBERT m...@sibert.fr a écrit : Un exemple ? Une rue commune a deux communes :-) ? cf. http://addr.openstreetmap.fr/nancy/?zoom=19lat=48.68871lon=6.15494layers=BTitem=100 Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même nom de rue. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit : Les adresses d'une partie de la rue doivent correspondre à une commune et le reste à l'autre commune, non ? Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Logique, oui c'est sûr. Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux communes. Parfois le nom change un tout petit peu, genre rue de machin chose, puis route de machin chose, mais souvent le nom reste, seul la numérotation change. Et effectivement a chaque fois je fais deux relations, de toutes façon sinon les numéro se chevauche et on a des doublons. Le 8 janvier 2014 12:43, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit : Les adresses d'une partie de la rue doivent correspondre à une commune et le reste à l'autre commune, non ? Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Logique, oui c'est sûr. Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que les numéros sont cohérents ; il n'y a pas de doublons sinon la question eût été résolue. -Message d'origine- De : Tetsuo Shima [mailto:tets...@gmail.com] Envoyé : mercredi 8 janvier 2014 13:04 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Du Fantoir C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux communes. Parfois le nom change un tout petit peu, genre rue de machin chose, puis route de machin chose, mais souvent le nom reste, seul la numérotation change. Et effectivement a chaque fois je fais deux relations, de toutes façon sinon les numéro se chevauche et on a des doublons. Le 8 janvier 2014 12:43, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit : Les adresses d'une partie de la rue doivent correspondre à une commune et le reste à l'autre commune, non ? Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Logique, oui c'est sûr. Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le problème c'est que du coup il est moins facile déterminer dans qu'elle commune est la rue ! Le 8 janvier 2014 13:17, HELFER Denis denis.hel...@rff.fr a écrit : Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que les numéros sont cohérents ; il n'y a pas de doublons sinon la question eût été résolue. -Message d'origine- De : Tetsuo Shima [mailto:tets...@gmail.com] Envoyé : mercredi 8 janvier 2014 13:04 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Du Fantoir C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux communes. Parfois le nom change un tout petit peu, genre rue de machin chose, puis route de machin chose, mais souvent le nom reste, seul la numérotation change. Et effectivement a chaque fois je fais deux relations, de toutes façon sinon les numéro se chevauche et on a des doublons. Le 8 janvier 2014 12:43, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit : Les adresses d'une partie de la rue doivent correspondre à une commune et le reste à l'autre commune, non ? Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Logique, oui c'est sûr. Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
C’est toujours la question sempiternelle : faut-il tout décrire y compris les relations spatiales (was « is_in »)? D’un point de vue sgbd, plusieurs adresses mais une seule rue. Nous n’avons jamais indiqué que telle rue appartient à telle commune (il faudrait une relation de l’ensemble des voies de la commune). On se base sur la relations spatiale, non ? Le vrai problème, c’est hétérogénéité des méthodes et, donc, la réutilisation des données pour tout type de public (du lambda à l’expert). De : Frédéric Rodrigo [mailto:fred.rodr...@gmail.com] Envoyé : mercredi 8 janvier 2014 13:23 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Du Fantoir Le problème c'est que du coup il est moins facile déterminer dans qu'elle commune est la rue ! Le 8 janvier 2014 13:17, HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr a écrit : Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que les numéros sont cohérents ; il n'y a pas de doublons sinon la question eût été résolue. -Message d'origine- De : Tetsuo Shima [mailto:tets...@gmail.commailto:tets...@gmail.com] Envoyé : mercredi 8 janvier 2014 13:04 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Du Fantoir C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux communes. Parfois le nom change un tout petit peu, genre rue de machin chose, puis route de machin chose, mais souvent le nom reste, seul la numérotation change. Et effectivement a chaque fois je fais deux relations, de toutes façon sinon les numéro se chevauche et on a des doublons. Le 8 janvier 2014 12:43, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.netmailto:nicolas_openstreetmap@dumoulin63.net a écrit : Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit : Les adresses d'une partie de la rue doivent correspondre à une commune et le reste à l'autre commune, non ? Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Logique, oui c'est sûr. Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/8 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net: Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? Euh, au risque de me répéter, je pense que mettre le code fantoir sur une relation associatedStreet est, au final, une très, très mauvaise idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne faisais qu'officialiser ce qui était dit ici même). Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans parler des rues sans adresses). Ca veut dire que tous les segments de rues qui ne sont pas dans la relation n'auront pas de code fantoir ! Soit vous forcez tout le monde à mettre tous les segments de la rue dans la relation (ce qui serait en quelque sorte une redéfinition de la relation qui n'était pas faite pour ça à l'origine), soit vous laissez le code sur les ways. Je croyais que le code fantoir était lié aux voies, pas aux adresses. Et là, on mélange un peu les serviettes et les torchons. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
On le met sur la relation quand on a une relation, ça factorise. Mais je ne vois de problème à le mettre sur des ways. associatedStreet c'est plus qu'une relation pour les adresses, ça regroupe les composantes d'une rue. Le 8 janvier 2014 13:32, Pieren pier...@gmail.com a écrit : 2014/1/8 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net: Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? Euh, au risque de me répéter, je pense que mettre le code fantoir sur une relation associatedStreet est, au final, une très, très mauvaise idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne faisais qu'officialiser ce qui était dit ici même). Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans parler des rues sans adresses). Ca veut dire que tous les segments de rues qui ne sont pas dans la relation n'auront pas de code fantoir ! Soit vous forcez tout le monde à mettre tous les segments de la rue dans la relation (ce qui serait en quelque sorte une redéfinition de la relation qui n'était pas faite pour ça à l'origine), soit vous laissez le code sur les ways. Je croyais que le code fantoir était lié aux voies, pas aux adresses. Et là, on mélange un peu les serviettes et les torchons. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Fantoir ne fait pas que les voie, il fait aussi les lieux dits et il y en a beaucoup, ce qui explique notament les statistique parfois bizarre de la couche QA, ou des villages ont toutes les rues taggé correctement et ou il est affiché seulement 50%. Pour le probleme des voie adresse vs segment de voie ne serait il pas envisageable d'imposer une relation associated street par voie ... et par lieu dit. Relation qui matérialiserait la voie logique elle meme, et pas juste les segment physique que sont les way. On pourrait meme alors virer les name des way ... et se baser sur la relation pour dessiner les nom des voie. Bon je sais c'est extreme, mais c'est plus logique que la succession de segment avec le nom recopié a l'infini sur chaque petit bout. Le 8 janvier 2014 13:32, Pieren pier...@gmail.com a écrit : 2014/1/8 Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net: Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ? Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant de gérer ça simplement sans faire d'erreur ? Euh, au risque de me répéter, je pense que mettre le code fantoir sur une relation associatedStreet est, au final, une très, très mauvaise idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne faisais qu'officialiser ce qui était dit ici même). Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans parler des rues sans adresses). Ca veut dire que tous les segments de rues qui ne sont pas dans la relation n'auront pas de code fantoir ! Soit vous forcez tout le monde à mettre tous les segments de la rue dans la relation (ce qui serait en quelque sorte une redéfinition de la relation qui n'était pas faite pour ça à l'origine), soit vous laissez le code sur les ways. Je croyais que le code fantoir était lié aux voies, pas aux adresses. Et là, on mélange un peu les serviettes et les torchons. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Bonjour, De : Pieren Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans parler des rues sans adresses). Ca veut dire que tous les segments de rues qui ne sont pas dans la relation n'auront pas de code fantoir ! Soit vous forcez tout le monde à mettre tous les segments de la rue dans la relation (ce qui serait en quelque sorte une redéfinition de la relation qui n'était pas faite pour ça à l'origine), soit vous laissez le code sur les ways. Je croyais que le code fantoir était lié aux voies, pas aux adresses. Et là, on mélange un peu les serviettes et les torchons. Mettre tous les segments dans la relation apporterait un intérêt à cette construction un peu informe qu'est la relation associatedStreet. Avec une incitation claire à intégrer tous les ways, on gagnerait en homogénéité, et on pourrait envisager des usages de façon plus fiable, sans avoir à se demander où est le morceau de rue inclus dans la relation, ni quelle proportion de la géométrie complète de la rue il couvre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le mercredi 8 janvier 2014 13:47:08 Tetsuo Shima a écrit : Fantoir ne fait pas que les voie, il fait aussi les lieux dits et il y en a beaucoup, ce qui explique notament les statistique parfois bizarre de la couche QA, ou des villages ont toutes les rues taggé correctement et ou il est affiché seulement 50%. J'ai jeté un œuil sur ma commune et apparemment Christian n'inclue pas les lieux-dits dans les stats, uniquement les voies (type de voie == 1 à la colonne 109). -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 8 janvier 2014 13:47, Tetsuo Shima tets...@gmail.com a écrit : Fantoir ne fait pas que les voie, il fait aussi les lieux dits et il y en a beaucoup, ce qui explique notament les statistique parfois bizarre de la couche QA, ou des villages ont toutes les rues taggé correctement et ou il est affiché seulement 50%. Pourtant, il me semble que ma requête ne prend en compte que les voies, pas les pseudo-voies ni les lieux dits. C'est de toute façon un premier jet, qu'il faut affiner en regardant dans le détail sur quelques communes où on ne s'explique pas les différences. Pour le probleme des voie adresse vs segment de voie ne serait il pas envisageable d'imposer une relation associated street par voie ... et par lieu dit. Relation qui matérialiserait la voie logique elle meme, et pas juste les segment physique que sont les way. On pourrait meme alors virer les name des way ... et se baser sur la relation pour dessiner les nom des voie. Bon je sais c'est extreme, mais c'est plus logique que la succession de segment avec le nom recopié a l'infini sur chaque petit bout. Dans un premier temps, ça va poser un problème à la majorité des rendus utilisant la chaine classique osm2pgsl postgis mapnik Mais dans un deuxième temps, ça permettrait aussi de ne rendre le nom que sur la voie de plus grande importance, je pense aux rues avec des contre allées où on trouve le nom un peu partout ce qui n'apporte par vraiment d'information et réduit la lisibilité globale. Il ne faut oublier non plus que les données OSM ne servent pas qu'au rendu de cartes. Le 8 janvier 2014 13:32, Pieren pier...@gmail.com a écrit : Euh, au risque de me répéter, je pense que mettre le code fantoir sur une relation associatedStreet est, au final, une très, très mauvaise idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne faisais qu'officialiser ce qui était dit ici même). Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans parler des rues sans adresses). Ca veut dire que tous les segments de rues qui ne sont pas dans la relation n'auront pas de code fantoir ! Soit vous forcez tout le monde à mettre tous les segments de la rue dans la relation (ce qui serait en quelque sorte une redéfinition de la relation qui n'était pas faite pour ça à l'origine), soit vous laissez le code sur les ways. Je croyais que le code fantoir était lié aux voies, pas aux adresses. Et là, on mélange un peu les serviettes et les torchons. Ce que nous connaissons de FANTOIR ne contient effectivement que les voies, mais je pense que son usage interne est d'être une base aux adresses des propriétés (parcelles, bâti) et ainsi que des contribuables, non ? De toute façon, les noms de voies et de lieux-dits servent bien à la base à fixer des adresses ou alors un truc m'échappe dans ton message. Mettre le ref:FR:FANTOIR sur la relation (quand elle existe) évite de le répéter sur chaque tronçon de voie et aussi de retrouver facilement toutes adresses qui y sont liées. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/8 Christian Quest cqu...@openstreetmap.fr: Mettre le ref:FR:FANTOIR sur la relation (quand elle existe) évite de le répéter sur chaque tronçon de voie et aussi de retrouver facilement toutes adresses qui y sont liées. Encore une fois, code fantoir et adresses sont deux choses différentes. Pour éviter de dupliquer le code fantoir, vous allongez aussi la liste des membres 'street'. Où est le gain ? Quand je pense qu'on me disait que l'impact du tag source=cadastre sur la base était au final assez négligeable. L'argument de dire qu'on va économiser quelques octets ici est assez faible. Je vais redonner la définition d'associatedStreet : provide a connection between housenumber and street.. Rien d'autre. Si vous migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les autres ? Restons cohérents. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/8 Christian Quest cqu...@openstreetmap.fr: Ce que nous connaissons de FANTOIR ne contient effectivement que les voies, mais je pense que son usage interne est d'être une base aux adresses des propriétés (parcelles, bâti) et ainsi que des contribuables, non ? Si le code fantoir n'a qu'un usage interne, inutile de l'importer dans OSM. Si on pense qu'il peut être utile à d'autres choses, il faut seulement le considérer comme un attribut de la voie, un alias, le genre de chose qu'on a toujours mis sur le highway et dupliqué à l'envie lorsque celui-ci était fragmenté. Une chose qui ne gênait personne jusqu'ici. Je sais bien qu'on est ici dans la classique confrontation entre ceux qui veulent tout migrer dans des relations et ceux qui n'aiment pas les relations. Mais au-delà des arguments habituels, il faut comprendre que placer un attribut de la voie comme l'est le code fantoir sur la relation associatedStreet serait un changement dans la définition de cette relation et un changement dans le traitement habituel des attributs liés à la voie elle-même. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Encore une fois, code fantoir et adresses sont deux choses différentes. A bon? Je comprends pas bien. Le code Fantoir est effectivement un alias des nom de voie, nom de voie qui sont les adresses. Le numéro n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir comme adresse un voie, sans avoir de numéro, ou pas de voie et juste une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro. Le code FANTOIR c'est justement un élément d'adresse et pas un élément de voirie. L'objectif de FANTOIR ce justement d'établir des liste d'adresse pour pouvoir rapprocher chaque résident entre IRPP et taxe locale, de maniere a éviter les adresse fictive, ou multiple, de les trou dans l'impot foncier et taxe d'habitation etc. Pour cela il faut pour identifier de maniere unique les adresse. Pour les commune c'est facile on a déjà un code INSEE, pour les voies on a donc créée RIVOLI/FANTOIR. Les numéros de rue eux sont naturellement un index a eux seul, meme s'il y a encore des ambiguité de ce coté entre le bis ter, A,B,C ou les communes sans numéros de rue... Pour éviter de dupliquer le code fantoir, vous allongez aussi la liste des membres 'street'. Où est le gain ? C'est un probleme logique. D'un coté on a des segment physique de voirie, d'un autre coté on a des élément logique de voirie. Il est intéressant de modéliser ces élément logique, nom, référence, code Fantoir, dans un modele a coté du modele physique justement parce que la réalité logique d'une voie, et assez éloigné de la réalité logique des segment membre en question. Quand je pense qu'on me disait que l'impact du tag source=cadastre sur la base était au final assez négligeable. L'argument de dire qu'on va économiser quelques octets ici est assez faible. Ce n'est pas un probleme de poids, c'est un probleme de modele de donnée. On a le meme probleme avec le reférence de voie route antionel numéro machin, département truc. Pour bien faire il faudrait que les segment d'une meme voie au sens de sa référence soit regroupé dans un collection. Reconstruire a posterio la D951 a partir des infos actuel de la base c'est pas évident évident avec les doublons de voie différente ou de meme voie portant la meme référence. Tu me répondras qu'on a qu'a filtrer géographiquement ... mais je vois arriver gros comme une maison des exemples ou cette reconstruction a posteriori va merder. On le fait bien pour les riviere, les voie de chemin de fer, les voies cyclable, j'ai du mal a comprendre pourquoi ca ne se fait pas naturellement pour les voie routière. Je vais redonner la définition d'associatedStreet : provide a connection between housenumber and street.. Rien d'autre. Si vous migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les autres ? Restons cohérents. oneway et access sont souvent propre a chaque segments?! seul name et ref est commun a chacune des voie logique. Il faudrait donc deux collections. Une des nom au sens de l'adresse qui irait naturellement dans associatedstreet, et une des référence DDE qui irait dans une relation associatedroad ou un sous type de associated street. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 8 janvier 2014 14:18, Pieren pier...@gmail.com a écrit : 2014/1/8 Christian Quest cqu...@openstreetmap.fr: Mettre le ref:FR:FANTOIR sur la relation (quand elle existe) évite de le répéter sur chaque tronçon de voie et aussi de retrouver facilement toutes adresses qui y sont liées. Encore une fois, code fantoir et adresses sont deux choses différentes. Pour éviter de dupliquer le code fantoir, vous allongez aussi la liste des membres 'street'. Où est le gain ? Quand je pense qu'on me disait que l'impact du tag source=cadastre sur la base était au final assez négligeable. L'argument de dire qu'on va économiser quelques octets ici est assez faible. Je vais redonner la définition d'associatedStreet : provide a connection between housenumber and street.. Rien d'autre. Si vous migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les autres ? Restons cohérents. Pieren Je recherche en fait une cohérence avec le principe one feature, one OSM element*. 1 code FANTOIR à faire correspondre à 1 objet OSM et le plus approprié pour ça m'a l'air d'être la relation associatedStreet. * http://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/8 Tetsuo Shima tets...@gmail.com: A bon? Je comprends pas bien. Le code Fantoir est effectivement un alias des nom de voie, nom de voie qui sont les adresses. Le numéro n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir comme adresse un voie, sans avoir de numéro, ou pas de voie et juste une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro. Il y a un problème de définition ;-) Le code fantoir identifie la voie. Le nom de la voie est effectivement un élément constitutif d'une adresse - comme le nom de la ville ou le code postal - mais pas le code fantoir. Cet attribut n'est peut-être limité qu'à ce rôle dans l'administration fiscale. Mais dans OMS, ça devient un attribut de la voie, pour un usage plus général et pas seulement une composante de l'adresse. Il y a aussi plein de voies sans adresses, ni habitations mais qui doivent quand même avoir un code fantoir, non ? Le descriptif du fichier FANTOIR donne comme définition: Le fichier des voies et lieux-dits ou fichier FANTOIR recense par commune: - les voies - les lieux-dits - les ensembles immobiliers - les pseudo-voies Il est constitué de l'ensemble des références topographiques qu'elles soient annulées ou actives A aucun moment, ça ne parle d'adresse. Il faudrait donc deux collections. Une des nom au sens de l'adresse qui irait naturellement dans associatedstreet, et une des référence DDE qui irait dans une relation associatedroad ou un sous type de associated street. Ouh la, une relation de plus ;-) Une relation par attribut finalement, ou presque ;-) Je suis sûr qu'osm2pgsql pourrait y retrouver ses petits mais ça m'étonnerait que les contributeurs humains y gagnent en facilité de lecture puisqu'il faudra ouvrir toutes les relations pour voir l'ensemble des attributs (en espérant qu'ils n'entrent pas en contradiction). 2014/1/8 Christian Quest cqu...@openstreetmap.fr: 1 code FANTOIR à faire correspondre à 1 objet OSM et le plus approprié pour ça m'a l'air d'être la relation associatedStreet. Ca implique de mettre des relations associatedStreet partout, même là où il n'y a pas d'adresses, donc d'en changer fondamentalement la définition. Une telle modification nécessiterait d'en discuter à un niveau plus large que cette liste. Autrement, c'est du bricolage. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
@Pieren Tu parles de lieu sans adresse? J'ai un peu du mal a suivre. A priori toutes les parcelles sont adressables au sens fantoir, puisque celui ci sert essentiellement d'outil a MAJIC pour adresser chaque parcelles! Seulement les élément de fantoir ne sont qu'un élément de l'adresse des parcelle et propriétaire au sens de la DGI. Forcément l'adresse de la résidence des propriétaire est aussi une adresse postal puisque c'est la qu'on leur adresse l'avis d'impot. Le 8 janvier 2014 16:48, Pieren pier...@gmail.com a écrit : 2014/1/8 Tetsuo Shima tets...@gmail.com: A bon? Je comprends pas bien. Le code Fantoir est effectivement un alias des nom de voie, nom de voie qui sont les adresses. Le numéro n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir comme adresse un voie, sans avoir de numéro, ou pas de voie et juste une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro. Il y a un problème de définition ;-) Le code fantoir identifie la voie. Le nom de la voie est effectivement un élément constitutif d'une adresse - comme le nom de la ville ou le code postal - mais pas le code fantoir. Cet attribut n'est peut-être limité qu'à ce rôle dans l'administration fiscale. Mais dans OMS, ça devient un attribut de la voie, pour un usage plus général et pas seulement une composante de l'adresse. Il y a aussi plein de voies sans adresses, ni habitations mais qui doivent quand même avoir un code fantoir, non ? Le descriptif du fichier FANTOIR donne comme définition: Le fichier des voies et lieux-dits ou fichier FANTOIR recense par commune: - les voies - les lieux-dits - les ensembles immobiliers - les pseudo-voies Il est constitué de l'ensemble des références topographiques qu'elles soient annulées ou actives A aucun moment, ça ne parle d'adresse. Il faudrait donc deux collections. Une des nom au sens de l'adresse qui irait naturellement dans associatedstreet, et une des référence DDE qui irait dans une relation associatedroad ou un sous type de associated street. Ouh la, une relation de plus ;-) Une relation par attribut finalement, ou presque ;-) Je suis sûr qu'osm2pgsql pourrait y retrouver ses petits mais ça m'étonnerait que les contributeurs humains y gagnent en facilité de lecture puisqu'il faudra ouvrir toutes les relations pour voir l'ensemble des attributs (en espérant qu'ils n'entrent pas en contradiction). 2014/1/8 Christian Quest cqu...@openstreetmap.fr: 1 code FANTOIR à faire correspondre à 1 objet OSM et le plus approprié pour ça m'a l'air d'être la relation associatedStreet. Ca implique de mettre des relations associatedStreet partout, même là où il n'y a pas d'adresses, donc d'en changer fondamentalement la définition. Une telle modification nécessiterait d'en discuter à un niveau plus large que cette liste. Autrement, c'est du bricolage. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/8 Tetsuo Shima tets...@gmail.com: Tu parles de lieu sans adresse? J'ai un peu du mal a suivre. A priori toutes les parcelles sont adressables au sens fantoir, puisque celui ci sert essentiellement d'outil a MAJIC pour adresser chaque parcelles! Seulement les élément de fantoir ne sont qu'un élément de l'adresse des parcelle et propriétaire au sens de la DGI. Forcément l'adresse de la résidence des propriétaire est aussi une adresse postal puisque c'est la qu'on leur adresse l'avis d'impot. Je parle d'adresses postales, bien-sûr. Dans OSM, on n'a pas de parcelles. Et dans le vocabulaire OSM, une adresse est toujours une adresse postale (même Philou ne confondrait pas avec une adresse IP). On va finir par se comprendre ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 8 janvier 2014 12:22, Romain MEHUT romain.me...@gmail.com a écrit : cf. http://addr.openstreetmap.fr/nancy/?zoom=19lat=48.68871lon=6.15494layers=BTitem=100 Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même nom de rue. J'ai fait l'intégration de la rue que je donnais en exemple. Et j'ai indiqué le ref:FR:FANTOIR dans les relations car je suis aussi dans le cas où une section de rue (http://www.openstreetmap.org/way/10522781) porte deux noms, un name:left et un name:right. Si je devais mettre le ref:FR:FANTOIR sur le way, il me faudrait créer un ref:FR:FANTOIR:left et un ref:FR:FANTOIR:right. Alors relation ou pas relation? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 8 janvier 2014 21:27, Romain MEHUT romain.me...@gmail.com a écrit : Le 8 janvier 2014 12:22, Romain MEHUT romain.me...@gmail.com a écrit : cf. http://addr.openstreetmap.fr/nancy/?zoom=19lat=48.68871lon=6.15494layers=BTitem=100 Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même nom de rue. J'ai fait l'intégration de la rue que je donnais en exemple. Et j'ai indiqué le ref:FR:FANTOIR dans les relations car je suis aussi dans le cas où une section de rue (http://www.openstreetmap.org/way/10522781) porte deux noms, un name:left et un name:right. Si je devais mettre le ref:FR:FANTOIR sur le way, il me faudrait créer un ref:FR:FANTOIR:left et un ref:FR:FANTOIR:right. Alors relation ou pas relation? CQFD... le FANTOIR est donc bien lié aux adresses avant d'être liée à la voirie... ce sont une fois de plus les cas particuliers qui revèlent la cohérence des modèles envisagés. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2014/1/8 Christian Quest cqu...@openstreetmap.fr: le FANTOIR est donc bien lié aux adresses Sur ce point, j'admet. J'ai naivement fait confiance aux différents descriptifs du fantoir que j'ai pu lire (y compris sur l'opendata). Ca ne justifie pas d'utiliser systématiquement une relation associatedStreet si les adresses sont déjà présentes dans OSM ou s'il n'y a pas d'adresses du tout. En passant, cet exemple est encore pire. Le way se trouve entièrement dans une seule des deux communes (et non sur la frontière). Il y aura donc erreur ou même conflit avec les autres attributs d'adresse qu'on déduit à partir du polygone communal (code postal, code insee). Bon courage pour que ça fonctionne correctement avec les outils de geocoding. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 8 janvier 2014 22:20, Pieren pier...@gmail.com a écrit : En passant, cet exemple est encore pire. Le way se trouve entièrement dans une seule des deux communes (et non sur la frontière). Il y aura donc erreur ou même conflit avec les autres attributs d'adresse qu'on déduit à partir du polygone communal (code postal, code insee). Bon courage pour que ça fonctionne correctement avec les outils de geocoding. On déplace la frontière? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 08/01/2014 22:22, Romain MEHUT a écrit : On déplace la frontière? On regarde ce que disent les cadastres ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 08/01/2014 22:31, Vincent de Château-Thierry a écrit : Le 08/01/2014 22:22, Romain MEHUT a écrit : On déplace la frontière? On regarde ce que disent les cadastres ? Même si la rue n'est pas dans la commune ça n'empêche pas les adresses d'y être. C'est le cas des boulevard de Bordeaux dont la voie elle même est à bordeaux, mais seulement les maison d'un seul coté sont à Bordeaux. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Tout à fait en phase avec pieren. Sur les highway c'est plus simple et permet en plus quelque chose que Christian aime bien, les tests de cohérence : - Un code fantoir ne doit avoir qu'un seul nom de rue (et vice versa ?). - Une relation relatedstreet qu'un seul code fantoir. Après, que quelques exceptions passent en relation, c'est une autre histoire. Je ne suis pas du tout aussi expérimenté que vous, mais c'est la modeste contribution. -- Jean-Baptiste Holcroft Le 8 janvier 2014 22:20, Pieren pier...@gmail.com a écrit : 2014/1/8 Christian Quest cqu...@openstreetmap.fr: le FANTOIR est donc bien lié aux adresses Sur ce point, j'admet. J'ai naivement fait confiance aux différents descriptifs du fantoir que j'ai pu lire (y compris sur l'opendata). Ca ne justifie pas d'utiliser systématiquement une relation associatedStreet si les adresses sont déjà présentes dans OSM ou s'il n'y a pas d'adresses du tout. En passant, cet exemple est encore pire. Le way se trouve entièrement dans une seule des deux communes (et non sur la frontière). Il y aura donc erreur ou même conflit avec les autres attributs d'adresse qu'on déduit à partir du polygone communal (code postal, code insee). Bon courage pour que ça fonctionne correctement avec les outils de geocoding. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 03/01/2014 19:04, Frédéric Rodrigo a écrit : Le 01/01/2014 11:07, Frédéric Rodrigo a écrit : Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo,mais probablement ceux de Toulouse)) Le nouvelles stats donnent : 58 009 ref:FR:fantoir (dont 55 755 nœuds) 23 959 ref:FR:FANTOIR (dont 14 218 relations, 6 121 ways et 3 620 nœuds) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Je viens de les passer à ref:FR:FANTOIR, les codefantoir étaient en très grande partie déjà migré. Prochaine étapes aligner les codes sur 11 caractères : - dans l'outil d'aide à l'intégration Voilà toutes les données disponibles à l'intégration avec une ref fantoir sont au format sur 10 caractères (sauf si la ref n'a pas de correspondance dans le fichier fantoir, c'est la valeur d'origine). Au passage les données sur Bordeaux ont été mise à jour (+300 rues en 6 mois). - dans la base Reste à faire ça ! Il faut reverse géocoder les adresses pour identifier la commune de l'adresse, c'est d'un pratique... Je viens d'en faire un premier lot, sur 4200 relations avec le tag ref:FR:FANTOIR (en majuscule) et avec un code sur 4 caractères : http://www.openstreetmap.org/changeset/19870698 Comment j'ai procédé : - reverse géocodage d'un point du way de la relation associatedStreet, mais la qualité du résultat ne garanti pas d'avoir la bonne commune à tous les coups. Sur mes tests : 8 erreurs sur 500. - validation que pour la commune reverse-géocodé le code fantoir (sur 4) donne une rue dont le dernier mot (concept du fantoir) est le même dans le fantoir et dans osm. 100 rues sur 4200 non pas matché sur le dernier mot. - mise a jour des codes si la version de la relation n'a pas changé entre temps et upload. Allez, plus que 75000... Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 01/01/2014 11:07, Frédéric Rodrigo a écrit : Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo,mais probablement ceux de Toulouse)) Le nouvelles stats donnent : 58 009 ref:FR:fantoir (dont 55 755 nœuds) 23 959 ref:FR:FANTOIR (dont 14 218 relations, 6 121 ways et 3 620 nœuds) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Je viens de les passer à ref:FR:FANTOIR, les codefantoir étaient en très grande partie déjà migré. Prochaine étapes aligner les codes sur 11 caractères : - dans l'outil d'aide à l'intégration Voilà toutes les données disponibles à l'intégration avec une ref fantoir sont au format sur 10 caractères (sauf si la ref n'a pas de correspondance dans le fichier fantoir, c'est la valeur d'origine). Au passage les données sur Bordeaux ont été mise à jour (+300 rues en 6 mois). - dans la base Reste à faire ça ! Il faut reverse géocoder les adresses pour identifier la commune de l'adresse, c'est d'un pratique... L'outil d'aide à l'intégration est tout de même assez peu utilisé : http://addr.openstreetmap.fr/stats.php Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Héhé. D'un autre coté c'est un certain Pieren qui a ajouté ce paragraphe sur la page du wiki. Mais je suis d'accord avec lui. Frédéric. Le 01/01/2014 23:03, Pieren a écrit : Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Cette doc laisse à penser que la relation associatedStreet est une entité représentant la rue. C'est évidemment faux puisqu'elle ne sert qu'à l'adressage. Nombre de ces relations ne contiennent qu'un segment de rue. Du coup, mettre votre code FANTOIR sur la relation laisse de nombreuses voies sans référence... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 23/09/2013 15:34, Christian Quest a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo,mais probablement ceux de Toulouse)) Le nouvelles stats donnent : 58 009 ref:FR:fantoir (dont 55 755 nœuds) 23 959 ref:FR:FANTOIR (dont 14 218 relations, 6 121 ways et 3 620 nœuds) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Je viens de les passer à ref:FR:FANTOIR, les codefantoir étaient en très grande partie déjà migré. Prochaine étapes aligner les codes sur 11 caractères : - dans l'outil d'aide à l'intégration - dans la base L'outil d'aide à l'intégration est tout de même assez peu utilisé : http://addr.openstreetmap.fr/stats.php Frédéric, en direct de puis 2014. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Tout compte fait je pense que c'est plutôt la version sur 10 caractères qu'il nous faut utiliser : - Département (2 car) - INSEE Commune (3 car) - RIVOLI voie (4 car) - clé (une lettre) Frédéric. Le 30/12/2013 19:11, Otourly Wiki a écrit : Je pense que le code alphanumérique de 11 caractères devrait suffire. Florian. Le Lundi 30 décembre 2013 16h01, Marc SIBERT m...@sibert.fr a écrit : Bonjour, je remonte le sujet (bien qu'en général personne ne le voit)... Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Perso je penche pour la version longue telle qu'elle est dans le fichier. Vos avis ? A+ Le 23 septembre 2013 15:34, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le Lundi 30 décembre 2013 16h01, Marc SIBERT m...@sibert.fr a écrit : Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Cette doc laisse à penser que la relation associatedStreet est une entité représentant la rue. C'est évidemment faux puisqu'elle ne sert qu'à l'adressage. Nombre de ces relations ne contiennent qu'un segment de rue. Du coup, mettre votre code FANTOIR sur la relation laisse de nombreuses voies sans référence... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Hello, Dites ce serait cool d'avoir un plugin pour çA qui fonctionnerait à la manière de celui pour Wikipédia, afin de retrouver facilement une référence à ajouter. Florian. Le Lundi 30 décembre 2013 19h33, Christian Quest cqu...@openstreetmap.fr a écrit : Ce code long me semble préférable car il permet d'identifier à lui tout seul et de façon unique une voie. Si on ne mettait que le code court, il faudrait systématiquement croiser avec la géométrie de la commune et son code INSEE ce qui ne facilite pas la ré-utilisation qui serait parfois bancale (les voies en limite de commune). Donc un très gros +1 pour moi pour le code long. Le 30 décembre 2013 19:11, Otourly Wiki otou...@yahoo.fr a écrit : Je pense que le code alphanumérique de 11 caractères devrait suffire. Florian. Le Lundi 30 décembre 2013 16h01, Marc SIBERT m...@sibert.fr a écrit : Bonjour, je remonte le sujet (bien qu'en général personne ne le voit)... Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Perso je penche pour la version longue telle qu'elle est dans le fichier. Vos avis ? A+ Le 23 septembre 2013 15:34, Christian Quest cqu...@openstreetmap.fr a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Bonjour, je remonte le sujet (bien qu'en général personne ne le voit)... Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Perso je penche pour la version longue telle qu'elle est dans le fichier. Vos avis ? A+ Le 23 septembre 2013 15:34, Christian Quest cqu...@openstreetmap.fr a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Je pense que le code alphanumérique de 11 caractères devrait suffire. Florian. Le Lundi 30 décembre 2013 16h01, Marc SIBERT m...@sibert.fr a écrit : Bonjour, je remonte le sujet (bien qu'en général personne ne le voit)... Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Perso je penche pour la version longue telle qu'elle est dans le fichier. Vos avis ? A+ Le 23 septembre 2013 15:34, Christian Quest cqu...@openstreetmap.fr a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Ce code long me semble préférable car il permet d'identifier à lui tout seul et de façon unique une voie. Si on ne mettait que le code court, il faudrait systématiquement croiser avec la géométrie de la commune et son code INSEE ce qui ne facilite pas la ré-utilisation qui serait parfois bancale (les voies en limite de commune). Donc un très gros +1 pour moi pour le code long. Le 30 décembre 2013 19:11, Otourly Wiki otou...@yahoo.fr a écrit : Je pense que le code alphanumérique de 11 caractères devrait suffire. Florian. Le Lundi 30 décembre 2013 16h01, Marc SIBERT m...@sibert.fr a écrit : Bonjour, je remonte le sujet (bien qu'en général personne ne le voit)... Quelle longueur pour les codes FANTOIR ? http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Perso je penche pour la version longue telle qu'elle est dans le fichier. Vos avis ? A+ Le 23 septembre 2013 15:34, Christian Quest cqu...@openstreetmap.fr a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2013/9/29 Frédéric Rodrigo fred.rodr...@gmail.com: ...FR:Key:ref:FR:FANTOIR mdr. A lui seul, ce titre de page wiki mériterait sa place dans les [[FR:Fortunes]] ;-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 26/09/2013 23:49, Frédéric Rodrigo a écrit : A Nantes, c'est d'abord rivoli qui avait été retenu puis, à l'exemple de Toulouse, la conversion a ref:FR:FANTOIR a eu lieu le 8/2/2013.. Le débat pour savoir si Nantes est en Bretagne semble évité mais si c'est pour mettre Nantes en Auvergne... Concernant la valeur à mettre, l'opendata fournit généralement les 4 caractères alphanumérique identifiant la voie dans la commune. Le code FANTOIR complet comprend les codes du département et de la commune. Il peut donc être reconstitué à partir de la localisation de la rue sur OSM. Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il évite de la redondance d'information. Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également le recadrage de la valeur sur 4 caractères ? Je ne sais pas c'est avoir. Les ref:FR:fantoir sont ceux de Brest et du Finistère. Ces adresses ont été rentré dans OSM sans relation associatedStreet (je ne sais pas même si elles étaient d'usage à l'époque). Donc le tag ref:FR:fantoir est présent pour chaque numéro et est sur quatre carcactères. Il y a également des zones ou la tag ref:FR:fantoir est juste porté par des ways, mais sans adresses dans le coin. ref:FR:FANTOIR doivent être à Nantes et à Toulouse sur les relations. Pour les relations taille| count +--- 1 |56 2 | 673 3 | 2464 4 | 8980 5 | 126 11 | 423 Pour l'Auvergne il s'agit en fait de 87 noeuds avec une référence sur 11 carcactères, avec des tags places village ou locality : 63081B076G (sûrement département, commune et code à 5 caractères) Pour ce qui est de http://addr.openstreetmap.fr Arles : ref:FR:FANTOIR 4 4 caractères Bordeaux : ref:FR:FANTOIR 5 caractères Lyon : - Montpellier : - Nancy : ref:FR:FANTOIR 4 caractères Rennes : - Pour ce qui est de Bordeaux j'ai corrigé les codes fantoir dans l'outil http://addr.openstreetmap.fr et tout ceux qui étaient déjà en base pour passer à un code à 4 caractères. Je propose maintenant de combler les codes à mois de 4 caractères avec des zéros. btw, j'ai ajouté une petite page de stats là : http://addr.openstreetmap.fr/stats.php J'ai également commencé la page sur le wiki : http://wiki.osm.org/wiki/FR:Key:ref:FR:FANTOIR Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
A Saint-Etienne les code Fantoir sont à 10 caractères apparemment dans les sources : 6 lettres STEDGI plus 4 chiffres. Il semblerait que les 6 lettres initiales indiquent la source à l'origine de la codification (DGI : le cadastre) et un code abrégé pour désigner la commune (STE : Saint-Etienne). On a donc un code abrégé à 4 chiffres mais il n'est pas suffisant. Selon les communes le nombre de chiffres pourrait varier entre 3 et 4, et il pourrait y avoir plusieurs sources selon les secteurs ou selon la source, ou la collecticité qui a la charge de la voirie et fournit ses données. S c'est le cas, le code FANTOIR n'a pas un format unique ou bie il faut le préfixer par les 6 lettres pour le rendre unique au moins dans la commune ou plus grand si nécessaire (s'il y a des sources du département ou d'un EPCI ou d'une autre administration de l'Etat, y compris l'armée, ou d'une administration locale portuaire, voire un établissement mixte d'aménagement local). Y a-t-il une page de référence expliquant cette codification foutoir pardon, FANTOIR ??? Le 29 septembre 2013 19:24, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 26/09/2013 23:49, Frédéric Rodrigo a écrit : A Nantes, c'est d'abord rivoli qui avait été retenu puis, à l'exemple de Toulouse, la conversion a ref:FR:FANTOIR a eu lieu le 8/2/2013.. Le débat pour savoir si Nantes est en Bretagne semble évité mais si c'est pour mettre Nantes en Auvergne... Concernant la valeur à mettre, l'opendata fournit généralement les 4 caractères alphanumérique identifiant la voie dans la commune. Le code FANTOIR complet comprend les codes du département et de la commune. Il peut donc être reconstitué à partir de la localisation de la rue sur OSM. Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il évite de la redondance d'information. Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également le recadrage de la valeur sur 4 caractères ? Je ne sais pas c'est avoir. Les ref:FR:fantoir sont ceux de Brest et du Finistère. Ces adresses ont été rentré dans OSM sans relation associatedStreet (je ne sais pas même si elles étaient d'usage à l'époque). Donc le tag ref:FR:fantoir est présent pour chaque numéro et est sur quatre carcactères. Il y a également des zones ou la tag ref:FR:fantoir est juste porté par des ways, mais sans adresses dans le coin. ref:FR:FANTOIR doivent être à Nantes et à Toulouse sur les relations. Pour les relations taille| count +--- 1 |56 2 | 673 3 | 2464 4 | 8980 5 | 126 11 | 423 Pour l'Auvergne il s'agit en fait de 87 noeuds avec une référence sur 11 carcactères, avec des tags places village ou locality : 63081B076G (sûrement département, commune et code à 5 caractères) Pour ce qui est de http://addr.openstreetmap.fr Arles : ref:FR:FANTOIR 4 4 caractères Bordeaux : ref:FR:FANTOIR 5 caractères Lyon : - Montpellier : - Nancy : ref:FR:FANTOIR 4 caractères Rennes : - Pour ce qui est de Bordeaux j'ai corrigé les codes fantoir dans l'outil http://addr.openstreetmap.fr et tout ceux qui étaient déjà en base pour passer à un code à 4 caractères. Je propose maintenant de combler les codes à mois de 4 caractères avec des zéros. btw, j'ai ajouté une petite page de stats là : http://addr.openstreetmap.fr/**stats.phphttp://addr.openstreetmap.fr/stats.php J'ai également commencé la page sur le wiki : http://wiki.osm.org/wiki/FR:**Key:ref:FR:FANTOIRhttp://wiki.osm.org/wiki/FR:Key:ref:FR:FANTOIR Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.**org/listinfo/talk-frhttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Il y a bien une description officielle du Fantoir: http://www.collectivites-locales.gouv.fr/mise-a-disposition-fichier-fantoir-des-voies-et-lieux-dits Pourtant ce fichier a une codification bien a lui utilisant des champs multiples, et tous ces champs ne sont pas utilisés selon les sources qui le référence. Si je reprend Saint-Etienne, on a des lignes comme: +--+-+***++-++--+*+*+**+*+**+*+*+**+***+***+***+*+***+***+***+**+***++**+ |42|0| || |LOIR|E | | | | | | | | | |000|000| |000|000| | | || | +--+-+***++-++--+*+*+**+*+**+*+*+**+***+***+***+*+***+***+***+**+***++**+ +--+-+---++-++--+*+-+**+-+**+-+-+--+---+---+---+-+---+---+***+**+***++**+ |42|0|218||J|SAIN|T-ETIENNE | |R| | | | |*| |0180773|000|000| |000|1987001| | | | | +--+-+---++-++--+*+-+**+-+**+-+-+--+---+---+---+-+---+---+***|**+***++**+ +--+-+---++-++--+*+-+**+-+**+-+-+--+---+---+---+-+---+---+---+--+***|+**+ |42|0|218|0010|B|PL |ABBAYE| |R| | | |0| | | |000|000| |000|1987001| |004351| |ABBAYE | | |42|0|218|0020|M|RUE |DE L ABBAYE | |R| | | |0| | | |000|000| |000|1987001| |004361| |ABBAYE | | |42|0|218|0025|T|RUE |DE L ABBE BREUIL | |R| | | |0| | | |000|000| |000|1987001| |004371| |BREUIL | | |42|0|218|0030|Y|MTE |DE L ABBE DE L EPEE | |R| | | |0| | | |000|000| |000|1987001| |004381| |EPEE| | +--+-+---|+-++--**+-+--+-+**+-+-+--+---+---+---+-+---+---+---+--+***++**+ (Là j'ai découpé les champs pour la lisibilité, en utilisant des lignes de bordures, mais si les bordures sont des astérisques, c'est juste un champ filler). On voit des lignes de 3 types : - pour la direction locale de la DGFiP (une seule dans ce département de la Loire, portant le nom du département) ; toujours présente en tête de chacun des fichiers; son code est 420 autrement dit le code département plus la direction 0 (pas de découpage du département). Je n'ai pas regardé tous les fichiers pour voir s'il y avait des départements découpés en plusieurs directions c'est peut-être hsitorique). - pour la commune ici le code est 420218 (et non 42218 comme le code INSEE complet d'une commune) car le code de direction s'y insère - pour les voies le code est 420218 suivi de 4 chiffres. La lettre qui suit est incohérente, elle est sensée avoir une signification de clé RIVOLI selon la lettre utilisée (la tranche où elle est allouée donne normalement un statut, masi visiblement ce n'est pas le cas ici pour la Montée de l'Abbé de l'épée. Malheureusement le fichier est écrit entièrement en capitales, sans aucun accent ni apostrophe (les types de voies sont abrégés et codés sur 4 positions, ici MTE pour Montée). - Le nom des voies est limité à 26 caractères (lettre capitale sans accent, ou espace qui remplace toute apostrophe ou trait d'union). - Dans certains cas pour faire tenir le nom de la rue, il est abrégé. RUE DU DOCTEUR XYZ pourra être écrit aussi RUE DOCTEUR XYZ ou RUE DOC XYZ, selon la longueur dy nom qui suit, et un prénom avant le nom pourra être abrégé à sa première lettre... - Quand un prénom est abrégé à son initiale, elle peut être ou pas suivie d'un point abréviatif (le plus souvent non mais ce n'est apparemment pas une règle) - Parfois les apostrophes sont conservées et non remplacées par une espace, parfois on trouve des traits d'union (éventuellement encadrés d'espaces). - Les noms de lieux-dits suivent parfois la mention LIEU-DIT (abrégé parfois LIEUDIT sans trait d'union, ou LDT ) dans le nom de voie, mais pas toujours (le type de voie sur 4 caractères est laissé vide). - Les nombres dans les noms de rue sont écrits en toutes lettres ou en chiffres, parfois en romains (aucune règle on trouve de tout, même pour les dates). Je souhaite bien du plaisir pour traiter ces noms de voies et les rapprocher des noms dans OSM !!! Le reste de la ligne donne - une colonne contient une astérisque our les communes de plus de 3
Re: [OSM-talk-fr] Du Fantoir
Le 25/09/2013 23:43, isnogoud a écrit : Le 25/09/2013 19:20, Frédéric Rodrigo a écrit : Le 23/09/2013 16:40, Pieren a écrit : 2013/9/23 Christian Quest cqu...@openstreetmap.fr: 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) A Nantes, c'est d'abord rivoli qui avait été retenu puis, à l'exemple de Toulouse, la conversion a ref:FR:FANTOIR a eu lieu le 8/2/2013.. Le débat pour savoir si Nantes est en Bretagne semble évité mais si c'est pour mettre Nantes en Auvergne... Concernant la valeur à mettre, l'opendata fournit généralement les 4 caractères alphanumérique identifiant la voie dans la commune. Le code FANTOIR complet comprend les codes du département et de la commune. Il peut donc être reconstitué à partir de la localisation de la rue sur OSM. Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il évite de la redondance d'information. Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également le recadrage de la valeur sur 4 caractères ? Je ne sais pas c'est avoir. Les ref:FR:fantoir sont ceux de Brest et du Finistère. Ces adresses ont été rentré dans OSM sans relation associatedStreet (je ne sais pas même si elles étaient d'usage à l'époque). Donc le tag ref:FR:fantoir est présent pour chaque numéro et est sur quatre carcactères. Il y a également des zones ou la tag ref:FR:fantoir est juste porté par des ways, mais sans adresses dans le coin. ref:FR:FANTOIR doivent être à Nantes et à Toulouse sur les relations. Pour les relations taille| count +--- 1 |56 2 | 673 3 | 2464 4 | 8980 5 | 126 11 | 423 Pour l'Auvergne il s'agit en fait de 87 noeuds avec une référence sur 11 carcactères, avec des tags places village ou locality : 63081B076G (sûrement département, commune et code à 5 caractères) Pour ce qui est de http://addr.openstreetmap.fr Arles : ref:FR:FANTOIR 4 caractères Bordeaux : ref:FR:FANTOIR 5 caractères Lyon : - Montpellier : - Nancy : ref:FR:FANTOIR 4 caractères Rennes : - Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 23/09/2013 16:40, Pieren a écrit : 2013/9/23 Christian Quest cqu...@openstreetmap.fr: 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli D'après wikipedia, fantoir est plutôt un acronyme. Ca serait donc mieux de conserver la version en majuscules ref:FR:FANTOIR comme il est déjà listé dans la liste des ref:FR sur le wiki. Par contre, ça serait bien aussi d'en écrire un peu plus ici: wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR On essaye donc de document ça sur le wiki. Puis de tout migrer vers ref:FR:FANTOIR. Allez hop, c'est parti ! Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Le 25/09/2013 19:20, Frédéric Rodrigo a écrit : Le 23/09/2013 16:40, Pieren a écrit : 2013/9/23 Christian Quest cqu...@openstreetmap.fr: 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) A Nantes, c'est d'abord rivoli qui avait été retenu puis, à l'exemple de Toulouse, la conversion a ref:FR:FANTOIR a eu lieu le 8/2/2013.. Le débat pour savoir si Nantes est en Bretagne semble évité mais si c'est pour mettre Nantes en Auvergne... Concernant la valeur à mettre, l'opendata fournit généralement les 4 caractères alphanumérique identifiant la voie dans la commune. Le code FANTOIR complet comprend les codes du département et de la commune. Il peut donc être reconstitué à partir de la localisation de la rue sur OSM. Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il évite de la redondance d'information. Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également le recadrage de la valeur sur 4 caractères ? Librement Christophe On essaye donc de documenter ça sur le wiki. Puis de tout migrer vers ref:FR:FANTOIR. Allez hop, c'est parti ! Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Du Fantoir
Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
2013/9/23 Christian Quest cqu...@openstreetmap.fr: 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli D'après wikipedia, fantoir est plutôt un acronyme. Ca serait donc mieux de conserver la version en majuscules ref:FR:FANTOIR comme il est déjà listé dans la liste des ref:FR sur le wiki. Par contre, ça serait bien aussi d'en écrire un peu plus ici: wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Du Fantoir
Voila la nomenclature du fantoir : http://www.collectivites-locales.gouv.fr/files/files/gestion_locale_dgfip/Descriptif_FANTOIR_2013.pdf 2 Code département 1 Code direction 3 Code commune 4 Identifiant de la voie dans la commune 1 Clé RIVOLI - numérique pour les voies - 1er caractère pour [...] Ce n'est pas juste un code insee. Le code long peut faire redondant, ou apporter du lien supplémentaire avec la commune. Info que l'on a pas autrement que spatialement (je ne cherche pas à troller). Le 23 septembre 2013 15:34, Christian Quest cqu...@openstreetmap.fr a écrit : Il faudrait qu'on s'accorde là dessus, car c'est un élément important pour le projet adresses. Les codes courts sont ceux sans le code INSEE de la commune ? Le 23 septembre 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, En travaillant sur l'outil d'aide à l'intégration des adresses je me suis rendu compte que le tag ref:FR:FANTOIR est un peu utilisé n'importe comment. Sur taginfo on trouve : 57 995 ref:FR:fantoir (sur des nœuds en Bretagne) 12 807 ref:FR:FANTOIR (sur des relations en Auvergne (selon taginfo, mais probablement ceux de Toulouse)) 3 565 codefantoir (sur des nœuds en Bretagne) 449 rivoli Les valeurs ne sont pas également très normées, on trouve un code court (à 4 chiffre maximun) et des codes longs. L'outil d'aide d'intégration des adresses propose le tag ref:FR:FANTOIR avec comme valeur ce qu'il y a dans l'OpenData, code long ou code court. Le wiki ne nous est d'aucune aide : http://wiki.osm.org/FR:Relation:associatedStreet Le Fantoir c'est le foutoir pour l'instant (oui c'était facile). Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
