Bonjour,

Je me permets de repartir de ce message pour élever le débat. AMHA vous
partez trop vite dans les détails techniques et devez revenir à des
concepts plus stratosphériques.
J'ai créé une page dans le Wiki pour libérer cette liste de diffusion, mais
vous êtes libres, n'est-ce pas ?
http://wiki.openstreetmap.org/wiki/FR:WikiProject_UID_pour_les_administrations(vous
pouvez la déplacer si besoin).

Pour revenir aux basiques :
1. Qu'est-ce qu'un référentiel
2. Quel est le besoin pour les administrations

Et laissez tomber les questions de diffs, on s'en f... à *ce* stade.

(je porterais ce début de conversation dans le wiki et je vous encourage
donc à poursuivre là bas)

I. Un référentiel n'est pas *que * une base de données, mais une
application qui fournit des informations homogènes, stables, fondamentales
pour d'autres applications (au pluriel c'est important)
Dans notre cas, les objets à présenter en référentiel sont (j'enfonce des
portes ouvertes, mais ce sont bien nos bases) :
Point (ex adresse, poi, lieux dits -- ça c'est un troll ;-) )
Linéaire (filaire routier)
Surfacique (îlots de tous types : CP, niveaux administratifs, îlots INSEE,
etc.)

II. A la lecture de la biblio, les organismes concernés gèrent
principalement des bases adresse (ponctuelles ou linéaire), des voies
routières avec code RIVOLI, des territoires gérés par d'autres
administrations (avec codes postaux et/ou INSEE)

A mon avis, nous devons fournir un référentiel sous la forme d'une API
(déjà suggéré ailleurs dans le fil) qui intégrera à la fois des infos OSM
et des informations administratives (je pense particulièrement au RIVOLI et
aux codes admin INSEE en autre) pour permettre la production de données
référentielles.

Les ref des administrations *ne doivent pas* figurer dans OSM, mais au pire
dans une base intermédiaire gérée (maintenue) par OSM_FR (un service...
payant pourquoi pas -- troll aussi)

Je mettrais des schémas de tout ça dans le wiki (plus tard)

Merci de vos retours,

(éviter les troll quand même et essayez de passez sur le wiki donc)


A+



Le 14 avril 2013 16:00, Christian Quest <cqu...@openstreetmap.fr> a écrit :

> Pour prendre un peu de recul... si on réfléchissait au problème de façon
> plus globale ?
>
> Pour utiliser des ref:xx ?
>
> - pour lier des données OSM avec des jeux de données externes
>
> Peut-on/doit-on le faire pour n'importe quel jeu de données ?
>
> Je ne pense pas. Si ce sont des données librement accessibles et qui
> apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa
> place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de
> données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles
> gardent de leur utilité.
>
> Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien.
>
> Comment faire l'inverse... avoir un lien dans des données externes vers
> des objets OSM ?
>
> Là ça se complique gravement pour plusieurs raisons:
>
> - les "id" OSM ne sont pas pérennes: ils peuvent changer suite à un
> effacement/recréation ou parce qu'on fait évoluer un objet (par exemple un
> POI initial sur un nœud peut disparaitre en étant reporté sur un polygone)
>
> - un objet dans le jeu de données externe peut correspondre à plusieurs
> objets dans OSM. C'est le cas par exemple pour les codes FANTOIR/RIVOLI
> (rayer la mention inutile) qui identifient une rue, laquelle rue peut être
> segmentée dans OSM... et là il faut avoir un objet englobant sous la forme
> d'une relation.
>
> Il y en a sûrement d'autres...
>
>
> Il va falloir se pencher sérieusement un de ces jours sur des identifiants
> pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la
> dimension spatiale et la dimension sémantique en gardant un niveau de flou
> sur les deux pour retrouver des objets qui ont légèrement bougé ou
> légèrement changé de description.
>
> Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps)
> serait un truc du genre "bakery#u09v8z39" où "bakery" indique le type
> d'objet cherché et #u09v8z39 est le geohash de sa position approximative.
>
> C'est assez facile à mettre en œuvre pour des objets ponctuels ou
> surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash
> (début/fin).
>
> L'utilisation pourrait se faire via une API interrogeant par exemple
> l'overpass en convertissant ce "hash" à la volée.
>
> Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ?
>
> --
> Christian Quest - OpenStreetMap France
> Synthèse du Week-end "SOTM-FR" à Lyon : 
> http://openstreetmap.fr/s<http://openstreetmap.fr/sotmfr2013>ynthese-sotmfr
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Marc Sibert
m...@sibert.fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à