WikiProject France/Limites administratives/Modèle somme de surface ou modèle frontière
De manière récurrente, la communauté française se pose la question de comment rentrer les entités administratives françaises (communes, canton, EPCI, départements, régions, pays, etc.) dans la base de donnée OSM.
Si vous voulez en lire pour plusieurs heures, voici les sujets de discussion sur la liste talk-fr : [1] [2]
que l'on va tenter de résumer ici. (Vous êtes le bienvenu pour améliorer, mais les discussions seront mieux sur La page de discussion)
D'après les discussion deux modèles sont proposés et régulièrement discutés, les voici, avec leurs avantages et inconvénients (plus ou moins supposés ou avéré)
Contents
|
Modèle de somme de surface (subarea)
Ce modèle consiste à utiliser une relation par entité administrative qui contiendrait comme membres l'ensemble des entités administratives de "niveau administratifs" juste un peu plus petits (par exemple, une région aurait comme membres toutes les relations qui représentent les départements) avec un role "subarea".
Modèle de frontière (inner, outer)
Ce modèle (actuellement celui qu'on utilise) consiste à utiliser une relation par entité administrative qui contiendrait comme membres la liste des chemins qui forment le contour de l'entité administrative
Comparaison selon différents points de vue et utilisations
Du point de vu de celui qui rentre les données
Compatibilité avec les autres modèles dans OSM
- Le modèle déjà utilisé dans les autres pays pour les type=boundary, et pour les relations type=multipolygon est le modèle de frontière (A l'exception de waterway=riverbank).
Nombre de membre
- Dans le cas de faible nombre d'entité (régions) dans une autre le Modèle de somme de surface comporte moins de membres
- Dans le cas de grand nombre nombre d'entité (Départements) le Modèle de frontière comporte moins de membres
Nombre d'entité auxquelles appartient un chemin de frontière
- Dans le Modèle de somme de surface, chaque way n'appartient qu'a deux entités administrative (celle les plus petites) c'est donc beaucoup plus simple à gérer que le Modèle de frontière dont chaque way appartient à autant d'entité administratives qu'il en sépare (jusqu'a 16 ou plus pour ceux en frontières de pays)
La proposition Relations/Proposed/boundary_segment tente d'améliorer le Modèle de frontière sur ce point, mais ce n'est pas utilisé et augmente le nombre de relation
Risque qu'un contributeur casse les relations
- avec le Modèle de somme de surface, même si une entité disparaît ou a un contour non fermé, il est toujours possible de construire tout le reste, mais avec un trou. (soit une enclave soit un trou de bordure). Alors que dans le Modèle de frontière si on casse une entité à l'intérieur, il ne se passera rien pour le reste, mais on cassera si l'entité est en bordure de celle du dessus.
En cas de modification du nombre d'échelon
- Avec le modèle de surface, contrairement à celui de frontière, si on veut par exemple rajouter un niveau (après avoir tout terminé) entre admin_level=6 et admin_level=7 (par exemple 6.5) il faut refaire l'étage de liaison qui faisait que une entité de niveau 6 disposait de membres de niveau 7 pour qu'elle ait maintenant des membres de niveau 6.5
Du point de vu de celui qui utilise les données
- Avec le modèle par surfaces, il nous serait impossible actuellement de proposer une couverture France entière des emprises de régions et départements, vu qu'il reste environ 8000 définitions de contours de communes à tracer pour couvrir entièrement la France.
- À l'inverse, cette fourniture est rendue possible par le modèle par frontières, et plus encore depuis que la source "Cartographes Associés" a été supprimée au profit de tracés issus du cadastre pour toutes les limites départementales.
Dit autrement, le modèle par frontière a comme avantage de ne pas nécessiter l'existence de toutes les entitées d'un niveau administratif pour construire les niveaux admins supérieurs.
Logiciel : Construire le polygone de contour
- Si un programme a besoin de construire le polygone qui fait le tour d'une entité administrative (par exemple pour que le GPS vous dise "vous êtes dans la region bidule"), avec le modèle par frontières il doit parcourir tous les membres et en connecter les noeuds de début et de fin de chaque way pour construire le gros polygone.
- Avec le modèle de surface, il devra récupérer les entité administratives du niveau plus petit, puis encore plus petit jusqu'au dernier échelon, récupérer l'ensemble de tous les ways où qu'ils soient. Et faire le calcul de ceux qui sont en bordure.
- A priori, je dirais que la solution 2 est plus longue et plus complexe en terme d'algorithme et de temps
Choix et avenir
Comme il est plus ou moins impossible de trancher en faisant le bon choix, le statu quo est maintenu et le modèle "Modèle de frontière" reste celui recommandé, mais des nouvelles relations utilisant le "Modèle de somme de surface" vont être rentrées (ou pas) par ceux qui défendent ce modèle, de manière séparé afin d'expérimenter, et de voir les avantages de ce modèle.
