On partage le même point de vue, sauf que les références provenant d'entités administratives multiples mais de même niveau (plusieurs communes ou plusieurs départements) risquent d'arriver (sans pour autant que leurs identifiants de bases de données soient compatibles entre eux.
Là dessus OSM peut **aussi** devenir prescripteur d'identifiants stables permettant d'aider les collectivités à trouver des identifiants pour bases de données compatibles entre elles, si les organismes nationaux fournissant des nomenclatures (l'Insee par exemple, ou des organismes européens, ou l'ISO dans une norme internationale) ne traitent pas certains sujets. De nombreux pays par exempel n'ont pas de nomenclature stabilisée et utilisent des logiciels et bases de données fournies par d'autres pays ou par des sociétés privées ou organisations non commerciales (je pense à des tas de PVD en Afrique, Asie centrale, et archipels du Pacifique ou des Caraïbes), tout bonnement car ils n'ont pas les moyens de développer et maintenir ces logiciels et bases de données eux-mêmes. Hors ces pays, s'ils font appel à des sociétés privées (ou même de la part de fondations caritatives internationales), risquent de se retrouver dans l'incapacité de publier leurs données à cause de problèmes de licences de la part de ces tiers. OSM peut alors fournir une aide en proposant sa codification qui ne sera pas meilleure, ni pire, que les autres codifications incompatibles entre elles proposées par des tiers sous des licences restrictives et empêchant les croisements de fichiers qui leurs sont pourtant fournis. Le 7 avril 2013 00:46, Tony Emery <[email protected]> a écrit : > Guillaume Allegre wrote > > OSM ne doit pas devenir un dépôt où les "institutions" accepteraient de > > verser leurs données à condition que personne n'y touche. > > > > OSM c'est du crowdsourcing avant tout ; l'open data est un complèment, > > bienvenu mais pas essentiel. > > Il faut qu'on travaille au maximum pour intégrer l'open data dans OSM, > > mais si > > on tombe sur un conflit entre les deux, OSM laissera tomber l'open data > et > > privilégiera toujours le crowdsourcing. > > > > Ce point est très important pour les discussions avec les collectivités, > > et > > il est non négociable, comme la licence. > > En un mot : aucune donnée ne doit être verrouillée dans OSM. > > Je suis d'accord sur ce point. Mais je tiens, en tant que cartographe et > géographe de formation à vous rappeler une chose : quel sens donne-t-on à > la > carte ? à quoi doit-elle servir ? > S'il s'agit juste de cartographier le réel juste pour avoir des objets dans > la base de données, ça sert à rien. > Si on veut que cela soit utiliser, ça veut dire qu'il faut créer de la > donnée pour l'usage et l'usager. > > Concernant la remarque de Guillaume sur: > > Guillaume Allegre wrote > > Donc, exit le ref:source=...., et je ne vois pas d'autre solution que > > le ref:FR: > > <idbase> > > = > > <id> > > Je suis d'accord pour un ref:FR:<idbase>=<id>, et même, je dirais, un > ref:FR:Communal=<id> ou un ref:FR:<niveau_administratif>=<id> pour gérer > les > référentiels de plusieurs échelles administratives. > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5756101.html > Sent from the France mailing list archive at Nabble.com. > > _______________________________________________ > Talk-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
