[OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[V de Chateau-Thierry]

> 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