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

Répondre à