<div dir="ltr"><div>Et bien même dans ce cas là on se retrouve souvent avec des routes à tracer qui ne savent plus où se raccrocher. C'est tellement proche que ça finit toujours par des fusions de noeuds pour régler le problème (quanf les noeuds ne sont séparés que de quelques centimètres et qu'on ne peut les distinguer (à peine) qu'en zoomant au maximum, ce qui n'est même pas possible dans iD pour cause de problème de rendu des images de fond dans les navigateurs, et que tes noeuds ne sont séparés à l'écran que de quelques millimètres correspondant  parfois même à moins d'un </div><div>puisque ce niveau de zoom est plus grand que la réalité).<br></div><div><br></div><div>Ce que tu crois résoudre un temps finit en fait par compliquer la tâche de ceux qui passent derrière.</div><div><br></div><div>Tant qu'on n'aura pas dans OSM des bases multicouches et que tout est mélangé et qu'il supporte très mal des noeuds multilpes quasiment au même endroit, on ne peut pas reocmmander ta méthode. Le jour où on aura une base multicouche (par thème), tu n'auras même plus à te poser la question, le chargement des donénes mettra automatiquement les données dans leurs couches respectives selon le type de "feature" et les transfert d'une couche à l'autre seront limités (on pourra cependant utiliser une couche coomme guide "gluant" sans pour autant fusionner les points, les traits, les polygones, et sans mélanger tous les tags car il n'y aura plus de collision.</div><div><br></div><div>Déjà que la base actuelle gère mal la 3e dimension (spatiale) et ne veut pas la 4e (le temps, sauf pour des cas de transitions, elle ne peut pas gérer les historiques justement à cause du fourre-tout). Faute de gestion multicouche, elle ne permet pas de créer des catalogues spécilisés avec des validation sur plusierus niveaux (par exemple par groupe de projet et travail individuel, un peu comme Git, ni le versionnement sur la base d'une caputre instantanée; identifiable. (tout ce qu'on a ce sont des identifiant s des derniers objets *créés*, rien pour ceux qui sont modifiés ou supprimés.</div><div><br></div><div>Bref c'est bien pour ça qu'on demande aux utilisateurs un important travail de préparation et d'intégration. Mais toi tu veux t'en passer en créant des géométries modifiées détachées de leurs sens initial.</div><div><br></div><div>Ta méthode ne permet pas du tout de prévenir les altérations involontaires (et surtout pas par les utilisateurs d'iD ou PotLatch)</div><div><br></div><div>En attendant la règle dans OSM c'est de préparer ses données pour une fusion propre. Des accidents il y en aura toujours avec la base actuelle "fourre-tout".</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">Le 24 février 2015 12:47, Nicolas Dumoulin <span dir="ltr"><<a href="mailto:nicolas_openstreetmap.org@dumoulin63.net" target="_blank">nicolas_openstreetmap.org@dumoulin63.net</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mardi 24 février 2015 12:35:54 Jérôme Amagat a écrit :<br>
<span class="">> > Qu'on soit bien clair, moi je ne parlais pas de superposer mon way<br>
> > boundary=political aux ways déjà existants en réutilisant les nœuds.<br>
><br>
> Ok tu ne réutilises pas les noeuds. Tu trace des way très très proches des<br>
> ways déjà existant donc c'est quand même très proche d'une superposition,<br>
> non?<br>
<br>
</span>très proche, oui<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Nicolas Dumoulin<br>
<a href="http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin" target="_blank">http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin</a><br>
<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></div>