Le 19 octobre 2012 09:48, kimaidou <kimai...@gmail.com> a écrit : > Ok pour ta proposition Christian, sauf la suppression du tag source des > objets OSM pour le reporter sur le tag du changeset. Nous nous sommes > engagés à conserver la source du cadastre sur les objets, et cela risque de > coincer. Mais j'ai peut-être mal compris ta proposition >
Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. > Mais sinon, montrer que la communauté français sait être force de > proposition aussi dans le domaine technique fera avancer le débat. On pourra > dire à nos interlocuteurs : que pensez vous de notre solution ? Cela ne > résout pas le problème de gouvernance, qui mettra plus de temps (le temps > long de la négociation), mais cela nous permettra d'avancer dans le bon > sens. > Cette approche technique n'est qu'une facilité pour gérer automatiquement une règle illégitime. Elle a aussi l'avantage de pouvoir gérer bien plus intelligemment un réel problème en séparant dans des changesets différents des données de source différente (que l'on utilise un ou plusieurs compte). La règle reste illégitime pour moi, et les questions sur la gouvernance restent ouvertes. Le 19 octobre 2012 10:06, Jean-Marc Liotier <j...@liotier.org> a écrit : > J'ai un gros doute sur la pertinence d'une modification structurelle d'une > fonction importante d'un outil majeur pour traiter le cas particulier d'une > source de données locale. Mon expérience est que lorsqu'on se lance dans de > telles aventures pour traiter un cas particulier, c'est généralement qu'il y > a un problème ailleurs. Dans le cas présent, il me semble que les problèmes > principaux sont d'ordre politiques. > Justement, je vois cette modification comme un outil bien plus global et pas uniquement adapté au cas particulier du double compte et du cadastre. Il y a une réelle amélioration à apporte à la gestion du traçage des sources, traçage qui sert aussi à évaluer la qualité d'un objet (quelle source, quelle date pour la source, etc). Le 19 octobre 2012 10:31, khris78 <ch...@gallioz.fr> a écrit : > Attention toutefois, d'un point de vue solution technique, ça ne sera > probablement pas si simple. Quid par exemple s'il y a un noeud commun à deux > ways dont l'une est tagguée cadastre et l'autre pas ? => cela nécessitera > surement un download entre les deux uploads, afin de récupérer l'id de ce > noeud. > Seuls les objets NOUVEAUX (id=0) ayant un tag source=* seraient ainsi traités. Si lors de l'intégration, on fusionne des objets avec des objets pré-existants, ceux-ci gardent l'id de l'objet pré-existant. Il y aura bien quelques cas à la marge, mais globalement le principe de traçabilité de l'origine des données fonctionnera. J'ai déjà fait des essais manuels à coup de "chercher" et "envoyer la sélection", ça marche. Il faut envoyer les nouveaux objets avec sourge=* en premier, puis le reste. Il faudrait juste l'automatiser et le rendre transparent pour le contributeur, mais je suis incapable de coder des trucs dans JOSM (java pas bien du tout). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
