[OSM-talk-fr] Réflexions sur la modélisation dans osm des niveaux administratifs en france

[Philippe Verdy]

Le 25 janvier 2012 18:09, Pieren <pieren3 at gmail.com> a écrit :
> 2012/1/25 Vincent de Chateau-Thierry <vdct at laposte.net>:
>
>> Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux
>> ajouts de type "subarea" dans les relations Paris et Val de Marne, pour la simple raison
>> que de tels ajouts se sont multipliés depuis hier :
>>
>> la Vienne :
>> http://www.openstreetmap.org/browse/relation/7377
>> Poitou-Charente :
>> http://www.openstreetmap.org/api/0.6/relation/8652
>> Seine-et-Marne :
>> http://www.openstreetmap.org/api/0.6/relation/7383
>>
>> etc, etc.
>>
>> Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il sera proposé.
>> Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions alternatives (ne
>> pas squatter les relations existantes, avant tout), ce qui ne réunit pas les conditions
>> minimales d'une discussion. Un jour peut-être.
>
> Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des
> modifs semble d'accord pour une séparation des modèles dans des
> relations différentes à minima ?

Tout d'abord je comprend très bien l'intérêt de la méthode de
construction par niveaux indépendants qui favorise la modélisation par
frontières. Je n'ai absolument rien à critiquer là-dessus. Cette
méthode permet effectivement de construire 100% d'un niveau et de
vérifier qu'il n'y a doublon des surfaces couvertes (intersections),
ni surfaces oubliées pour un niveau donné. Oui effectivement elle
permet de construire chaque niveau indépendamment de tous les autres.
De même elle permet de détecter au sein d'un même niveau les
frontières mitoyennes définies par des ways (ou boundary_segments si
on les utilise, débat séparé)  superposés: la méthode demandée veut
qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au
delà: on obtient une couche séparée pour ce niveau.

Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec
une couverture totale, pas de doublons, qu'elle est de qualité. Car on
me dit d'utiliser une requête spaciale pour trouver les inclusions
entre niveaux. En particulier, les frontières définies par un niveau
sont aussi réutilisées pour définir les niveaux inférieurs: en
travaillant sur un niveau donné, on peut très bien obtenir le niveau N
100% complet, et avoir tout cassé aux niveaux 1 à N-1...

De même, il n'y a strictement rien avec le modèle qui utilise
UNIQUEMENT les frontières pour recoller les niveaux entre eux: par
exemple quel propriété "boundary_level" doit être mise dans les ways
(ou boundary-segments si on les crée) ? Il n'y a aucune méthode pour
vérifier que ces boundary_level sont corrects.

