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: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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr