Mais les raisons invoquées par le DWG pour ce compte dédié ne sont pas liée à la taille des changeset à ce que je sache.
La raison invoquée, c'est de pouvoir retrouver les données issues de telle ou telle source. Si on accepte que de petite imports soient faits sans un compte dédié, ces données ne seraient plus identifiable comme provenant de cette source ? Il faudra donc de toute façon repasser toutes les données en revue... donc retour à la case départ. C'est totalement illogique comme position sur le plan technique. Si on a besoin d'identifier des données selon leur provenance, on met en place des méthodes valables dans 100% des cas. C'est ce que l'on a fait en imposant le "source=cadastre". Ok, cela prends de la place, mais c'est un problème technique surmontable si on s'en donne la peine (rendre plus populaire le format .o5m/.o5c par exemple qui gère très bien ces répétitions, revoir la structure de la base de données pour que les valeurs des tags soient stockés dans une table et pas multipliés à l'infini). Le besoin d'identifier la provenance est d'ailleurs étrange. On fait référence à un éventuel changement de licence ultérieur. Je sais que le psychodrame du passage à l'ODbL est encore frais dans l'esprit de beaucoup mais justement je pense qu'on n'est pas près de se relancer dans une telle aventure qui cette fois-ci risquera un véritable fork. Il me semble bien plus important de s'assurer que les données importées le soient correctement sur le plan de la qualité que sur ce côté purement bureaucratique. En gros aujourd'hui, importer du bâti mal calé, avec des chevauchements, ne pose pas de problème au DWG tant que c'est fait avec un compte dédié, mais importer du bâti propre, avec les chevauchements corrigés mais avec son propre compte cela ne va pas... c'est là que le délire bureaucratique commence, quand on applique bêtement une règle (le compte dédié) en perdant de vue l'objectif général (la qualité des contributions). Je suis aussi choqué par les points de vue exprimés par certains (y compris au sein du DWG ou board OSMF) sur l'utilité d'importer le bâti ou sur ce côté non prioritaire. C'est hors de propos. (j'espère que ces échanges en français ne te gênent pas, c'est malheureusement plus facile pour moi d'expliquer mon point de vue dans ma langue) Le 25 septembre 2012 18:32, Richard Fairhurst <[email protected]> a écrit : > Christian Quest a écrit: >> Il faut prendre en compte l'aspect très peu pratique et l'utilité >> très très limitée de ce compte dédié pour les imports faits >> de façon parcellaire comme c'est le cas pour le cadastre, >> mais aussi pour beaucoup d'import de données opendata >> comme nous le faisons depuis quelques temps. > > Oui, je comprends vos raisons, et aussi je comprends que (selon DWG) 20,000 > noeuds n'est pas entierement "de façon parcellaire". DWG n'a pas bloqué la > plupart d'utilisateurs de cadastre, seulement les auteurs des changesets > très grands. > > Alors, c'est difficile d'écrire les regles qui sont applicable à tous les > situations. J'espere qu'on peut trouver une solution, mais ça prend du temps > et peut-être du travail technique. > > Richard > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/Imports-du-cadastre-et-compte-dedie-tp5727181p5727429.html > Sent from the France mailing list archive at Nabble.com. > > _______________________________________________ > Talk-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