De même, un ensemble de surfaces (définies par frontières) définies
dans un niveau N+1 et qui devraient former une partition du niveau N,
ne le font pas: la requête spacile échoue (et on se retrouve donc avec
l'Ille-et-Vilaine qui n'est pas en Bretagne car des morceaux en
dépassent. Le modèle avec *uniquement* les frontières ne permet pas le
contrôle de cohérence. On aboutit alors aux aberrations produites par
Nominatim (qui cherche alors une heuristique afin de déterminer quelle
région contient le plus probablement l'Ille-et-Vilaine, basée sur les
distances entre centroïdes, une heuristique qui est largement fausse
et produit de nombreuses erreurs; on pourrait améliorer l'heuristique
en calculant la surface (en mètres carrés ou autre unité de surface)
commune, mais un tel calcul est bien plus lourd car cela suppose
d'abord déterminer les intersections de surfaces polygonales, avant de
calculer la surface par décomposition en triangles élémentaires:
calcul très complexe que Nominatim ne fera sans doute jamais).

Je ne veux pas dire qu'il faut supprimer les frontières: je veux
garder les deux comme un outil de vérification mais aussi de
consultation de la base de données ave des requêtes simples non
spaciales. Ce que je défend reste la méthode de construction d'un
niveau donné commençant d'abord par le modèle à frontières, qu'il font
conserver dans les données. Si on représente la topologie des
relations obtenues, on dessine un arbre des surfaces en commençant par
tous les noeuds de l'arbre représentant les zones d'un même niveau,
ces niveaux consituant l'axe horizontal de l'arbre hiérarchique
virtuel.

Maintenant on a toutes les couches horizontales créées, on les recolle
sur le plan vertical en libellant explicitement les branches de
l'arbre virtuel: c'est un ajout que l'on fait, on ne supprime pas les
frontières du tout (les ways actuels, ou les boundary_segments
proposés) ! Cet ajout évite d'avoir recours ensuite systémantiquement
aux requêtes spaciales très lourdes et aux heuristiques pour gérer les
ambiguités (cas des surfaces de niveaux différents qui se chevauchent
géométriquement). Cette couche permet de vérifier la cohérence des
niveaux différents entre eux.

Je n'ai jamais milité pour la construction n'utilisant QUE le modèle
par surface, mais je ne milite pas non plus pour celle n'utilisant QUE
le modèle par frontières. Les deux devraient être présents (d'autant
que dans certains cas, il est normal et même attendu que les
chevauchements surviennent, à priori pas entre départements et régions
françaises, mais bien entre EPCI et départements, ou EPCI et régions,
et d'autres cas se présentent avec les "eaux intérieures" (pour les
limites côtières sur la ligne de base, étendue par les digues,
barrages, surfaces découvertes à marée basse, gués, terres
inondables).


Mais si on me demande de créer des relations séparées, cela ne va pas
du tout: tout l'intérêt est perdu de ces relations verticales, et on
se retrouve avec par exemple deux relations pour représenter la même
région, l'une contenant uniquement les frontières externes de la
région, l'autre contenant uniquement une énumération des départements
(qu'il faudra ensuite dédoubler eux aussi...) Pas question de cela !
La même relation représentant la région peut contenir à la fois la
définition de ses frontières externes (définition horizontale dans
l'arbre hiérarchique), et inclure la liste de ses membres (définition
verticale dans l'arbre hiérarchique des niveaux). Les deux se
complètent, mais ne se déduisent PAS l'un de l'autre (il y a plein de
raisons pour cela), comme certains le supposent (à tord: il semble
vrai en apparence qu'on peut déduire les relations verticales
hiérarchiques de la définition par frontières, mais dans le détail
cela ne marche pas, et c'est extrêmement lourd à calculer).

Il reste aussi que des tonnes de données géographiques externes
utilisent le modèle par surface. Je ne veux pas privilégier un modèle
contre l'autre: les deux se complètent très bien (et ne servent pas à
la même chose).

En disposer ne même temps permet aussi des contrôles de cohérence, et
permet aussi de réparer des zones cassées, par exemple:
- des frontières (définition horizontale par niveau dans l'arbre
hiérarchique) ne sont plus fermées par la suppression par erreur d'un
way dont on n'a pas pu charger toutes les relations qui l'utilisent
(notamment les relations régions et pays car cela concerne des
centaines de ways et des dizaines de milleirs de noeuds voire beaucoup
plus, ce que le serveur OSM ne peut pas supporter.
- des surfaces ne sont plus contenues l'une dans l'autre (définition
verticale dans l'arbre hiérarchique) quand elles le devraient (d'où
les erreurs de type Nominatim qui cherche une approximation
heuristique, qui ne peut jamais être 100% exacte).

La définition des relations hiérarchiques (par surface) est en terme
de volume de données stockées dans la base très minime en comparaison
de la définition des frontières (qui actuellement n'utilise que les
ways, d'où une duplication énorme de données, qui ne fait qu'empirer
avec le temps, sauf si plus tard on se met à admettre le support des
"boundary_segments", qu'on peut aussi appeler "MultiLineString" en
terminologie GIS, et avec lesquels il va bien falloir se mettre !).
Les ajouter aux relations n'aura pas d'impact significatif (l'impact
est bien supérieur au moment où on ajoute des couches de niveaux, et
quand on se met à partager des ways pour mixer à la fois la géographie
administrative et la géographie physique, une erreur grave à mon avis,
alors que ce partage ne devrait exister QUE sur les points
géodésiques, mais PAS sur les lignes de côtes physiques, les rives de
fleuves, les routes, ponts, jetées, forêts, bâtiments...).

Disposer des deux modèles solidifie le schéma, permet de le certifier,
permet l'exploitation des cartes par des logiciels tiers ou aux fins
statistiques. Il permet aussi à ceux qui modifient les cartes à un
niveau N de ne pas oublier de modifier des relations de niveaux
supérieurs ou inférieurs, sans que ceux-ci aient à charger la totalité
des données contenues dans des rectangles très larges. Il n'a alors
pas à s'occuper de charger les maisons, rivières, routes, commerces,
terrains "landuse". Il travaille sur le plan administratif, ou sur le
plan physique, que sur des ensembles de couches qui doivent
normalement être indépendantes les un des autres, en ne demandant que
peut de données au serveur, qui sera capable de les lui retourner avec
des requêtes simples (il ne sera nécessaire de charger tous les types
de données dans une zone que pour résoudre des conflits dans des
toutes petites zones où on détecte une ambiguité ou une erreur entre
la définition hiérarchique horizontale par frontières et la définition
vertical par surface).

Le rendu des tuiles n'a pas besoin de charger la définition par
surfaces: celle par frontières suffit oui. Mais on ne se contente pas
de produire des données OSM pour faire un rendu de tuiles. Dès qu'on
cherche à exploiter une carte dans une application réelle (là je parle
des utilisateurs de la cartes, pas de ceuw qui créent ou modifient les
cartes), on se pose en permanence la question : dans quoi (quelle
relation de boundary ?) est situé tel ou tel objet (noeud, ways,
surface) ? Et c'est là que le modèle uniquement par frontières trouve
ces limites, car il ne produit pas la réponse (objet non trouvé alors
qu'il y est bien !), ou produit des réponses incorrectes (heuristiques
: mauvais objets retournés par la requête spéciale), ou encore le
serveur n'est pas capable de supporter la charge de cette requête
(nécessite le chargement de dizaines de milliers de noeuds et ways,
parfois plus).

On a exactement la même problématique hors des zones administratives,
avec d'autres données géolocalisées comme les réseaux de transport,
plans d'aménagement du territoire, découpages de territoires non
administratifs ou hors du découpage "principal" (de type NUTS). D'où
sans arrêt les débat entre les deux modèles, dès que certains ne
veulent privilégier qu'un seul des deux modèles, alors que les deux se
complètent et se solidifient entre eux pour des usages différents (on
utilise soit un type de recherche, soit l'autre, mais pas les deux en
même temps pour un même niveau de couverture). C'est ce que je veux
faire comprendre:

Le modèle par surfaces (le plus économe en volume de données stockée
en comparaison du modèle par frontières qui nécessite encore une
duplication énorme de données sauf si on admet les "boundarysegments"
ou "Multilinestring") correspond à la modélisation hiérarchique
verticale des arbres, le modèles par frontières correspond à la
modélisation horizontale. N'avoir que l'un ou l'autre ne répond pas à
tous les problèmes, et dans les DEUX cas, le modèle utilise reste très
fragile et instable face aux modifications parcellaires qui rendent
les données incohérentes avec la réalité, et DIFFICILES à réparer.

Mais dire que la modélisation par ways et celle par surfaces est
équivalente est faux: elles ne sont ABSOLUMENT PAS duales l'une de
l'autre.

Le seul véritable dual (terme mathématique : cherchez les références
en géométrie pour comprendre, ou bien dans la documentation relative
aux topologies réseaux, au encore dans la documentation du traitement
numérique des images pixellisées et des effets photographiques
numériques...) de la modélisation par surfaces, c'est la modélisation
par frontières utilisant les boundary_segments (ou multilinestring en
termes GIS, mais eux-mêmes aussi définitions de façon relationnelle,
sans duplication d'aucune liste des ways qui composent chaque segment,
puisqu'il faudrait que chaque segment soit décomposables en
sous-segments eux aussi de niveaux différents et formant eux-aussi un
arbre).

Mais visiblement nos logiciels ne sont pas encore prêts à les accepter
(alors qu'ils n'ont pas de problème à gérer et ignorer les données du
modèle par surfaces), même si on n'utilise QUE des boundary_segments
dupliquant des sous-listes de ways (donc pas encore eux-mêmes
structurés eux aussi en arbres).

Donc en attendant d'avoir des chemins structurés hiérarchiquement (de
façon relationnelle aussi, et pas uniquement de simples listes
ordonnées de noeuds), les données par surface sont indispensables (et
peuvent fonctionner immédiatement : les surfaces structurées
hiérarchiquement sont même bien plus simples à modéliser (et
comprendre aussi) que les chemins linéaires structurés
hiérarchiquement, qui restent "imaginaires" et n'existent pas dans la
réalité (sauf pour les données de frontières administratives: traités
internationaux, cadastres...) mais ces lignes imaginaires n'ont aucune
manifestation physique qu'on puisse voir sur les photos même les plus
fines, hormi les repères géodésiques (si on leur accorde une
signification au niveau d'un seul noeud, mais strictement jamais sur
une ligne elle aussi imaginaire, ni sur une surface bien réelle où ils
auraient été construits sur le terrain).

Alors oui je veux bien qu'on suspende l'utilisation des
"boundary_segments" les modéliser avec les relations actuelles est une
erreur qui conduit à des ambiguités topologiques. Mais en revanche
l'utilisation des relations pour structurer les surfaces a bel et bien
un sens: les relations ont été conçues pour ça (entre autres) et aussi
pour définir des jeux de métadonnées (avec pour chaque jeu un "rôle"
distinctif) qui ne tiennent pas dans des propriétés (à valeurs simple:
un nom, un identifiant, un nombre, une date) de l'objet mais dans des
collections énumérables de valeurs multiples (à priori non ordonnées
entre elles dans un même rôle) : alors le "rôle" a la même fonction
dans un objet que celle que joue la "clé" dans les propriétés à
valeurs simples de cet objet.