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

[Philippe Verdy]

Pus lisible deu modèles dans des relations séparées ? Pas du tout ! Et cela
complique tout en fait en ne sachant plus quelle relation utiliser, on va
dénormaliser ennore plus les attributs.

Regarde effectivement l'Espagne ou la Belgique et prétend que ce n'est pas
lisible ! Et pourtant cela demande peu de membres dans les relations, qu
sont classés à part avec des rôles clairement séparés qui ne gênent en rien
la lisibilité des lites de chemins membres (qui elles sont carrément
bordéliques, et le mot est faible, et totalement illisibles sans outils
pour vérifier qu'on n'a pas pris par erreur un morceau de commune voisine
ni oublié une petite enclave ou une ile exclavée qui fait échouer toute
requête purement géométrique...).



Le 19 septembre 2013 15:34, V de Chateau-Thierry <vdct at laposte.net> a écrit
:

>
> > 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130919/f439911d/attachment.htm>