[OSM-talk-fr] <DKIM> BANO : Orléans et environs en rouge

[Philippe Verdy]

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
puisque ce niveau de zoom est plus grand que la réalité).

Ce que tu crois résoudre un temps finit en fait par compliquer la tâche de
ceux qui passent derrière.

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.

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.

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.

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)

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".


Le 24 février 2015 12:47, Nicolas Dumoulin <
nicolas_openstreetmap.org at dumoulin63.net> a écrit :

> Le mardi 24 février 2015 12:35:54 Jérôme Amagat a écrit :
> > > Qu'on soit bien clair, moi je ne parlais pas de superposer mon way
> > > boundary=political aux ways déjà existants en réutilisant les nœuds.
> >
> > Ok tu ne réutilises pas les noeuds. Tu trace des way très très proches
> des
> > ways déjà existant donc c'est quand même très proche d'une superposition,
> > non?
>
> très proche, oui
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150224/154fd0be/attachment.htm>