Le 2 décembre 2012 19:47, Pierre Béland <infosbelas-...@yahoo.fr> a écrit :
> >Je ne suis pas très fan de cette couche. Ce qui à mon avis doit définir > une way comme limite administrative est son >appartenance à une relation de > limites administrative. Pour moi les tags sur les ways sont désuets. > > Frédéric, le but d'utiliser cette couche est justement pour repérer les > chemins de limites admistratives sans relation et corriger en conséquence. > > Voir cet exemple où des chemins de limites se chevauchent dont certains ne > sont pas définis dans une relation > > http://layers.openstreetmap.fr/?zoom=12&lat=45.41025&lon=-73.41898&layers=B00FFFFFFFFFFFFTFFFFFFT&item=xxxx&level=1 > Et voilà une démonstration évidente que cette dénormalisation des données, où les chemins indiquent par eux même pourquoi ils ont été créés, indépendemment des relations qui les utilisent ou non, aide à solidifier le schéma. Et même si en fin de compte un moteur de rendu ou de recherche des surfaces ne tiendra pas compte des attributs de ces chemins mais uniquement des relations, c'est une grande aide pour les utilisateurs des éditeurs, car on a sans arrêt des relations brisées : si on n'a plus que des chemins totalement anonymes et sans aucun attribut, comment distinguer dans cet écheveau de traits ce qui devait être une frontière et à quoi servait tel ou tel trait ? Je suis favorable à la conservation de cette dénormalisation des relations vers les chemins, et même à la correction systématique de ces attributs selon quelques règles : - tout chemin utilisé par une ou plusieurs relations de frontière doit porter un attribut "boundary=*" - cet atttribut doit être "boundary=administrative" si parmi ces relations il y en a au moins une ayant cet attribut - sinon cet atttribut doit être "boundary=political" si parmi ces relations il y en a au moins une ayant cet attribut - si ce chemin porte "boundary=administrative" alors ce chemin doit porter un attribut "admin_level=*". Cet attribut doit être la plus petite valeur parmi les "admin_level" des relations de frontières administratives utilisant ce chemin. - sinon si ce chemin porte "boundary=political" alors ce chemin doit porter un attribut "political_division=*". Cet attribut doit être une des valeurs du même attribut parmi les relations boundary=political utilisant ce chemin ; la plupart du temp on n'aura qu'une seule valeur (canton...), mais on peut aussi les énumérer en séparant par des point-virgules. - ce chemin devrait aussi porter un nom. Mais ce nom dépend du fait qu'il soit ou non lié à un autre usage physique qu'une simple frontière "virtuelle", donc si ce chemin est un waterway=* ou highway=* ou railway=* ou landuse=* ou natural=* ou building=* ou man_made=* non n'y touche pas car le nom désigne autre chose que la frontière elle-même ; pour cela on regarde dans ce chemin la liste des autres attributs qui ne sont pas utilisés spécifiquement pour les frontières (boundary, admin_level, political_division, ...) ou qui ne sont pas génériques pour n'importe quel objet (name:*, *_name:*, ref:*, source:*, url:*, website:*, note:*, comment:*, fixme:*, FIXME:*), ou si c'est un attribut privé (les CLC:* de Corine par exemple) et s'il reste des attributs hors de cet ensemble, ce chemin sert aussi à autre chose, on ne touchera donc pas à ce nom Sinon on pourra le nommer de façon systématique en tant que frontière uniquement. - le nom à donner (name=*) pour ce chemin est le formé par la juxtaposition des noms par défaut (name=*) des deux entités ayant l'admin_level déterminé précédemment (l'ordre importe peu, mais on peut aussi choisir d'unformiser en les mettant dans un ordre alphabétique, ou si les relations adjascentes se partageant le chemin ont des populations connues, mettre en premier la relation la plus peuplée, ou encore celle dont la surface est la plus grande ; ce critère doit être stable, ce qui n'est pas le cas d'un tri en fonction du nombre de chemins découpant une frontière) ; on sépare par un caractère bien distinctif les noms des deux entités : le tiret cadratin convient très bien pour ça. Contrairement à ce qui a été prétendu ici par certains, on a bien un critère déterministe permettant de choisir le niveau à retenir parmi les paires de relations adjascentes qui se partagent le chemin. Résultat : plus aucun chemin anonyme dont on se demande ensuite à quoi il sert. Le schéma reste utilisable pour une utilisation en mode "filaire" (en ignorant les surfaces, les collections donc toutes les relations), ce qui facilite aussi la réutilisation de la base de données (alors qu'en voulant tout normaliser, il est IMPOSSIBLE d'utiliser la base de données sans avoir à charger TOUTES les relations dépendantes, partout, sans même avoir la possibilité de faire une requête géométrique sur elles puisque les relations n'ont aucune géométrie par elles-mêmes, mais seulement indirectement par leur liste de membres et uniquement quand ils ont chacun une géométrie propre, donc quand ces membres ne sont QUE des noeuds et des chemins). ---- C'est le défaut actuel du schéma OSM de ne pas pouvoir représenter les surfaces avec des objets bien spécifiques, mais uniquement comme des relations-collections "fourre-tout" (alors que si on avait de VRAIS multipolygones et multilinestrings, leurs membres ne seraient JAMAIS vides, mais ne serait QUE des chemins, et les VRAIS multiplygones seraient TOUJOURS fermés (sinon erreur de violation d'intégrité référencielle dans la base OSM, y compris si quelqu'un essaye de supprimer un chemin utilisé par des multipolygones, sans d'abord supprimer ces mutlipolygones ou les modifier en en supprimant un des "anneaux" fermés utilisant ce chemin). TANT QUE la base OSM n'aura pas ces vrais objets OpenGIS en tant que primitives géométriques, mais seulement de vagues "relations", et ne permettra donc pas d'assurer l'intégrité référencielle, une dénormalisation de certains attributs des relations vers les chemins RESTERA indispensable, pour en assurer la solidité. Noter alors que les VRAIS multilinestrings et multipolygones (pas les relations actuelles) n'ont que des membres homogènes, tous des chemins, et qui n'ont aucun "rôle" (ou plutôt c'est nécessairement le même pour tous). Les rôles "inner" et "outer" n'ont aucun sens dans un multilinestring ; cesrôles n'en ont pas plus non plus au niveau de chaque chemin membre (le sens "inner" ou "outer" est un attribut des seuls anneaux, en fonction de leur inclusion mutuelle au sein de la relation mutilipolygone, et qui permet de savoir de quel côté de l'anneau se trouve la surface que délimite l'anneau). Il ne resterait alors des relations que pour les collections (et non listes) de membres non homogènes, sans plus AUCUNE notion d'ordre pour les relations, mais avec pour chaque membre un rôle unique pour toute la collection : pour garantir cette unicité, la base devrait aussi avoir un objet homogène "multipoint" (ne contenant QUE des noeuds, sans aucun ordre parmi eux). On peut aller plus loin pour encore simplifier, en créant un objet intermédiaire "ring" (anneau) pour rassembler dans un même objet une liste de chemins formant un unique anneau fermé et sans aucune intersection, le multipolygone devenant une collection non ordonnée de "rings" (eux aussi toujours sans aucun rôle, sauf que les anneaux inclus peuvent se toucher, y compris le long d'un chemin de longueur non nulle, mais PAS se croiser). Les actuels chemins fermés seraient automatiquement dans un "ring" ne comportant qu'un seul chemin membre. Les chemins aussi devraient être distingués dans la base parmi ceux qui sont orientés ou non : les chemins orientés ne peuvent PAS être membres d'un anneau (réservé à la description de limites de surfaces). Plus besoin alors de l'attribut "area=yes/no". Et plus besoin non plus d'inclure le même nœud deux fois dans un chemin qui est un anneau, il n'y a plus de notion de "premier" ou "dernier" noeud dans un anneau qui est forcément fermé, la base supprime automatiquement ce doublon inutile dès qu'un chemin fermé est défini en tant qu'anneau non orienté (cette normalisation forcée va plus loin que ce qu'impose OpenGIS) : la liste des noeuds d'un anneau reste ordonnée cependant mais n'admet aucune intersection ni aucun noeud en doublon. L'anneau devient une sous-classe particulière parmi les chemins, et reste topologiquement un chemin même si la liste des membres d'un anneau est faite SOIT d'une liste ordonnée (et sans doublons) de plusieurs chemin non fermés (et uniquement de chemins), SOIT d'un d'unique chemin implicite (lui-même) avec pour membre une liste ordonnée de noeuds (eux ausi sans aucun doublon). Ce qui veut dire que la base OSM pourrait même réduire largement le volume nécessaire en réduisant le volume nécessaire pour les relations. Et on ne passerait plus son temps à corriger les trous dans les frontières ou surfaces. Et ce serait SEULEMENT dans ce cas, que les dénormalisations d'attributs seraient alors inutiles et même indésirables. De plus la base OSM serait alors automatiquement conforme OpenGIS, en simplifiant énormément les utitlisations puisqu'on n'aurait plus à les convertir lors des exports. Une telle base pourrait encore présenter une "vue" compatible avec le schéma actuel pour les outils OSM qui ne reconnaîtraient pas ces nouvelles primitives, en transformant automatiquement les VRAIS multipoints, multilinestrings, rings, et multipolygones en "relations" dans les résultats des requêtes utilisant une API compatible, mais PAS avec l'API normalisée. Une telle vue peut tout à fait permettre une compatibilité totale (en gardant aussi, de façon transitoire, et en tant que pseudo-primitives, les actuelles "relations" qui ne sont pas représentables selon ces nouvelles contraintes). La base serait alors nativement dans un schéma OpenGIS, avec toute une série de possibilités nouvelles pour effectuer des requêtes géométriques (notamment recherche d'objets dans une zone géométrique délimitée, ce que la base ne sait faire QUE sur les seuls noeuds, et au prix du stockage dénormalisé, dans ses index, d'objets "bounding box" approximatifs pour tenter de rechercher des chemins, et aucun autre support pour les relations que les listes de membres hétérogènes), comme dans les bases OpenSQL+OpenGIS qu'on doit construire avec les trop lourds outils d'exports. Les fichiers d'exports/imports seraient aussi beaucoup plus légers, de même que les imports et requêtes d'ajout/modifications faites par les éditeurs .avec la nouvelle API normalisée Mais on n'a toujours pas tout ça ! Résultat : des dénormalisations sont indispensables, sinon plus moyen d'assurer une intégrité stable des données permettant de réparer les trous laissés par les éditeurs et que la base est incapable de vérifier.
_______________________________________________ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
