Bonjour à tous, 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...?
Romain Le 26 janvier 2012 09:33, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Le 25 janvier 2012 18:09, Pieren <pier...@gmail.com> a écrit : > > 2012/1/25 Vincent de Chateau-Thierry <v...@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. > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
