[OSM-talk-fr] expérimentations à Orange

[Vincent de Chateau-Thierry]

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