Pffff. N'importe quoi. Les EPCI ne peuvent pas gérer *toutes* les donénes qu'on met dans OSM. Elles sont de toute façon obligées de faire le tri dans ce qui les intéresse, et de reclasser/regrouper des éléments qui ont été codifiés séparément dans OSM (par exemple à quoi cela peut servir à une collectivité française les clés qui séparents les concepts définis au Royaume-Uni ou aux USA, et à quoi sert la nomenclature de classification officielle française à une agence américaine qui a des lois carrément incompatibles et une toute autre classification ? Personne (j'insiste) ne peut utiliser toutes les clés simultanément, d'autant plus que certaines codifications dans OSM n'ont aucun équivalent officiel ailleurs et ne sont que des compromis orientés vers une utilisation plus grand public. Même nos serveur sde rendu sont obligés tous de faire ces requalifications quand ils créents leurs propres tables de "features" à partir des données OSM trop riches, et de résoudre aussi des ambiguités avec des heuristiques (car on n'a pas encore de règles claires, très souvent, sur la façon de taguer *partout* de la même façon). Dès qu'on commence à parler d'une telle couche d'adaptation, toutes les clés (et aussi les valeurs) doivent d'avord être interprêtées, et ce qu'on ne comprend pas selon le but de la base finale à créer, on le met déjà de côté. Les utilisations vont aussi changer, comme nos propres recommandations et expérimentations sur bon nombre de tags. Déjà assez souvent on doit ignorer des tags devenus obsolètes car trop ambigus. N'en ajoutons pas d'autres qui dès le départ seront ambigus.
Le 14 avril 2013 16:43, Tony Emery <tony.em...@yahoo.fr> a écrit : > Guillaume Allegre wrote > >> Je continue de penser que ref:FR: > > <code INSEE de la commune> > > est une > >> galère potentielle, tant en gestion qu'en compréhension. > > > > Pourquoi ? Ça gêne qui ? > > Ceux qui utilisent les données dans des SIG classiques (il y en a encore). > Il ne faut pas seulement penser informatique et web... > > > Guillaume Allegre wrote > >> Quitte à considérer qu'au sein d'une commune on n'aura pas de > >> chevauchements d'identifiants, alors je préfère largement un unique > >> tag qui serait quasi la proposition de Tony, à savoir > >> ref:FR:admin_level8 > > > > Et si une voie est à la limite de deux communes ayant toutes deux versé > > leur SIG, ça ne marche plus. > > C'est déjà le cas pour le nom de ces voies name:left et name:right. Ou > alors > les séparer par des ";". De toute façon, l'identifiant unique devrait > contenir le n° INSEE de la commune (comme pour les parcelles). > > > Guillaume Allegre wrote > >> avec comme valeur l'identifiant externe fourni par le SIG communal. > >> Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule > >> colonne dans un schéma de BD par exemple) et à documenter : une page > > > > Qui va faire un schéma de BD contenant toutes les clés possibles ? > > Ça existe _en pratique_ ? ça me paraît tordu. > > Des communautés de communes, d'agglo ou tout autre EPCI qui gèrent > plusieurs > communes, par exemple. > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757054.html > Sent from the France mailing list archive at Nabble.com. > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
