[OSM-talk-fr] synchronisation pour les "imports" de collectivités territoriales

Jean-Guilhem Cailton jgc at arkemie.com
Jeu 1 Avr 21:10:52 UTC 2010


Guillaume Allegre a écrit :
> Le Thu 01 Apr 2010 à 10:57 +0200, Jean-Guilhem Cailton a ecrit :
>
>   
>>> Qu'est ce qui différencierait localCollectivityId d'un tag ref=
>>> (ou ref:Trifouillis=) dans ce cas ?
>>>       
>> Bonjour,
>>
>> La définition et l'usage.
>>
>> Le tag pourrait être défini spécifiquement comme destiné à la
>> synchronisation entre OSM et des bases de données locales.
>> (Pour OSM, il me semblerait plus commode qu'un tag unique soit
>> utilisé (plutôt qu'une possible infinité de "ref:Trifouillis",
>> "ref:LesOies", etc..., pour rester dans le ton de votre exemple)).
>> (D'ailleurs la même démarche pourrait aussi être utile pour la
>> synchronisation avec des bases de données externes, plus
>> généralement ("externalSynchroId" ?)).
>>     
>
> Mais comment la source serait-elle indiquée dans ce cas ?
>
>
>   

Par exemple par un préfixe conventionnel dans la valeur associée à la 
balise, comme
"localCollectivityId=FR-29222-BMO-123456789...", par exemple.

Mais d'ailleurs il vaudrait sans doute mieux diviser ça en deux :
- "localCollectivityId:source=FR-29222-BMO"
- "localCollectivityId=123456789..."
par exemple.

>> Cela permettrait, par exemple, de supprimer des objets d'OSM si le
>> gestionnaire, par exemple la collectivité locale, les supprime.
>>
>> Ce point est certes délicat, puisque l'objet peut avoir été enrichi
>> par ailleurs dans OSM.
>>
>> (Pour les établissements de santé d'Haïti, les suppressions d'OSM
>> consécutives aux suppressions de la Master List sont d'ailleurs
>> validées et faites manuellement, ce qui est un peu lourd, et
>> constitue l'étape la plus longue du processus d'importation. Ces
>> vérifications permettent d'ailleurs dans certains cas d'attirer
>> l'attention sur de possibles erreurs).
>>
>>
>> Quoiqu'il en soit, il me semble que le sujet mérite réflexion.
>>     
>
>
> Bien sûr, le projet mérite réflexion.
>
> Ce qui apparait dans cette proposition, c'est qu'OSM remplirait alors la fonction
> d'un aggrégateur de sources externes multiples.
> C'est bien sûr possible, mais d'autres ont déjà souligné qu'il y avait un risque
> de démotivation de la communauté si ce genre d'emplois devenait majoritaire.
>   

C'est aussi un souci de certains Britanniques avec l'ouverture des 
données de l'Ordnance Survey, et une réponse est qu'il reste toujours 
des choses complémentaires à cartographier ou à mettre à jour (dont les 
plus agréables, comme les sentiers de randonnée :). Il vaut 
effectivement mieux éviter les importations trop massives ou trop 
automatiques qui ont apparemment pu démotiver aux Pays-Bas ou en Autriche.

> Cela dit, on recouvre quand même partiellement la fonction de "ref", je pense.
>
>
>
>   
C'est bien possible, mais justement il vaudrait peut-être mieux éviter 
des chevauchements avec d'autres usages pré-existants et peut-être 
incompatibles.



Si ce qui se passe en Haïti (voir par exemple 
http://lists.openstreetmap.org/pipermail/hot/2010-March/000098.html) est 
une indication, il existe un besoin d'un centre d'échange de données 
central. La question est : voulons nous laisser ce rôle à Google ou 
consorts, avec leur modèle de données propriétaires, à fin lucrative ; 
ou bien défendre un modèle de données libre, à la ODbL ?

(D'ailleurs, avec l'annonce de closedstreetmap.org, et le passage en 
CDbL ("Closed Database License"), la question ne se pose plus).

Cordialement,

Jean-Guilhem
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100401/82745c7f/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr