Le 12 juillet 2011 12:34, Eric Sibert <courr...@eric.sibert.fr> a écrit : >> A titre personnel, je pense que "tous" les itinéraires devraient aller >> dans >> une base séparée tant ces itinéraires sont gênants pour les éditions de >> base > > Personnellement, j'ai aussi tendance à penser que les itinéraires devraient > être dans des bases à part s'appuyant sur OSM, pas uniquement pour des > questions d'édition mais parce qu'on a à faire des constructions > intellectuelles fluctuantes. C'est la réflexion que je me faisais à Noël > quand je mettais à jour le plan des pistes de ski de fond d'une station. > Chaque année, ça change. Oui, dans les champs, tu les fais passer où tu veux > les pistes. Dans la forêt, par contre, ça suit des chemins sous-jacents > qu'on retrouve une fois la neige fondue. Donc de mon point de vue, les > éléments suivants auraient plus leur place dans des bases externes: > - pistes de ski > - ligne de bus (mais arrêts et couloirs de bus dans OSM) > - lignes de tram (mais arrêts et voies dans OSM) > - itinéraires routiers Bis, Vert... > - itinéraires vélos > > Après, on peut se demander jusqu'où aller. Les limites administratives? Les > limites de communes ne sont pas très fluctuantes. Mais on pourrait se > demander si les EPCI et autres syndicats intercommunaux à vocations > multiples ou uniques ont leur place. Les liaisons maritimes par ferry? C'est > nécessaire pour les applications de routage. Néanmoins, suivant la > fréquence, ça ne peut pas vraiment s'assimiler à une route. Un temps de > calcul de parcours qui ne tient pas compte des trois jours d'attente du > ferry hebdomadaire... Idem ferroutage.
Je trouve le sujet particulièrement délicat. Il faudrait surtout définir à quoi ça peut bien servir de séparer les bases de données. D'un certain point de vue, les données sont déjà séparées (ou séparables) puisqu'utilisant des entités différentes (type de relation). La solution actuelle est la plus simple et fait déjà ressortir des problèmes lors de l'édition. Je pense qu'en séparant les bases, les problèmes seront encore plus complexes. Mais il me semble que les usages évolues aussi. Par exemple, j'ai récemment consulter le moyen de tagger un radar de vitesse. Et j'ai été surpris de découvrir qu'il s'agissait d'une relation incluant 3 noeuds (oui oui, des noeuds, pas des voies). Je vois assez facilement à quel point ça simplifie le mapping et réduit les conflits d'édition (y'a juste ces 3 noeuds à préserver, pas des ways entières). Du coup, peut-être qu'un solution pour les relations de type "route" consisterait à évoluer vers ce schéma : la route contient quelques noeuds et le tracé est calculé en retrouvant les way qui permettent de joindre les noeuds en question. Du coup, fini les problèmes de split/fusion de way, d'inversion du sens de la way... > Un jour, il faudra répondre à la question : qu'est-ce qui va dans OSM et > qu'est-ce qui n'y va pas? Personnellement, je trouve que cette question a du sens. Mais je ne me la pose pas tant sur les notions d'information concrète ou abstraite. Aujourd'hui, je me demande ce que l'on peut y stocker : - uniquement des éléments réels ? Par exemple, puis-je y mapper l'Atlantide ? - uniquement des éléments visibles ? Par exemple, galeries de grottes, tunnel métro, canalisation, réseau électrique enterré... - uniquement ce qui dure dans le temps ? Par exemple, une discussion récente a abordé la question de la praticabilité des chemins, mais quid des sens de circulation qui changent, finalement, assez souvent, ou de la position des ralentisseurs, passages piétons, pistes cyclable... > Actuellement, le problème des bases externes, c'est comment les relier à > OSM. Répondre à ce problème pourrait aussi faire avancer le schmilblick. Si les bases sont disjointes, il me semble que la réponse est simple, au risque d'être simpliste : les id + changeset/version d'élément. Les Id pour savoir de quoi on parle. Les changeset/version d'élément pour repérer l'état (position, valeur des tags) de l'élément pointé dans le temps. J'ai peur qu'on ne puisse pas vraiment faire plus. Par exemple, impossible d'envisager de contraindre la base centrale avec les bases annexes car le modèle ne tiendrait pas avec l'évolution du nombre de bases annexes, ou finirait par défavoriser des bases officieuses par rapport à des bases officielles (et en libriste que je suis, je n'aime pas les solutions qui privilégient certains utilisateurs par rapport à d'autres). En tout cas, et je ne pense rien apprendre à vous autres, ces réflexions/expériementations sont de plus en plus nécessaires. Avec le temps, OpenStreetMap fait son chemin et devient de plus en plus crédible. Ce qui nous rapproche de plus en plus d'un nouveau type d'utilisateurs, qui ont un SIG et qui veulent bien contribuer à condition qu'on leur offre des outils de synchronisation et le moyen de stocker de l'information qui leur est propre et qui s'appuie sur les données OSM. Bref, va falloir inventer l'équivalent de Git, mais pour OSM. :-) -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr