Bonjour Pas de foudre pour ma part, je trouve ton commentaire très intéressant, car il montre bien la complexité de la choses et ne tombe pas l'écueil de la simplification abusive d'un problème complexe.
Je ne pense pas non plus qu'il y ait de solution évidente. Il faut que le travail des participants reste simple, sinon comme cela a été dit personne n'ajoutera des lignes de transport, et à force de créer des relations par dessus les données de base on ne verra plus rien. D'un autre côté, je n'aime pas trop les affirmations du genre "On n'est pas là pour simplifier le travail du concepteur de logiciel". D'accord, les développeurs peuvent toujours s'adapter, mais il ne faut pas que cela oblige à concevoir des usines à gaz non plus. Tout est dans l'équilibre. Pour finir, on atteint peut-être là aussi la limite de ce qu'on devrait cartographier dans osm. Peut être que tous nos chemins de rando, lignes de bus, etc, bref tout ce qui n'est pas physique ne devrait pas être ajouté directement dans la donnée brute d'osm, mais seulement sur des bases de données parallèles dédiées. ? Cela permettrait d'avoir un fond de carte physique qui reste simple, mais cela demande une fois encore plus de travail pour développer ces applications tierces. (Si la route n'est pas découpée en plusieurs ways, il est plus difficile de "créer" les routes et il faudrait alors travailler noeud par noeud ? Par exemple on définit une ligne comme passant par des noeuds, et plus comme une relation contenant des ways = morceaux de rues ?) Kimaidou Le 13 octobre 2009 12:43, g.d <g...@wanadoo.fr> a écrit : > Bhen oui, dilemme dans la "stratégie générale" d'osm... :-( > > Utiliser les points seulement, ça deviendrait vite ingérable > (invisible, et pas exploité), > > Saucissonner tout en petits morceaux et les fourrer dans des > relations, ce serait certes "systématique", > mais tant que les éditeurs sont ce qu'ils sont, > ça va finir dans un plateau de charcuterie à la fin d'un buffet froid : > "Plat de résistance : Île flottante de jambon cru dans saumure de > cornichon, garnie d'anneaux de peau de tranches de salami" :-( > > (Pour être conséquent avec soi-même, il faudrait que Tout osm du jour > au lendemain bascule vers un système de "relations" imbriquées : > Plus aucun tag sur des nodes ni sur des ways, qui eux deviendraient > géopositionnement pur, > et toute la description irait dans les "relations"... > On aurait donc aussi des "relations mono-nodes", > et un système de super-hyper-duper-relations. > Il deviendrait inconséquent, de noter un copyright dans chaque sous- > élément ou sous-relation : > On aurait une seule "super-relation" par année d'édition de cadastre, > dans laquelle on fourre tous les tracés de cette année-là, > l'IGN ne figurera qu'une seule fois : dans le tag d'une super-relation > dans laquelle on engloutirait toutes ses bornes, > voire même une seule "relation" pour tous les parkings de France et de > Navarre, pareil pour les églises, mairies, peaks et autres. > Ce deviendrait une approche inverse à l'actuelle. > Peut-être ça viendra un jour, > mais on n'en est pas là, > pour l'instant c'est "hybride"). > > Revenir à l'api précédente : en aucun cas, > > Et superposer des ways à part pour les itinéraires en utilisant les > mêmes nodes, > ça avait été regardé comme indigne, ringard out over Mathusalem, si > j'ai bon souvenir > (Dans l'amas des "spaghetti" superposés, parfois il n'est pas aisé de > sélectionner celui qu'on cherche, > il est plus facile de dire, que c'est méthode ringard...) > > Donc, qu'est-ce qu'on fait ? Pour "être in" ? > me grattant la tête... > > ...bhen, > n'étant pas féru en relations, et par trouille de casser une relation, > pour l'instant je pense continuer avec des ways superposés, pour les > trajets/itinéraires. > > Dans le cas d'itinéraire rando que présente Fabien, > si le randonneur doit emprunter le bitume de la route (comme c'est le > cas dans des villages où il n'y a pas de trottoirs, et sur beaucoup de > petites routes "dehors"), > je pense que je collerai un way "footway" supplémentaire sur les nodes > de la route, > mais si les randonneurs passent sur le bas-côté (se sont faits un > sentier à part), ou en ville sur des trottoirs, > j'y mettrai probablement un footway avec des nodes séparés, > et des nodes communs avec les highway voitures, là où ça les croise. > > Et pour le trajet d'un bus ou tram, je probablement mettrai un way à > lui, pareillement : > Si ça partage le même espace, sur les mêmes nodes que la route, > mais si ça passe à côté sur voie séparée ou entre deux voies sens- > uniques, sur des nodes distincts. > > Donc le rond-point resterait un rond-point fermé, > avec collé dessus d'autres ways qui eux représentent le trajet du car, > > donc un way pour l'aller et un autre pour le retour, à chaque fois un > way complet entre deux arrêts (solution que je préférerais), > Ensuite, je pourrai imaginer de découper ce way-trajet en morceaux sur > le rond-point, et fourrer les morceaux dans des relations distinctes, > une pour l'aller, l'autre pour le retour. > Mais dans ce cas, je ne sais pas comment faire pour qu'un trajet entre > deux arrêts reste cohérent *et* qu'il reste distinctif de la "ligne" > entière : > Il y a bien des trajets de car/tram/métro distincts dans les deux > sens, soit-ce à cause de rues en sens unique, > ou des lignes qui bifurquent pour desservir des coins différents. > Il faut donc garder bien séparé les deux trajets, > afin qu'un nav' "mixte" ne propose pas un tour de manège autour d'un > rond-point ou autour d'un quartier, > là où pour ce faire, en réalité on doit descendre à la station > suivante et prendre la rame / le car suivant dans l'autre direction. > > Dans d'autres pays, on voit sur osm des lignes de transport-en-commun > représenté par des linges droites entre les haltes/stations. > D'un point de vue topologique et pour les nav', "ça se tient", puisque > les points où on change de réseau, y sont, > mais sur la carte ça fait désordre, quand une ligne de car traverse > les blocs de maisons, > ou traverse les Alpes en ligne droite là où il n'y a pas de tunnel. > > Je suis donc "pour" une représentation réaliste des lignes de > transport en commun, > mais je suis conscient que pour la ligne de car Montpellier-Rodez > (officielle) ça pose des conflits, > sans parler de lignes de car comme Berlin-Istanbul ou Paris-Alger > (privées, je pense). > Je n'ai pas la science infuse :-( > > Je vois déjà les foudres que ce commentaire va m'attirer, et rétracte > la tête entre les épaules, > mais faute de mieux je ne sais pas comment conserver la cohérence *et* > la lisibilité par une autre manière, que de tracer un way concret. > > Amicalement (et pas sur de moi, du tout...) > Gerhard > trop long... > --- > > Le 12 oct. 09 à 13:41, Pieren a écrit : > > > > > 2009/10/12 sly (sylvain letuffe) <sylv...@letuffe.org>: > >> Bref, dans ces cas là, je ne vois pas d'autre solution que de faire > >> du > >> saucissonnage de way. > >> > > > > On peut résoudre ça en utilisant des points intermédiaires > > (d'intersections virtuelles en quelque sorte). > > > > Sinon, on continue à saucissonner les rues à tout va, juste pour que > > les logiciels de rendu d'itinéraire ait un boulot facile et à terme, > > effectivement, on va tout placer dans des relations comme Sylvain le > > souhaite depuis longtemps. Au final, ça sera le travail des > > contributeurs qui sera compliqué à souhait. Comme le dit souvent > > Frederik Rahmm, ce n'est pas à ceux qui fournissent les données - > > ceux-là sont rares et précieux - à faire le boulot pour ceux qui > > consomment les données - ceux-là doivent faire l'effort d'adapter > > leurs logiciels. > > Pieren > > > > _______________________________________________ > > _______________________________________________ > 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
