[OSM-talk-fr] [OSM-talk] Rencontre SIG Grand Besançon - OSM

[Vincent Pottier]

Le 22/05/2013 22:01, Vincent de Château-Thierry a écrit :
> Bonsoir,
>
> Le 22/05/2013 14:02, Christian Quest a écrit :
>>
>> Nous allons avoir le même type de "problème" avec d'autres sources de 
>> données.
>>
>> Nous allons en effet avoir accès aux données brute du cadastre
>> vectoriel dans certains départements.
>> Ces données contiennent bien sûr le bâti et les limites
>> administratives, mais aussi les points adresses et le filaire de
>> voirie ainsi que quelques POI.
>> L'intégration et la comparaison avec l'existant va donc devoir être
>> développé d'une façon ou d'une autre, soit pour une intégration
>> automatique soit semi automatique avec l'intervention des fourmis OSM.
>> Si possible un tel outil ne devrait pas être trop lié à tel ou tel jeu
>> de données libéré pour pouvoir être utilisé dans un maximum de cas qui
>> au final sont assez similaire.
>> Osmose a pu rendre générique l'intégration de POI ponctuels, il
>> faudrait un équivalent pour des données linéaires ou surfaciques...
>
> Quand j'entends "générique", je tique. Face aux jeux de données d'un 
> nouveau producteur, il faudra se (re)poser des questions sur la 
> qualité de ce qu'on nous propose. Que l'interface pour les fourmis OSM 
> soit au final la même d'un producteur à l'autre pourquoi pas (c'est 
> même souhaitable), mais en amont il faut par principe être prêt à 
> adapter la donnée, pour la faire converger vers notre "cahier des 
> charges" : un mélange de compatibilité technique (format osm, système 
> de coordonnées, géométrie correcte) et de choix éditoriaux (quels 
> modèle de tags pour quelles entités), le tout combiné aux 
> particularismes liés de chaque source.
> De mon côté, volontiers partant pour discuter de tout ça le moment venu.
>
> vincent
Tout à fait d'accord.
Ce que j'avais en tête en causant avec le Service Carto du Grand 
Besançon, c'est un processus en deux temps.
1/
* Analyse
* tri : éviter les doublons, les superpositions, les objets inutiles
* formatage : sémantique, simplification de ways...
* import en base de donnée

2/ mise à disposition sur une interface osmose (ou clc qui sert des 
polygones)
* un layer noir & blanc pour OSM existant
* un layer couleur, fond transparent, pour ce qui est disponible à 
l'intégration
* un layer vecteur cliquable

Le défi est de produire un diff sur une thématique, genre bâti 
(building=*), et d'arriver à le visualiser selon les différents cas
* L'objet existe et est identique dans OSM et dans la source => pas 
d'intégration
* L'objet existe dans OSM et dans S, mais les tags sont différents => 
proposer l'intégration avec report de tags
* Un objet existe dans OSM qui est fortement recouvert par un objet de S 
avec tags équivalents => proposer le remplacement
* Un objet existe dans OSM mais pas dans S = afficher une note (besoin 
de mise à jour ?)
* Un objet existe dans S mais pas dans OSM = proposer l'intégration

Est-il possible de faire une interface unique qui présente à 
l'intégration des éléments de sources diverses, avec peut-être un select 
multiple pour les sources proposées ?
Cette interface laisserait passer certains éléments et pas d'autres... 
On pourrait l'appeler... osmose.
(la partie contrôle qualité pourrait s'appeler cosmetic)
--
FrViPofm