Bonjour à tous,<br><br>Cela fait un moment que je suis dépassé par cette discussion interminable. Est-ce qu'il ne serait pas intéressant que les différents "protagonistes" se rencontrent pour en discuter de vive-voix et avec des exemples à l'appui...?<br>
<br>Romain<br><br><div class="gmail_quote">Le 26 janvier 2012 09:33, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 25 janvier 2012 18:09, Pieren <<a href="mailto:pieren3@gmail.com">pieren3@gmail.com</a>> a écrit :<br>
<div class="im">> 2012/1/25 Vincent de Chateau-Thierry <<a href="mailto:vdct@laposte.net">vdct@laposte.net</a>>:<br>
><br>
>> Contrairement à ce que je disais hier soir, je n'ai en revanche pas touché aux<br>
>> ajouts de type "subarea" dans les relations Paris et Val de Marne, pour la simple raison<br>
>> que de tels ajouts se sont multipliés depuis hier :<br>
>><br>
>> la Vienne :<br>
>> <a href="http://www.openstreetmap.org/browse/relation/7377" target="_blank">http://www.openstreetmap.org/browse/relation/7377</a><br>
>> Poitou-Charente :<br>
>> <a href="http://www.openstreetmap.org/api/0.6/relation/8652" target="_blank">http://www.openstreetmap.org/api/0.6/relation/8652</a><br>
>> Seine-et-Marne :<br>
>> <a href="http://www.openstreetmap.org/api/0.6/relation/7383" target="_blank">http://www.openstreetmap.org/api/0.6/relation/7383</a><br>
>><br>
>> etc, etc.<br>
>><br>
>> Je suis tout à fait prêt à discuter du modèle par surfaces, le jour où il sera proposé.<br>
>> Pour l'instant, il est plutôt imposé (litote) au mépris des suggestions alternatives (ne<br>
>> pas squatter les relations existantes, avant tout), ce qui ne réunit pas les conditions<br>
>> minimales d'une discussion. Un jour peut-être.<br>
><br>
> Et donc on ne fait rien ? Alors que tout le monde à part l'auteur des<br>
> modifs semble d'accord pour une séparation des modèles dans des<br>
> relations différentes à minima ?<br>
<br>
</div>Tout d'abord je comprend très bien l'intérêt de la méthode de<br>
construction par niveaux indépendants qui favorise la modélisation par<br>
frontières. Je n'ai absolument rien à critiquer là-dessus. Cette<br>
méthode permet effectivement de construire 100% d'un niveau et de<br>
vérifier qu'il n'y a doublon des surfaces couvertes (intersections),<br>
ni surfaces oubliées pour un niveau donné. Oui effectivement elle<br>
permet de construire chaque niveau indépendamment de tous les autres.<br>
De même elle permet de détecter au sein d'un même niveau les<br>
frontières mitoyennes définies par des ways (ou boundary_segments si<br>
on les utilise, débat séparé)  superposés: la méthode demandée veut<br>
qu'on évite de superposer les ways d'un même niveau. Elle ne va pas au<br>
delà: on obtient une couche séparée pour ce niveau.<br>
<br>
Cependant ce n'est pas parce qu'un niveau parait 100% terminé, avec<br>
une couverture totale, pas de doublons, qu'elle est de qualité. Car on<br>
me dit d'utiliser une requête spaciale pour trouver les inclusions<br>
entre niveaux. En particulier, les frontières définies par un niveau<br>
sont aussi réutilisées pour définir les niveaux inférieurs: en<br>
travaillant sur un niveau donné, on peut très bien obtenir le niveau N<br>
100% complet, et avoir tout cassé aux niveaux 1 à N-1...<br>
<br>
De même, il n'y a strictement rien avec le modèle qui utilise<br>
UNIQUEMENT les frontières pour recoller les niveaux entre eux: par<br>
exemple quel propriété "boundary_level" doit être mise dans les ways<br>
(ou boundary-segments si on les crée) ? Il n'y a aucune méthode pour<br>
vérifier que ces boundary_level sont corrects.<br>
<br>
De même, un ensemble de surfaces (définies par frontières) définies<br>
dans un niveau N+1 et qui devraient former une partition du niveau N,<br>
ne le font pas: la requête spacile échoue (et on se retrouve donc avec<br>
l'Ille-et-Vilaine qui n'est pas en Bretagne car des morceaux en<br>
dépassent. Le modèle avec *uniquement* les frontières ne permet pas le<br>
contrôle de cohérence. On aboutit alors aux aberrations produites par<br>
Nominatim (qui cherche alors une heuristique afin de déterminer quelle<br>
région contient le plus probablement l'Ille-et-Vilaine, basée sur les<br>
distances entre centroïdes, une heuristique qui est largement fausse<br>
et produit de nombreuses erreurs; on pourrait améliorer l'heuristique<br>
en calculant la surface (en mètres carrés ou autre unité de surface)<br>
commune, mais un tel calcul est bien plus lourd car cela suppose<br>
d'abord déterminer les intersections de surfaces polygonales, avant de<br>
calculer la surface par décomposition en triangles élémentaires:<br>
calcul très complexe que Nominatim ne fera sans doute jamais).<br>
<br>
Je ne veux pas dire qu'il faut supprimer les frontières: je veux<br>
garder les deux comme un outil de vérification mais aussi de<br>
consultation de la base de données ave des requêtes simples non<br>
spaciales. Ce que je défend reste la méthode de construction d'un<br>
niveau donné commençant d'abord par le modèle à frontières, qu'il font<br>
conserver dans les données. Si on représente la topologie des<br>
relations obtenues, on dessine un arbre des surfaces en commençant par<br>
tous les noeuds de l'arbre représentant les zones d'un même niveau,<br>
ces niveaux consituant l'axe horizontal de l'arbre hiérarchique<br>
virtuel.<br>
<br>
Maintenant on a toutes les couches horizontales créées, on les recolle<br>
sur le plan vertical en libellant explicitement les branches de<br>
l'arbre virtuel: c'est un ajout que l'on fait, on ne supprime pas les<br>
frontières du tout (les ways actuels, ou les boundary_segments<br>
proposés) ! Cet ajout évite d'avoir recours ensuite systémantiquement<br>
aux requêtes spaciales très lourdes et aux heuristiques pour gérer les<br>
ambiguités (cas des surfaces de niveaux différents qui se chevauchent<br>
géométriquement). Cette couche permet de vérifier la cohérence des<br>
niveaux différents entre eux.<br>
<br>
Je n'ai jamais milité pour la construction n'utilisant QUE le modèle<br>
par surface, mais je ne milite pas non plus pour celle n'utilisant QUE<br>
le modèle par frontières. Les deux devraient être présents (d'autant<br>
que dans certains cas, il est normal et même attendu que les<br>
chevauchements surviennent, à priori pas entre départements et régions<br>
françaises, mais bien entre EPCI et départements, ou EPCI et régions,<br>
et d'autres cas se présentent avec les "eaux intérieures" (pour les<br>
limites côtières sur la ligne de base, étendue par les digues,<br>
barrages, surfaces découvertes à marée basse, gués, terres<br>
inondables).<br>
<br>
<br>
Mais si on me demande de créer des relations séparées, cela ne va pas<br>
du tout: tout l'intérêt est perdu de ces relations verticales, et on<br>
se retrouve avec par exemple deux relations pour représenter la même<br>
région, l'une contenant uniquement les frontières externes de la<br>
région, l'autre contenant uniquement une énumération des départements<br>
(qu'il faudra ensuite dédoubler eux aussi...) Pas question de cela !<br>
La même relation représentant la région peut contenir à la fois la<br>
définition de ses frontières externes (définition horizontale dans<br>
l'arbre hiérarchique), et inclure la liste de ses membres (définition<br>
verticale dans l'arbre hiérarchique des niveaux). Les deux se<br>
complètent, mais ne se déduisent PAS l'un de l'autre (il y a plein de<br>
raisons pour cela), comme certains le supposent (à tord: il semble<br>
vrai en apparence qu'on peut déduire les relations verticales<br>
hiérarchiques de la définition par frontières, mais dans le détail<br>
cela ne marche pas, et c'est extrêmement lourd à calculer).<br>
<br>
Il reste aussi que des tonnes de données géographiques externes<br>
utilisent le modèle par surface. Je ne veux pas privilégier un modèle<br>
contre l'autre: les deux se complètent très bien (et ne servent pas à<br>
la même chose).<br>
<br>
En disposer ne même temps permet aussi des contrôles de cohérence, et<br>
permet aussi de réparer des zones cassées, par exemple:<br>
- des frontières (définition horizontale par niveau dans l'arbre<br>
hiérarchique) ne sont plus fermées par la suppression par erreur d'un<br>
way dont on n'a pas pu charger toutes les relations qui l'utilisent<br>
(notamment les relations régions et pays car cela concerne des<br>
centaines de ways et des dizaines de milleirs de noeuds voire beaucoup<br>
plus, ce que le serveur OSM ne peut pas supporter.<br>
- des surfaces ne sont plus contenues l'une dans l'autre (définition<br>
verticale dans l'arbre hiérarchique) quand elles le devraient (d'où<br>
les erreurs de type Nominatim qui cherche une approximation<br>
heuristique, qui ne peut jamais être 100% exacte).<br>
<br>
La définition des relations hiérarchiques (par surface) est en terme<br>
de volume de données stockées dans la base très minime en comparaison<br>
de la définition des frontières (qui actuellement n'utilise que les<br>
ways, d'où une duplication énorme de données, qui ne fait qu'empirer<br>
avec le temps, sauf si plus tard on se met à admettre le support des<br>
"boundary_segments", qu'on peut aussi appeler "MultiLineString" en<br>
terminologie GIS, et avec lesquels il va bien falloir se mettre !).<br>
Les ajouter aux relations n'aura pas d'impact significatif (l'impact<br>
est bien supérieur au moment où on ajoute des couches de niveaux, et<br>
quand on se met à partager des ways pour mixer à la fois la géographie<br>
administrative et la géographie physique, une erreur grave à mon avis,<br>
alors que ce partage ne devrait exister QUE sur les points<br>
géodésiques, mais PAS sur les lignes de côtes physiques, les rives de<br>
fleuves, les routes, ponts, jetées, forêts, bâtiments...).<br>
<br>
Disposer des deux modèles solidifie le schéma, permet de le certifier,<br>
permet l'exploitation des cartes par des logiciels tiers ou aux fins<br>
statistiques. Il permet aussi à ceux qui modifient les cartes à un<br>
niveau N de ne pas oublier de modifier des relations de niveaux<br>
supérieurs ou inférieurs, sans que ceux-ci aient à charger la totalité<br>
des données contenues dans des rectangles très larges. Il n'a alors<br>
pas à s'occuper de charger les maisons, rivières, routes, commerces,<br>
terrains "landuse". Il travaille sur le plan administratif, ou sur le<br>
plan physique, que sur des ensembles de couches qui doivent<br>
normalement être indépendantes les un des autres, en ne demandant que<br>
peut de données au serveur, qui sera capable de les lui retourner avec<br>
des requêtes simples (il ne sera nécessaire de charger tous les types<br>
de données dans une zone que pour résoudre des conflits dans des<br>
toutes petites zones où on détecte une ambiguité ou une erreur entre<br>
la définition hiérarchique horizontale par frontières et la définition<br>
vertical par surface).<br>
<br>
Le rendu des tuiles n'a pas besoin de charger la définition par<br>
surfaces: celle par frontières suffit oui. Mais on ne se contente pas<br>
de produire des données OSM pour faire un rendu de tuiles. Dès qu'on<br>
cherche à exploiter une carte dans une application réelle (là je parle<br>
des utilisateurs de la cartes, pas de ceuw qui créent ou modifient les<br>
cartes), on se pose en permanence la question : dans quoi (quelle<br>
relation de boundary ?) est situé tel ou tel objet (noeud, ways,<br>
surface) ? Et c'est là que le modèle uniquement par frontières trouve<br>
ces limites, car il ne produit pas la réponse (objet non trouvé alors<br>
qu'il y est bien !), ou produit des réponses incorrectes (heuristiques<br>
: mauvais objets retournés par la requête spéciale), ou encore le<br>
serveur n'est pas capable de supporter la charge de cette requête<br>
(nécessite le chargement de dizaines de milliers de noeuds et ways,<br>
parfois plus).<br>
<br>
On a exactement la même problématique hors des zones administratives,<br>
avec d'autres données géolocalisées comme les réseaux de transport,<br>
plans d'aménagement du territoire, découpages de territoires non<br>
administratifs ou hors du découpage "principal" (de type NUTS). D'où<br>
sans arrêt les débat entre les deux modèles, dès que certains ne<br>
veulent privilégier qu'un seul des deux modèles, alors que les deux se<br>
complètent et se solidifient entre eux pour des usages différents (on<br>
utilise soit un type de recherche, soit l'autre, mais pas les deux en<br>
même temps pour un même niveau de couverture). C'est ce que je veux<br>
faire comprendre:<br>
<br>
Le modèle par surfaces (le plus économe en volume de données stockée<br>
en comparaison du modèle par frontières qui nécessite encore une<br>
duplication énorme de données sauf si on admet les "boundarysegments"<br>
ou "Multilinestring") correspond à la modélisation hiérarchique<br>
verticale des arbres, le modèles par frontières correspond à la<br>
modélisation horizontale. N'avoir que l'un ou l'autre ne répond pas à<br>
tous les problèmes, et dans les DEUX cas, le modèle utilise reste très<br>
fragile et instable face aux modifications parcellaires qui rendent<br>
les données incohérentes avec la réalité, et DIFFICILES à réparer.<br>
<br>
Mais dire que la modélisation par ways et celle par surfaces est<br>
équivalente est faux: elles ne sont ABSOLUMENT PAS duales l'une de<br>
l'autre.<br>
<br>
Le seul véritable dual (terme mathématique : cherchez les références<br>
en géométrie pour comprendre, ou bien dans la documentation relative<br>
aux topologies réseaux, au encore dans la documentation du traitement<br>
numérique des images pixellisées et des effets photographiques<br>
numériques...) de la modélisation par surfaces, c'est la modélisation<br>
par frontières utilisant les boundary_segments (ou multilinestring en<br>
termes GIS, mais eux-mêmes aussi définitions de façon relationnelle,<br>
sans duplication d'aucune liste des ways qui composent chaque segment,<br>
puisqu'il faudrait que chaque segment soit décomposables en<br>
sous-segments eux aussi de niveaux différents et formant eux-aussi un<br>
arbre).<br>
<br>
Mais visiblement nos logiciels ne sont pas encore prêts à les accepter<br>
(alors qu'ils n'ont pas de problème à gérer et ignorer les données du<br>
modèle par surfaces), même si on n'utilise QUE des boundary_segments<br>
dupliquant des sous-listes de ways (donc pas encore eux-mêmes<br>
structurés eux aussi en arbres).<br>
<br>
Donc en attendant d'avoir des chemins structurés hiérarchiquement (de<br>
façon relationnelle aussi, et pas uniquement de simples listes<br>
ordonnées de noeuds), les données par surface sont indispensables (et<br>
peuvent fonctionner immédiatement : les surfaces structurées<br>
hiérarchiquement sont même bien plus simples à modéliser (et<br>
comprendre aussi) que les chemins linéaires structurés<br>
hiérarchiquement, qui restent "imaginaires" et n'existent pas dans la<br>
réalité (sauf pour les données de frontières administratives: traités<br>
internationaux, cadastres...) mais ces lignes imaginaires n'ont aucune<br>
manifestation physique qu'on puisse voir sur les photos même les plus<br>
fines, hormi les repères géodésiques (si on leur accorde une<br>
signification au niveau d'un seul noeud, mais strictement jamais sur<br>
une ligne elle aussi imaginaire, ni sur une surface bien réelle où ils<br>
auraient été construits sur le terrain).<br>
<br>
Alors oui je veux bien qu'on suspende l'utilisation des<br>
"boundary_segments" les modéliser avec les relations actuelles est une<br>
erreur qui conduit à des ambiguités topologiques. Mais en revanche<br>
l'utilisation des relations pour structurer les surfaces a bel et bien<br>
un sens: les relations ont été conçues pour ça (entre autres) et aussi<br>
pour définir des jeux de métadonnées (avec pour chaque jeu un "rôle"<br>
distinctif) qui ne tiennent pas dans des propriétés (à valeurs simple:<br>
un nom, un identifiant, un nombre, une date) de l'objet mais dans des<br>
collections énumérables de valeurs multiples (à priori non ordonnées<br>
entre elles dans un même rôle) : alors le "rôle" a la même fonction<br>
dans un objet que celle que joue la "clé" dans les propriétés à<br>
valeurs simples de cet objet.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br>