Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Oui. Mais dans ce cas particulier où il faut deux relations, addr:street dans la relation a du sens à partir du moment où le name de la relation *devrait* être suffixé. Oui, +99% des relations actuelles n'a pas besoin de tag addr:street supplémentaire vu que c'est le même (ce qui est alors cosmétique si on le répète). Mais dans les agglomérations de plusieurs communes on réglerait le problème correctement. Tout n'est pas à changer dans la base, seulement les rues limitrophes ou les rues d'une commune comportant des maisons d'une autre communes proche de cette rue. La solution que j'évoquais est propre. Elle résoud aussi le cas des ponts qui changent localement le nom d'une rue (dans quell segment de voie présent dans la relation le rapprochement BANO irait donc chercher le nom de rue à rapprocher?) Bref addr:street dans la relation n'est pas cosmétique. C'est plus le name de la relation qui l'est quand la relation mentionne un addr:street différent parce que le name doit être suffixé (avec le nom de commune, (entre parenthèses, ou avec une autre ponctuation). Je pense que pour en tenir compte dans le rapprochement la modif est mineure (après tout ce rapprochement a *déjà chargé* les données de la relation pour y trouver un tag name, il peut aussi regarder le tag addr:street pour voir s'il est présent et mentionne quelquechose de différent qui devrait être prioritaire ou utilisé seulement en seconde tentative tout en signalant l'erreur si le rapprochement n'a pas pu être fait sur le addr:street de la relation mais seulement sur son name).. Cela résoud aussi le cas des rues limitrophes des frontières internationales avec deux langues différentes (par exemple entre la France et la Flandre en Belgique) où tous les ways (ou bien seulement une partie) es partagée par deux relations (même si dans ce cas chaque relation a généralement son propre name=* distinct mais on peut effectivement là encore avoir des maisons situées en France dont le way le plus proche est entièrement en Flandre avec son nom en néerlandais et non son nom français (les ways concernés mentionnent les deux noms dans name=*, séparés en général par un /).. Le 3 février 2015 11:00, Vincent de Château-Thierry osm.v...@free.fr a écrit : De: Stéphane Péneau stephane.pen...@wanadoo.fr Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent ___ 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] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 10:13, Christian Quest a écrit : Pas si cosmétique pour la gestion des adresses. C'est là qu'on retrouve facilement (un niveau d'indirection via la relation) le nom de la voie correspondant aux adresses, si il manque il faut passer en revue les membres street pour trouver le nom, donc un deuxième niveau d'indirection. Il n'est pas utilisé pour le rendu carto, mais c'est pas pour cela qu'on peut considérer qu'il soit cosmétique. Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 11:00, Vincent de Château-Thierry a écrit : Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent En fait, si j'ai lancé cette question, c'est en partie suite à ce que j'ai lu dans la discussion sur la liste tagging à propos des relations associatedStreet. Quelqu'un disait que le tag name de la relation était conseillé, mais pas obligatoire, et que ce name n'avait pas à être utilisé pour l'adressage : http://gis.19327.n5.nabble.com/Deprecation-of-associatedStreet-relations-tp5830903p5831243.html Stf (j'en vois un en train de sourire devant son écran :-) ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 06:37, Vincent de Château-Thierry a écrit : Bonjour, Le 03/02/2015 02:25, Philippe Verdy a écrit : Le rapprochement BANO n'utilise-t-il pas de préférence le tag addr:street:* (plutot que name=*) quand il est présent ? Du tout, non. Sur les entités associatedStreet, on a très souvent un tag name, et, d'après taginfo.fr, jamais de tag addr:street : http://taginfo.openstreetmap.fr/tags/type=associatedStreet#combinations Il y a 2 cas pour un objet portant le tag addr:housenumber, - rechercher un tag addr: street sur le même objet, - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. Pour le moment, j'ai juste créé les deux relations (pour lesquelles JOSM a râlé, puisqu'elles concernaient le même objet) sans name (il est sur le highway) avec chacune son ref:FR:FANTOIR. C'est donc suffisant pour que BANO retrouve ses petits ? http://www.openstreetmap.org/way/22755613 http://www.openstreetmap.org/relation/4548496 http://www.openstreetmap.org/relation/4548495 Oups !!! Je viens de voir que le rôle des relations n'est pas bon, il faut que je le corrige ... Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Pas si cosmétique pour la gestion des adresses. C'est là qu'on retrouve facilement (un niveau d'indirection via la relation) le nom de la voie correspondant aux adresses, si il manque il faut passer en revue les membres street pour trouver le nom, donc un deuxième niveau d'indirection. Il n'est pas utilisé pour le rendu carto, mais c'est pas pour cela qu'on peut considérer qu'il soit cosmétique. Le 03/02/2015 07:12, Stéphane Péneau a écrit : Bonjour, Le 03/02/2015 06:37, Vincent de Château-Thierry a écrit : - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. Je croyais que le tag name d'une relation AssociatedStreet était plus cosmétique qu'autre chose. Si oui, ne faudrait-il pas utiliser en priorité le tag name des membres street de la relation ? Stéphane ___ 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] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 10:47, Stéphane Péneau a écrit : Le 03/02/2015 10:13, Christian Quest a écrit : Pas si cosmétique pour la gestion des adresses. C'est là qu'on retrouve facilement (un niveau d'indirection via la relation) le nom de la voie correspondant aux adresses, si il manque il faut passer en revue les membres street pour trouver le nom, donc un deuxième niveau d'indirection. Il n'est pas utilisé pour le rendu carto, mais c'est pas pour cela qu'on peut considérer qu'il soit cosmétique. Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Les relations marchent bien aux limites administrative comme celui là, mais également dans une section avec un nom plus particulier que celui de la rue, tout en étant dans la rue, un pont par exemple. Pour moi c'est le nom de la relation qu'il faut prendre de préférence à ceux des segments pour les adresses. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
De: Stéphane Péneau stephane.pen...@wanadoo.fr Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 02/02/2015 20:20, lenny.libre a écrit : Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = Avenue des Chênes:Bordeaux pour l'une et name = Avenue des Chênes:Mérignac pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Si on en est là, autant laisser comme name=* de la relation le nom de terrain (sans nom de ville accolé) et ajouter à titre indicatif un tag addr:city à la relation, ou une note disant la même chose. Quand il existe (ce qui n'est en rien obligatoire), le tag name des relations associatedStreet sert dans BANO. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Tu peux mettre la commune entre parenthèses, c'est plus lisible que les deux-points collés. Ce nom suffixé dans 'name=* pour les relations n'est de toute façon pas celui des rues qui est dans addr:street:*, c'est un guide visuel pour l'éditeur. Le 2 février 2015 20:20, lenny.libre lenny.li...@orange.fr a écrit : Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = Avenue des Chênes:Bordeaux pour l'une et name = Avenue des Chênes:Mérignac pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Et puisque tous les membres (la voie notamment) ne sont pas dans le périmètre des communes, ils ne sont pas non plus dans le périmètre par défaut du code postal (qui n'est mentonné presque partout QUE dans la commune). Il faudra donc aussi compléter addr:postalcode=* dans la relation associatedStreet qui a des éléments à cheval de dexu communes ou sur la frontière communale. Ok ___ 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] BANO : non rapprochement highway avec code FANTOIR
Le rapprochement BANO n'utilise-t-il pas de préférence le tag addr:street:* (plutot que name=*) quand il est présent ? Le 2 février 2015 21:10, Vincent de Château-Thierry v...@laposte.net a écrit : Le 02/02/2015 20:20, lenny.libre a écrit : Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = Avenue des Chênes:Bordeaux pour l'une et name = Avenue des Chênes:Mérignac pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Si on en est là, autant laisser comme name=* de la relation le nom de terrain (sans nom de ville accolé) et ajouter à titre indicatif un tag addr:city à la relation, ou une note disant la même chose. Quand il existe (ce qui n'est en rien obligatoire), le tag name des relations associatedStreet sert dans BANO. vincent ___ 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] BANO : non rapprochement highway avec code FANTOIR
Bonjour, Le 03/02/2015 02:25, Philippe Verdy a écrit : Le rapprochement BANO n'utilise-t-il pas de préférence le tag addr:street:* (plutot que name=*) quand il est présent ? Du tout, non. Sur les entités associatedStreet, on a très souvent un tag name, et, d'après taginfo.fr, jamais de tag addr:street : http://taginfo.openstreetmap.fr/tags/type=associatedStreet#combinations Il y a 2 cas pour un objet portant le tag addr:housenumber, - rechercher un tag addr: street sur le même objet, - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Bonjour, Le 03/02/2015 06:37, Vincent de Château-Thierry a écrit : - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. Je croyais que le tag name d'une relation AssociatedStreet était plus cosmétique qu'autre chose. Si oui, ne faudrait-il pas utiliser en priorité le tag name des membres street de la relation ? Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 01/02/2015 21:12, Philippe Verdy a écrit : Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. J’ai fait une recherche et je n'ai pas trouvé de description sur la manière de faire (séparation entre radical et suffixe et le suffixe lui-même - name, code insee ... - ). Est-ce : name = Avenue des Chênes:Bordeaux pour l'une et name = Avenue des Chênes:Mérignac pour l'autre ? On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Et puisque tous les membres (la voie notamment) ne sont pas dans le périmètre des communes, ils ne sont pas non plus dans le périmètre par défaut du code postal (qui n'est mentonné presque partout QUE dans la commune). Il faudra donc aussi compléter addr:postalcode=* dans la relation associatedStreet qui a des éléments à cheval de dexu communes ou sur la frontière communale. Ok ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 31/01/2015 21:57, Vincent de Château-Thierry a écrit : Le 31/01/2015 20:43, lenny.libre a écrit : Le 31/01/2015 19:49, Stéphane Péneau a écrit : Elle n'est pas rapprochée car cette avenue est située dans les limites communales de Mérignac. A aucun moment elle ne passe dans Bordeaux. Il y a seulement quelques maisons qui semblent en faire parti. Je ne crois pas qu'il y ait de solution toute prête pour ce genre de situation, mais Vincent pourra certainement en dire plus. Bien vu, en effet, je l'ai vraiment raté !!! Le rapprochement se fait avec la même voie à Mérignac Je n'ai pas trouvé de statuts FANTOIR qui corresponde : Adresses hors périmètre est le plus proche, mais c'est toute la rue qui est hors périmètre ... Il y a bien un bout de code qui permet de récupérer des voies en dehors d'une commune pour tenter un rapprochement. Mais comme on est hors commune, pour ne pas prendre n'importe quoi, il faut un code Fantoir rattaché à la commune. Le cas que tu indiques est pile dedans, donc ça devrait marcher. Sauf que non. Bordeaux est une commune où certains noms sont suffixés. Et jusque là, pour les communes avec des noms suffixés, je zappe cette étape de recherche des voies en dehors de la commune. Pourquoi ? Pas idée ! Ça doit être la flemme :) Bref, ça ne marchera pas ce soir, mais pour ne pas oublier j'ai créé un ticket : https://github.com/osm-fr/bano/issues/88 vincent Pas ce soir ? Pas de soucis, il n'y a vraiment pas d'urgence, il y a suffisamment de taf pour passer à autre chose ; j'ai un post-it et un bon stylo pour me rappeler de revenir faire un tour. Par contre, je vois bien là l'utilisation de deux relations associatedStreet comme dit Philippe. La séparation entre deux communes coupe les parcelles et les bâtiments ; les n° de parcelles sont différents, et les n° dans la rue sont bien identiques dans les deux communes - il y donc bien un seul n° côté rue (bien que sur le cadastre de Bordeaux, le n° est prés de la limite inter-communale). Je vais enlever le FANTOIR du highway et créer les deux relations. Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Note: le noms des deux relations (name=*) devrait être suffixé pour éviter l'homonymie. On peut toujours indiquer le nom **non suffixé** de la rue dans le tag addr:street=* de la relation. Et puisque tous les membres (la voie notamment) ne sont pas dans le périmètre des communes, ils ne sont pas non plus dans le périmètre par défaut du code postal (qui n'est mentonné presque partout QUE dans la commune). Il faudra donc aussi compléter addr:postalcode=* dans la relation associatedStreet qui a des éléments à cheval de dexu communes ou sur la frontière communale. Cependant puisque ces adresses sont desservies par une rue située sur une autre commune que les noeuds d'adress, la zone de distribution postale de ces adresses peut avoir besoin de mentionner non pas la commune où est située le noeud mais le nom (et le code postal) de celle correspodant à la zone de distribution. Mais tant qu'on n'aura pas de relations boudary=postal_code pour gérer les codes postaux et frontières des zones de distributions (comme en Allemagne et en Belgique et un peu déjà en France pour quelques villes découpées en plusieurs zones postales avec des codes postaux multiples), il faudra alors ajouter aussi addr:postalcode=* et même addr:city dans ces relations à cheval.pour que l'adresse **postale** soit correcte (même si le noeud fait partie d'une autre commune que celle indiquée dans addr:city=*). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Elle n'est pas rapprochée car cette avenue est située dans les limites communales de Mérignac. A aucun moment elle ne passe dans Bordeaux. Il y a seulement quelques maisons qui semblent en faire parti. Je ne crois pas qu'il y ait de solution toute prête pour ce genre de situation, mais Vincent pourra certainement en dire plus. Stéphane Le 31/01/2015 19:24, lenny.libre a écrit : Bonjour, J'ai rencontré un highway non rapproché qui a me semble-t-il toutes les infos pour être rapproché ! J'ai mis à jour les données BANO avec OSM. Qu'ais-je raté ? Code FANTOIR Voie FANTOIR Voie OSM Cartes Édition Statut FANTOIR (wiki) http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#Typologie_des_anomalies_FANTOIR 330632046T AV DES CHENES -- ORG http://www.openstreetmap.org/#map=18/44.8484116907/-0.633291393544 FR http://tile.openstreetmap.fr/?zoom=18lat=44.8484116907lon=-0.633291393544 BANO http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#18/44.8484116907/-0.633291393544 JOSM ID http://www.openstreetmap.org/edit?editor=id#map=18/44.8484116907/-0.633291393544 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/44.8484116907/-0.633291393544 http://www.openstreetmap.org/way/22755613 Chemin : Avenue des Chênes (22755613) ref fantoir Modifié il y a 4 mois par Vinber Version #13 · Groupe de modifications #26103596 Attributs bicycle yes foot yes highway residential horse yes maxspeed 30 name Avenue des Chênes oneway no ref:FR:FANTOIR 330632046T surface asphalt zone:maxspeed FR:30 Cordialement lenny ___ 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] BANO : non rapprochement highway avec code FANTOIR
Le 31/01/2015 19:49, Stéphane Péneau a écrit : Elle n'est pas rapprochée car cette avenue est située dans les limites communales de Mérignac. A aucun moment elle ne passe dans Bordeaux. Il y a seulement quelques maisons qui semblent en faire parti. Je ne crois pas qu'il y ait de solution toute prête pour ce genre de situation, mais Vincent pourra certainement en dire plus. Stéphane Bien vu, en effet, je l'ai vraiment raté !!! Le rapprochement se fait avec la même voie à Mérignac 332810642U AV DES CHENES Avenue des Chênes ORG http://www.openstreetmap.org/#map=18/44.8467708102/-0.633763371924 FR http://tile.openstreetmap.fr/?zoom=18lat=44.8467708102lon=-0.633763371924 BANO http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#18/44.8467708102/-0.633763371924 JOSM ID http://www.openstreetmap.org/edit?editor=id#map=18/44.8467708102/-0.633763371924 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/44.8467708102/-0.633763371924 Je n'ai pas trouvé de statuts FANTOIR qui corresponde : Adresses hors périmètre est le plus proche, mais c'est toute la rue qui est hors périmètre ... Lenny Le 31/01/2015 19:24, lenny.libre a écrit : Bonjour, J'ai rencontré un highway non rapproché qui a me semble-t-il toutes les infos pour être rapproché ! J'ai mis à jour les données BANO avec OSM. Qu'ais-je raté ? Code FANTOIR Voie FANTOIR Voie OSM Cartes Édition Statut FANTOIR (wiki) http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#Typologie_des_anomalies_FANTOIR 330632046T AV DES CHENES -- ORG http://www.openstreetmap.org/#map=18/44.8484116907/-0.633291393544 FR http://tile.openstreetmap.fr/?zoom=18lat=44.8484116907lon=-0.633291393544 BANO http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#18/44.8484116907/-0.633291393544 JOSM ID http://www.openstreetmap.org/edit?editor=id#map=18/44.8484116907/-0.633291393544 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/44.8484116907/-0.633291393544 http://www.openstreetmap.org/way/22755613 Chemin : Avenue des Chênes (22755613) ref fantoir Modifié il y a 4 mois par Vinber Version #13 · Groupe de modifications #26103596 Attributs bicycle yes foot yes highway residential horse yes maxspeed 30 name Avenue des Chênes oneway no ref:FR:FANTOIR 330632046T surface asphalt zone:maxspeed FR:30 Cordialement lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 31/01/2015 20:43, lenny.libre a écrit : Le 31/01/2015 19:49, Stéphane Péneau a écrit : Elle n'est pas rapprochée car cette avenue est située dans les limites communales de Mérignac. A aucun moment elle ne passe dans Bordeaux. Il y a seulement quelques maisons qui semblent en faire parti. Je ne crois pas qu'il y ait de solution toute prête pour ce genre de situation, mais Vincent pourra certainement en dire plus. Bien vu, en effet, je l'ai vraiment raté !!! Le rapprochement se fait avec la même voie à Mérignac Je n'ai pas trouvé de statuts FANTOIR qui corresponde : Adresses hors périmètre est le plus proche, mais c'est toute la rue qui est hors périmètre ... Il y a bien un bout de code qui permet de récupérer des voies en dehors d'une commune pour tenter un rapprochement. Mais comme on est hors commune, pour ne pas prendre n'importe quoi, il faut un code Fantoir rattaché à la commune. Le cas que tu indiques est pile dedans, donc ça devrait marcher. Sauf que non. Bordeaux est une commune où certains noms sont suffixés. Et jusque là, pour les communes avec des noms suffixés, je zappe cette étape de recherche des voies en dehors de la commune. Pourquoi ? Pas idée ! Ça doit être la flemme :) Bref, ça ne marchera pas ce soir, mais pour ne pas oublier j'ai créé un ticket : https://github.com/osm-fr/bano/issues/88 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 31/01/2015 23:28, Philippe Verdy a écrit : Raison de plus pour ne pas séparer le chemin d'une rue et celui d'une frontière administrative alors que c'est dévidence la même; la rue étant partagée par deux communes, chacune utilisant son code FANTOIR et éventuellement son propre nom et sa propre numérotation des adresses (et son éventuel code de voie communal dans son SIG; si ce n'est pas le FANTOIR et le rapprochement complet n'est pas fait ou difficile car pas complètement équivalent pour certaines sections distinguées dans un des codes mais pas dans l'autre). La séparation physique (en séparant les nœuds) s'impose seulement si la frontière s'écarte de la voirie et va séparer des parcelles d'une seule commune. Dans le cas présent la frontière entre Bordeaux et Mérignac ne passe pas par l'axe de l'Avenue des Chênes, mais traverse bien des parcelles. La limite dans OSM est raccord avec celle visible directement sur le cadastre : http://www.openstreetmap.org/way/186045436#map=18/44.84906/-0.63297 donc la question du partage des chemins entre rue et frontière n'est pas à poser ici. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Oui mais on a bien le cas de bâtiments à cheval sur deux communes, et la voie partagée pour les adresses. La solution de deux relations associatedStreet est raccord avec le problème : évidement dans ce cas la voirie sera sur une commune différente que les noeuds d'adresse positionnés sur une autre: les noeuds ne sont pas hors périmètre et donc la relation sera trouvée même su les segments de voirie incus dans la relation sont hors périmètre. Le rapprochement est donc possible exactement de la même façon que quand la frontière suit l'axe de voirie: ce sont surtout les noeuds positionnés de chaque côté qui guident le résultat (et il est également permis d'associer un seul noeud à deux relations de rues différentes, pour le cas de batiments ayant des accès sur chacune des rues et une adresse sur chacune; cependant il se pose le cas des numéros différents sur chaque rue et pour ça pas moyen de faire autrement que d'avoir deux noeuds distincts sur le même bâtiment; l'un associé à une rue, l'autre associé à une autre rue). Le 31 janvier 2015 23:49, Vincent de Château-Thierry v...@laposte.net a écrit : Le 31/01/2015 23:28, Philippe Verdy a écrit : Raison de plus pour ne pas séparer le chemin d'une rue et celui d'une frontière administrative alors que c'est dévidence la même; la rue étant partagée par deux communes, chacune utilisant son code FANTOIR et éventuellement son propre nom et sa propre numérotation des adresses (et son éventuel code de voie communal dans son SIG; si ce n'est pas le FANTOIR et le rapprochement complet n'est pas fait ou difficile car pas complètement équivalent pour certaines sections distinguées dans un des codes mais pas dans l'autre). La séparation physique (en séparant les nœuds) s'impose seulement si la frontière s'écarte de la voirie et va séparer des parcelles d'une seule commune. Dans le cas présent la frontière entre Bordeaux et Mérignac ne passe pas par l'axe de l'Avenue des Chênes, mais traverse bien des parcelles. La limite dans OSM est raccord avec celle visible directement sur le cadastre : http://www.openstreetmap.org/way/186045436#map=18/44.84906/-0.63297 donc la question du partage des chemins entre rue et frontière n'est pas à poser ici. vincent ___ 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] BANO : non rapprochement highway avec code FANTOIR
Raison de plus pour ne pas séparer le chemin d'une rue et celui d'une frontière administrative alors que c'est dévidence la même; la rue étant partagée par deux communes, chacune utilisant son code FANTOIR et éventuellement son propre nom et sa propre numérotation des adresses (et son éventuel code de voie communal dans son SIG; si ce n'est pas le FANTOIR et le rapprochement complet n'est pas fait ou difficile car pas complètement équivalent pour certaines sections distinguées dans un des codes mais pas dans l'autre). La séparation physique (en séparant les nœuds) s'impose seulement si la frontière s'écarte de la voirie et va séparer des parcelles d'une seule commune. Mais dès qu'on partage les nœuds, cela n'a aucun sens de séparer les ways en les superposant (et ça complique beaucoup les jonctions de carrefours de rues, l'ajout des traversée piétons, le découpage pour des limites de vitesse, etc... (presque tout le temps c'est le mauvais chemin qui est utilisé pour ajouter un nœud ce qui donne une topologie incorrecte et des objets non trouvés dans les requêtes, et c'est infernal à corriger; en plus du fait que le rendu ne sait plus gérer correctement l'ordre d'affichage des layers et peut tracer un des chemins par dessus un libellé ce qui le rend difficilement lisible, ce cas étant encore pire si on a séparé aussi les nœuds). En revanche il arrive que la frontière communale soit parallèle à un chemin communal (fossés inclus) n'appartenant qu'à une seule commune la limite étant entre le fossé et la parcelle. L'écart dans ce cas entre l'axe de la voirie et le début de la parcelle est suffisant (de l'ordre de 2 mètres minimum, soit la moitié de la largeur de voirie et de ses bas-cotés et fossés) pour justifier la séparation physique des nœuds (et donc des chemins aussi). S'il n'y a qu'une voirie utilisée par les deux communes et pas de séparation physique centrale, alors un seul chemin partagé entre voirie et frontière communale : les deux communes en assument la charge de façon partagée (ou c'est les collectivités dont elles font partie). Pour les autres frontières non administratives n'entrant pas dans le champ des adresses on peut encore utiliser des chemins séparés (mais attention à ne pas en même temps couper des bâtiments et donc rester au moins dans la largeur de voirie publique mais dans ce cas garder les noeuds séparés. Dans les deux cas il faut deux relatons associatedStreet (ou type=street dans une proposition plus récente peu utilisée), une pour chaque coté avec ses propres nœuds d'adresse du bon côté et son bon nom de rue). et reprenant les chemins de voirie partagés ou longés sur la commune voisine. L'autre solution utilisant left:name et des left:ref:* ne marche pas bien du tout et n'est pas stable: un changement de direction et les noeuds adresses ne sont plus associés à la bonne commune... Cas particulier : il existe (surtout en zone urbaine dense, mais on en trouve aussi dans les zones industrielles comme des entrepôts et certains grands bâtiments agricoles ou des habitations qui ont été agrandies) des bâtiments à cheval sur deux communes (voire deux pays) et qui ont deux adresses : mettre un nœud d'adresse sur chaque partie disposant d'un accès sinon si on indique l'adresse sur le bâtiment lui-même elle indiquera une seule commune qui n'est pas celle qui couvre tout le bâtiment. Le 31 janvier 2015 19:49, Stéphane Péneau stephane.pen...@wanadoo.fr a écrit : Elle n'est pas rapprochée car cette avenue est située dans les limites communales de Mérignac. A aucun moment elle ne passe dans Bordeaux. Il y a seulement quelques maisons qui semblent en faire parti. Je ne crois pas qu'il y ait de solution toute prête pour ce genre de situation, mais Vincent pourra certainement en dire plus. Stéphane Le 31/01/2015 19:24, lenny.libre a écrit : Bonjour, J'ai rencontré un highway non rapproché qui a me semble-t-il toutes les infos pour être rapproché ! J'ai mis à jour les données BANO avec OSM. Qu'ais-je raté ? Code FANTOIR Voie FANTOIR Voie OSM Cartes Édition Statut FANTOIR (wiki) http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#Typologie_des_anomalies_FANTOIR 330632046T AV DES CHENES -- ORG http://www.openstreetmap.org/#map=18/44.8484116907/-0.633291393544 FR http://tile.openstreetmap.fr/?zoom=18lat=44.8484116907lon=-0.633291393544 BANO http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#18/44.8484116907/-0.633291393544 JOSM ID http://www.openstreetmap.org/edit?editor=id#map=18/44.8484116907/-0.633291393544 P2 http://www.openstreetmap.org/edit?editor=potlatch2#map=18/44.8484116907/-0.633291393544 http://www.openstreetmap.org/way/22755613 Chemin : Avenue des Chênes (22755613) ref fantoir Modifié il y a 4 mois par Vinber Version #13 · Groupe de modifications #26103596 Attributs bicycle yes foot yes highway residential horse yes maxspeed 30 name Avenue des Chênes
