Pour les rencontres, ça va être délicat là où je suis (les kilomètres...)...
J'ai de bonnes raisons pour qu'on onclue simultanément les deux modèles. Particulièrement pour cette base de données qui est et restera en évolution permanente, et dans laquelle on aura toujours des lacunes. Avoir les deux permet de les combler au moins partiellement selon un axe vertical dans l'arbre (les surfaces hiérarchisées), ou selon un axe horizontal dans l'arbre (l'ensemble des frontières d'un même niveau). On peut progresser simultanément dans les deux directions pour aboutir à une convergence. Un moteur de rendu de tuiles n'a normalement besoin que des frontières, mais si des frontières (ways, "boundary_segments", multilinestring en GIS: axe horizontal de l'arbre) manquent dans une relation, ou ne sont pas fermées, il peut alors de façon paliative (uniquement paliative) utiliser l'autre axe vertical (surfaces, "subareas"). Si on a une définition des "subareas" complètes (ou tout autre rôle qu'il serait utile de mettre si on veut renseigner plusieurs types de partitionnement de la surface mère) et pas encore de frontières, un moteur peur facilement remonter les frontières à la relation mère, et ajouter un "FIXME" pour vérifier cette frontière ajoutée automatiquement (uniquement dans le cas où la relation mère n'a pas de frontière définie, et uniquement si le rôle (subarea) le permet (mais une interdiction peut être mise en indiquant une propriété dans la relation mère, au cas où les subareas ne sont volontairement pas (ou pas encore) une partition complète de la surface définie par la relation mère (cas où il manque encore des subareas membres dans la relation mère). A mon avis un robot vérificateur ne doit pas faire cette remontée sans supervision humaine (il peut produire une liste, un humain ajoute des tags pour indiquer ce que le robot peut faire ou pas, le robot passe faire la modif demandée et revérifie en mettant à jour sa liste). De même, si on a une définition des frontières complètes dans la relation mère, un robot vérificateur peut faire la remontée des subareas avec le bon rôle en utilisant la définition des frontières trouvées par une recherche spaciale (attention: c'est seulement une heuristique! le contrôle humain reste nécessaire aussi, comme le prouve Nominatim qui fait ce type de recherches extrêmement lourdes à calculer et qui nécessite de charger et calculer un volume énorme de données depuis la base OSM). Le 26 janvier 2012 09:37, Romain MEHUT <romain.me...@gmail.com> a écrit : > 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
