Le 30 mars 2013 23:14, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > > Le 30/03/2013 22:35, Guillaume Allegre a écrit : >> >> Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit : >> >>>> Ensuite : ref:orange : là, je pense qu'on a un problème à régler. >>>> "orange" n'est pas suffisamment >>>> distinctif. Si toutes les communes du monde se mettent à utiliser le >>>> même schéma, on va multiplier >>>> les conflits. Comment régler ça ? >>>> >>> >>> Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut >>> rêver), je verrais plutôt un schéma générique sur 2 tags : >>> >>> source=* (rien de nouveau ici) >>> ref:source=* ou source:internal_id ou toute autre formulation pour >>> dire la même chose : mentionner l'identifiant unique utilisé par le >>> fournisseur. >>> >>> Dans l'exemple du way : >>> source="Mairie d'Orange 2012" >>> ref:source=84087V999999 >>> >>> Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un >>> chacun pourrait trouver sur le terrain, mais d'un tag ref qui >>> n'existe que parce qu'une certaine source a été utilisée pour >>> l'objet. >> >> >> Oui, mais cette façon de faire limite les possibilités d'édition >> ultérieures : >> - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un >> ref:FR:<code-commune>) >> - un objet peut avoir plusieurs sources : un SIG territorial à l'origine, >> puis une retouche par Bing >> ou par le cadastre >> et le source=Mairie d'Orange irait mieux sur le changeset >> Du coup, ref:source me semble trop fragile. >> Je pense que ref:FR:<code insee commune> comme proposé par Philippe Verdy >> est le plus sûr. >> > > Avec le schéma ref:FR:<code insee commune> on pourrait se retrouver avec > autant de clés que de communes, toutes signifiant grosso-modo la même chose > : "cette clé a pour valeur une référence interne à la commune XXX". À > l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera > pas là, je pousse juste la logique au bout. Et côté modélisation, autant de > clés distinctes qui disent toutes la même chose, je trouve que ça fait > beaucoup. Et dans ce scenario catastrophe, imagine le schéma de > réutilisation, dans un modèle mis à plat comme le schéma standard > d'osm2pgsql : 36.000 colonnes rien que pour la source...
Là tu pousses à l'extrême car ces clés ne sont pas destinées à devenir des "features" au sens OpenGIS, mais des métadonnées à distinguer parmi celles pouvant renseigner un objet GIS. Hors on se retrouvera vite avec des clés fournies ou référencées par deux collectivités différentes, par exemples sur les voiries partagées par deux communes (ou plus). Si chacun a sa propre référence dans son SIG, on fait comment ? Même si une seule des sources a été utilisée (les autres sont d'accord sur le tracé, il n'y a pas d'ambiguité que c'est bien le même objet référenc, chaque source devrait pouvoir faire le lien avec son propre système de référence, car il n'y a pas garantie que les références utilisées par un SIG soient les mêmes que celle du SIG voisin (à moins qu'il y ait une convention commune adoptée entre les collectivités pour qu'elles utilisent la même référence interne pour faciliter les échanges entre les collectivités). Si ces collectivitées sont deux communes d'une même EPCI, elles se mettront d'accord avec le SIG de l'EPCI qui fera la lien. Mais il restera tout de même encore des liaisons à faire entre les SIG de deux EPCI différents, ou d'un EPCI et d'une commune hors EPCI. Ces communes peuent être aussi dans un autre département ou une autre région. Quand je proposais "ref:FR:<numéro insee> = *", il était évident qu'on pouvait y mettre toute référence insee : un département à deux chiffres/lettres, une commune à 5 chiffres, mais si nécessaire on doit pouvoir être plus précis et indiquer le type de collectivité : - "ref:FR:région:<numéro insee> = *" - "ref:FR:département:<numéro insee> = *" - "ref:FR:commune:<numéro insee> = *" - "ref:FR:EPCI:<numéro insee> = *" Si au sein de la même collectivité il peut y avoir plusieurs sources utilisant des numéros de référence différents (service des espaces verts d'une commune par exemple), on peut sous-qualifier: - "ref:FR:EPCI:<numéro insee>:esp-verts = *" Note: les références nationales pour désigner les territoires entiers des collectivités elles-mêmes (ou autres subdivisions administratives voire aussi les cantons) restent: - "ref:INSEE = <numéro INSEE>" Les académies pourraient avoir leurs propre références pour les établissements qu'elles gèrent: - "ref:FR:académie:<Nom>=*" Chacun a sa clé de référence pour faire la liaison avec son SIG. Idem pour les régions militaires (mais là je pense qu'on n'a pas accès aux références internes, et que c'est géré en fait par le ministère de la défense, y compris pour les gendarmeries) > Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la > multiplicité des clés signifiant toutes la même chose. Cela ne multiplie pas les clés. Les "ref:*" ne sont pas des "features" au sens GIS se ne sont que des métadonnées attachées en complément à un autre feature. Et les ref indiquées ne sont pas non plus nécessairement les sources (on peut n'avoir qu'une source mais plusieurs rérérences non utilisées comme sources). Bref elles ne signifient PAS la "même chose" dans leur valeur ni leur origine même si elles désignent le même objet cible, celui défini dans OSM qui devient un "feature" GIS. Les "source=", comme les "note=", "FIXME=*", "ref:=*" ne sont pas des clés dans OSM, même si les dernières "ref:*=*" ce sont des clés dans d'autres systèmes externes (dont OSM n'a pas besoin d'être exhaustif et peut ne contenir qu'un extrait ou une version simplifiée, et qui peut aussi ne pas être synchronisées avec toutes les différentes sources externes possibles qui peuvent aussi avoir des petites différences entre elles). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
