Le 19/03/2011 21:46, JonathanMM a écrit :
On 19/03/2011 21:40, rldhont wrote:
Le 19/03/2011 21:06, Vincent Pottier a écrit :
Le 19/03/2011 19:53, JonathanMM a écrit :
On 19/03/2011 19:33, rldhont wrote:
Le 19/03/2011 15:36, JonathanMM a écrit :
Sauf que tu peux ne mettre qu'une seule fois chaque élément dans
une relation (pas de solution perso).
Faux.
Tu m'apprends un truc là ;)
Donc tu as le même problème avec le schéma proposer, non ?
Oui. Mais ça, c'est dans la structure de base d'OSM. Il faudrait
autoriser de pouvoir mettre plusieurs fois un élément dans une
relation (ou l'autoriser à avoir plusieurs positions)
Un élément peut être présent plusieurs fois dans une relation, que
ce soit un point dans une relation trip (c'est la première fois que
j'en entend parler. 0 dans taginfo) ou un way dans la relation line
(ce que j'emploie comme modèle. 1312 dans taginfo).
La relation trip n'existe pas! C'est une idée de ma part
Un attribut ne peut être présent qu'une fois et avec une unique
valeur (moyennant quelques bizarreries de syntaxe pour mentionner
des valeurs multiples jamais exploitées), mais un élément peut être
plusieurs fois membre d'une relation.
Par ailleurs, quel est le problème de l'exploitation du modèle line ?
Je le trouve, moi, un peu long à mettre en oeuvre (modifications à
reporter dans les différentes lines d'une même route) mais beaucoup
plus clair pour vérifier l'avancée du travail avec les outils de
relation de JOSM (continuité du parcours,, exhaustivité des éléments...)
Sketch-line s'en sort plutôt bien :
http://78.46.81.38/api/sketch-line?network=Ginko&ref=27&correspondences=100
(quatre relations 'line')
Oui le modèle line est pratique par ce que tous les outils te
permettent de travailler dans ce sens mais comme tu le soulignes
c'est long à mettre en oeuvre et après des tests sur la construction
du réseau ce modèle n'apporte aucun avantage.
Donc pour moi 0 avantages pour la construction du réseaux, des
inconvéniants (redondances d'informations, long à saisir, + complexes
à maintenir), 1 avantage tous les outils sont là, ce qui signifie
pour moi qu'il n'apporte rien et qu'il est préférable de rester sur
un modèle simple pour le moment.
En fait ce que je proposait était de garder le modèle simple avec une
seule relation route par ligne, il n'est pas nécessaire de dupliquer
la présence d'une way dans une ligne, et d'ajouter à cette relation
route des relations trip qui découcrivent l'enchainement des arrêts
pour les différents trajets d'une ligne. En fait je tire cette idée
du format GTFS (format de données de réseau de transport en commun de
Goggle) où on retour la notion de route (1 route par ligne) et la
notion de trip (ordre de parcours des arrêts par parcours). De plus
mes tests me laisse penser que c'est plus efficace.
René-Luc D'Hont
3Liz
En y réfléchissant, c'est pas si vrai. Si par exemple, je prend
l'exemple d'une ligne de train, généralement, ça n'utilise pas les
mêmes voies à l'aller et au retour donc redondance assez faible :)
Sketch-line perd quand c'est plus complexe :
http://78.46.81.38/api/sketch-line?network=RER&ref=D&style=transilien
Et puis, les relations trip, ça ne s'applique pas à tous. Si je
reprends l'exemple des trains, ça voudrait dire que je devrais faire
une relation pour chaque train ? Et même en simplifiant (par exemple
une relation par nom de mission, et encore, pour une mission, on a 4
origines différentes donc 4 relations), ça reste assez élevé.
Alors que deux relations par branches, ça marche assez bien :)
En fait 1 relation est suffisante car OSM n'est pas à mon avis fait pour
enregistrer tant de chose abstraite. (l'idée des trips est de ne surtout
pas répété les ways, mais les arrêts ce qui reste assez légé)
Pour info, le modèle complexe sous entend qu'il faut autant de relation
route qu'il y a d'origine donc dans ton cas on devrait avoir 4 relations
routes + 1 relation ligne soit 5 relations et donc par défaut toutes
lignes devrait avoir au moins 2 relations routes + 1 relations lignes
soit 3 relations. Je trouve qu'en fait c'est par défaut trop.
René-Luc
JonathanMM
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
