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
