[OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[DH]

Le 25/01/2013 21:18, Vincent de Chateau-Thierry a écrit :
> Bonsoir,
>
> Le 25/01/2013 15:44, HELFER Denis a écrit :
>> Je commence à m’intéresser sérieusement à la segmentation dynamique dans
>> le domaine de l’infra ferroviaire où l’on raisonne essentiellement en
>> termes de PK (pour les événements ponctuels ex. Passage à niveau,
>> appareil de voie)ou PK début/Pk fin pour les événements linéaires
>> (ouvrages d’art, chantiers, électrification, …). Je confirme mon intérêt
>> pour cette démarche !
>>
>> Idéalement, on devrait avoir une consistance topologique au niveau du
>> tracé, la consistance sémantique serait assurée par des relations.
>>
>> Exemple pour un pont-rail
>>
>> Relation X
>>
>> Required Type=ouvrage_art
>>
>> Required Description=pont-rail
>>
>> Optional source=RFF
>>
>> Optional material=metal
>>
>> Optional length=xxx
>>
>> Optional height=xxx
>>
>> Optional name=blabla
>>
>> Required Members : a rôle « from »
>>
>> Required Members : b rôle « to »
>>
>> Required Members : c rôle « on »
>>
>> Optional members : d rôle « under »
>>
>> a=id du point  début du pont  (son PK debut)
>>
>> b=id du point fin du pont (son PK fin)
>>
>> c=id du tronçon de voie supportant la relation
>>
>> d=id du tronçon de la voie traversée (rivière, chemin, route, …)
>>
>> C’est clair qu’il y a du boulot pour des applications pour transformer
>> ces relations en objets découpés suivant les pointillés.
>>
>
> Dans ton exemple, la portion de voie ferrée de type pont-rail est 
> définie par ses bornes, sous forme de nodes : a et b. Une autre 
> manière, même sans node, consiste à définir le pont avec 2 abscisses 
> curvilignes, à partir d'un way dont une extrémité serait le "PK 0". 
> Dans ce cas, on pourrait dire : le pont rail commence au PK 7.5 et se 
> termine au PK 7.6, c'est à dire : le pont rail commence à 7.5km du 
> début du way et mesure 100m.
> Ces 2 manières de dire la même chose souffrent du même bémol : il ne 
> faut pas que la référence (le way) bouge, sinon l'objet pont-rail 
> bouge aussi.
> Dans le premier modèle, il suffit de bouger par exemple le node a pour 
> déplacer le début du pont-rail. Dans le second, si je raffine la 
> courbure de la voie ferrée, j'augmente la longueur du way, et je 
> déplace l'endroit situé à 7.5 km du début.
> Dans les deux cas on est face à, j'ai l'impression, une contradiction 
> : la segmentation dynamique requiert une stabilité du référentiel 
> géométrique pour que les objets définis relativement à cette géométrie 
> soient stables, et à l'inverse, dans OSM, chacun est libre de modifier 
> tous les objets, rien n'est figé/vérouillé.
> Du coup est-ce compatible, au stade des contributions ? C'est 
> différent au stade de la réutilisation, où chacun est libre de définir 
> des objets (des 'évènements') relativement au graphe OSM, dès lors que 
> celui-ci a été extrait une fois et figé pour servir de référence.

La stabilité du référentiel géométrique dans le cadre d'un projet 
collaboratif ouvert relève du domaine de la foi (et non pas de la 
doctrine). Cela ne concerne pas que cette histoire de segmentation 
dynamique. Qu'un attribut vienne à disparaïtre, une coordonnée de noeud 
soit déplacée, de manière intentionnelle ou non, et toute application se 
servant des données OSM se trouve potentiellement malmenée. Nous 
disposons d'outils de surveillance qui deviennent de plus en plus 
efficaces parce qu'à mesure que la taille de la base, les usages 
-notamment dans des environnement professionnels- croissent, les 
exigences sont toujours plus prégnantes.
La tentation est donc de ne mettre dans la base que le substrat, le 
terreau sur lequel les réutilisateurs de tous poils viendront planter 
leurs graines. C'est la vision minimaliste et une question récurrente 
sur les listes de discussion : jusqu'où aller dans la description du 
réel, quel niveau de détail, quelle homogénéité, quels usages ?
Selon moi, il y a triple réflexion :
- organiser la base (ontologie) de la manière la plus rationnelle et 
consensuelle possible, quitte à innover avec les relations au détriment 
de l'acception courante des applications ; c'est le modèle de données 
qui doit être le moteur car il essaie de traduire les visions multiples 
de nos réalités complexes ;
- veiller à ce que la base soit conforme à un minimum de modélisation 
(documentée) commune. Sans parler de labellisation, on peut chercher à 
évaluer (donner de la valeur) le niveau de conformité par rapport à nos 
règles (osmose est probablement un des meilleurs démonstrateurs de cette 
veille -surveillance-) ;
- adapter dans le temps l'ambition de 1 aux ressources nécessaires en  2 
: accompagnement au changement.

Après avoir enfoncé ces portes ouvertes, et si je t'ai bien compris, 
réserve-t-on l'ontologie commune (donc minimale) aux contributeurs et 
les ontologies spécialisées aux réutilisateurs ?
Je crois qu'OSM peut être, outre un lieu d'intégration de données, un 
creuset de savoirs de tous les acteurs, une lunette géante qui 
corrigerait tous les défauts d'astigmatisme, de myopie, d'ambiopie, etc. 
et qui serait gratuite pour tous.

Denis, pas en charge du budget de la Sécu