L'idée de bases séparées par réseau au premier abord sonne pas mal,
ça probablement marcherait pour des réseaux comme ERDF ou SNCF,
mais je ne vois pas, comment traiter puis recouper des réseaux qui par
endroits partagent un même espace avec d'autres réseaux, et par
endroits ont leur support propre à eux.
Si on séparerait les BdD,
je crains que leur superposition/croisement poserait plus de blêmes
que leur séparation résoudrait,
logiques, et matériels.
On est des hobbyistes,
je crains qu'on ne puisse pas se payer des lignes atlas réservées sans
limite de bande passante.
Je pense que tout ce qui est "physique" (géoréférencement, nature et
caractéristiques des choses...) devrait rester ensemble dans une même
et unique BdD.
Y compris les "trajets" ou "itinéraires" des différents réseaux (sinon
blême aux intersections).
Ce qui est des infos supplémentaires (opérateur du carting, financier
de la chaîne d'achats, url externe, n° de téléphone du gîte, liens
vers des photos ou des tracks sonores,
prix des carburants à la pompe, de la boîte de ravioli ou du kilo de
patates, prénom de la fille de la cousine...)
d'acc, ça devrait/pourrait aller dans des BdD à part.
---
Le 13 oct. 09 à 14:30, kimaidou a écrit :
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
