> De : "Christian Quest" > Bien sûr, si l'on ne définissait les limites administratives que par un modèle surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de sûrement pas mal d'autres outils, mais je ne pense pas que quelqu'un propose un changement aussi radical.
> Le double modèle par contre peut avoir du sens. Il est en effet relativement difficile aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans créer ces géométries. > Je viens d'extraire par exemple des listes de lieux (communes) sur différents pays avec la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une base osm2pgsql pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in très mal renseigné et d'un format très aléatoire car textuel et non véritable structuré. > J'aime aussi cet ajout de redondance qui permet de détecter les incohérences. > A mon avis, au fur et à mesure qu'on a des zones complètes on devrait pouvoir ajouter les subarea en rôle supplémentaires dans les relations de découpages administratifs. Les outils ne sachant pas les exploiter les ignoreront tout simple comme il le font jusqu'à maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose aucun problème. Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de plaider (comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées. C'est plus lisible, et surtout, le type de ces relations ne peut pas être "boundary", ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté : nested_areas ou quoi que ce soit qui évoque la récursivité et la notion de surface. Mais pas type=boundary : on ne parle pas de limites, ici. A creuser... vincent [1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
