Certes, mais certains choix destinés à faciliter le travail doivent aussi être justifiés techniquement par ce qu'on sait faire à coût raisonnable : calculer (et recalculer) en permanence un squelette filaire à partir d'une donnée surfacique n'est pas envisageable pour l'instant, raison pour laquelle on a accepte de coder les deux, afin que les moteurs de rendus puissent choisir laquelle des représentations afficher sans trop de difficultés.
Le filaire (y compris les nœuds isolés) malgré tout a ses limites, et le surfacique (défini par des contours et non par un tracé central) est souvent bien meilleur en terme de précision pour des cartes à haute résolution, alors que le filaire est mieux adapté à des résolutions limitées qui ne permettraient normalement pas de voir le surfacique (un tracé fialire peut avoir un rendu d'une épaisseur arbitraire bien supérieure à ce que représente l'échelle de la carte: sur une carte routière des autoroutes de France par exemple, les autoroutes ou voies rapides représentées paraissent beaucoup plus larges qu'elles ne sont en réalité à cette échelle). Bref les deux modes de représentation en même temps sont parfaitement justifiés, même pour les réseaux de transport routier voire aussi ferroviaire, bien que là on a des largeurs de voies très homogènes (ces deux modes de représentation sont compatibles entre eux, à condition de BIEN distinguer les deux dans la façon de taguer les éléments : c'est pour ça qu'on a des rôles étiquetés différemment dans les relations : pour les rivières on a bien les classiques "inner"/"outer" pour le surfacique, et "main_stream"/"side_stream" pour le filaire central ; il est alors nécessaire de préciser les choses et ne PAS laisser de rôles vides ambigus à interpréter). Actuellement les routes sont principalement cartographiés en filaire, avec une seule voie centrale "virtuelle" : c'est suffisant à condition de ne pas vouloir créer de carte à haute résolution, et de ne pas vouloir faire de guidage précis sur les changements de voies, ou pour des voies à circulation restreinte ou réservées à autre chose que la circulation automobile générale (y compris les trottoirs, pistes cyclables, voies bus, bande d'arrêt d'urgence...). Si on commence à vouloir détailler les voies multiples, prenant aussi en compte leur sens de circulation, il y a lors des relations à définir (une pour le surfacique, la relation surfacique pouvant référencer un chemin filaire san entrer dans le détail des voies de circulation) ; la séparation des voies ne permet plus de savoir si elles sont en fait une même rue (avec le même nom et la même référence) : la relation séparée de surface permet cependant d'indiquer cela (mais il est plus pratique de grouper les voies filaires dans une relation filaire qui fournit le nom commun, et qui peut encore être référencée par la relation surfacique, tandis que la relation surfacique désignera seulement la voie centrale virtuelle de son squelette) : le chemin central virtuel squelettique passe dans cette surface qui lui donne son nom... Ensuite les moteurs de rendus choisiront ce qui leur est le mieux selon la résolution à laquelle ils travaillent. Quand le travail sera bien avancé, on se posera nécessairement la question de faire évoluer le modèle un peut trop filaire du routier, qui ne permet pas des associations faciles pour des éléments (on a déjà les relations de type "associatedStreet" pour les adresses, des relations pour les lignes de transport des réseaux de bus, avec des voies représentables séparément pour chaque sens dont les arrêts sont différemment placés, et il est difficile de "recoller" ces morceaux ensembles sans une relation de surface, par exemple pour des échanges de transport multimodaux, si en plus on ne veut pas voir dans la carte de "ways" partiellement ou totalement superposés, trop difficiles à modifier là où un seul way aurait suffit en utilisant des relations séparées...). Le 11 mars 2012 23:03, monsieur a <msr...@gmail.com> a écrit : > Et moi qui pensais que la puissance d'Osm etait sa relative facilite de > prise en main, qu'un simple cap cuisine etait suffisant sans avoir besoin > d'un bac +12 en géographie. > > Je devais me tromper. :( _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
