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...
Et c'est aussi, à sa manière, fragile. Quid de plusieurs sources issues
de la même ville (on a facilement le cas sur les grandes villes) : la
source des espaces verts, celle de la voirie, etc. Pour peu que les
plages de valeurs se recoupent, le tag ref:FR:<insee> n'a plus de
valeurs uniques dans la même ville, le bénéfice de tracer la source est
perdu.
Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la
multiplicité des clés signifiant toutes la même chose. Je suis d'accord
sur le fait que ça ne gère pas le multi-sources. Mais en même temps,
est-ce que sur ces objets on n'est pas, quasi par principe, face à du
mono-source ? Des objets issus d'un SIG communal, tracés comme tels,
sont potentiellement maintenus côté OSM grâce au lien avec la base
source, justement. Et si besoin, rien n'empêche d'aller un cran plus fin
dans le détail, en sourçant chaque clé plutôt que l'objet dans sa
globalité. On a déjà des paquets de source:addr:postcode et des
source:ref:INSEE, sur le même principe.
vincent
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
