[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