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 discussions 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és)
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 vue 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 membres
- Dans le cas de faible nombre d'entités (régions) le Modèle de somme de surface comporte moins de membres
- Dans le cas de grand nombre nombre d'entités (Départements) le Modèle de frontière comporte moins de membres
Nombre d'entités auxquelles appartient un chemin de frontière
- Dans le Modèle de somme de surface, chaque way n'appartient qu'à deux entités administratives (celles qui sont 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és administratives qu'il en sépare (jusqu'à 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 relations.
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'échelons
- 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 vue 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'ensemble des communes et collectivités françaises est maintenant délimité. - À 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és d'un niveau administratif pour construire les niveaux admins supérieurs.
- Note : il n'y a aucune différence entre un modèle "par frontière" et un modèle "par surface" puisque les frontières délimitent toujours une surface (et l'ensemble des frontières d'une relation doit former des anneaux fermés). Les deux notions sont totalement équivalentes.
- En revanche rien n'interdit d'utiliser un même chemin dans plus de deux relations limitrophes. Dans les faits, les chemins sont maintenant inclus dans toutes les relations pertinentes, quel que soit leur niveau administratif. Et autant que possible on maximise cette réutilisation pour ne pas superposer les tracés, en scindant les chemins chaque fois que nécessaire pour délimiter une entité plus petite (ces entités ne sont pas toutes "administratives" au sens OSM, elles peuvent être des intercommunalités, des parcs naturels, des autorités portuaires, des agences de bassin, des académies, des régions militaires, des zones de police ou judiciaire, des zones électorales, des zones postales, des zones de transport, des zones sanitaires ou sociales, etc.).
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 région bidule"), avec le modèle par frontières il doit parcourir tous les membres et en connecter les nœuds 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ée afin d'expérimenter, et de voir les avantages de ce modèle.