<div dir="ltr">J'y connais rien  en programmation en général et en programmation en lien avec OSM non plus.<div>Mais j'ai l'impression que cette solution avec un way pour chaque voie réel c'est du dessin, on veut recopier le monde réel. La solution avec les tag permet à OSM de ne pas servir qu'a faire une belle carte mais peut aussi servir comme données pour un GPS.</div>
<div>Je suis pas sur que de mettre tous les way dans une relation sans donnée d'indication sur les relation entre eux permette une réutilisation facile.</div><div>dans ta relation tu auras par exemple la voie de gauche à coté de la piste cyclable situé 2 km plus loin.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 23 janvier 2014 20:59, hamster <span dir="ltr"><<a href="mailto:hamster@suna.fdn.fr" target="_blank">hamster@suna.fdn.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 23/01/2014 09:22, Greg a écrit :<br>
<div class="im">>> dès qu'on voudra bouger une route (parce qu'il y a eu des travaux<br>
>> ou<br>
> parce qu'on a accès à des photos aériennes plus précises), il faudra<br>
> bouger toutes les ways en même temps, de façon à les garder bien<br>
> "parallèes" les unes aux autres<br>
><br>
> Je trouve et argument très pertinent. D'autant plus qu'avoir tous<br>
> ces ways pseudo-parallèles, c'est une duplication de l'information.<br>
<br>
</div>Couper un way unique en plein de petits troncons avec un gros sac de<br>
tags sur chaque troncon, c'est aussi une duplication d'informations.<br>
<br>
Je serais d'ailleurs curieux de savoir laquelle des 2 solutions prend le<br>
plus de place dans la base de donnees.<br>
<div class="im"><br>
> Aussi, c'est une information spatiale, donc plus délicate à utiliser<br>
> par des outils.<br>
<br>
</div>Comme si les informations spatiales n'etaient pas la base d'OSM...<br>
<div class="im"><br>
> Dans ton schéma, tout ce sac de ways est groupé dans une relation ?<br>
<br>
</div>Oui, je l'ai deja dit plusieurs fois.<br>
<div class="im"><br>
> Je pense qu'il est largement plus rationnel de grouper le tout dans<br>
> des tags,<br>
<br>
</div>Au contraire, je trouve que dans un systeme d'informations geographique<br>
il est rationnel de decrire ce qui peut se dessiner en le dessinant et<br>
de reserver les descriptions textuelles a ce qui peut pas se dessiner.<br>
Il faut pas oublier que dans "geographie" il y a "graphie".<br>
<br>
Je trouve que dans un systeme d'informations geographique, utiliser des<br>
tags plutot que des coordonnees pour dire "tel truc est a gauche de tel<br>
autre" est une heresie.<br>
<div class="im"><br>
> ce qui évite la duplication de l'info<br>
<br>
</div>Pas plus que de dupliquer les tags a outrance.<br>
<div class="im"><br>
> et conserve un schéma de données géographique simple.<br>
<br>
</div>Mais un schema de tags inextricable.<br>
<div class="im"><br>
> Il manque juste un peu d'amour pour cette proposition pour avoir un<br>
> éditeur sexy et avoir une saisie efficace.<br>
<br>
</div>Il manque juste un peu d'amour pour une solution graphique et une<br>
fonctionnalite dans les editeurs pour manipuler plusieurs ways de facon<br>
groupee.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>