[OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?
Christian Quest
cquest at openstreetmap.fr
Jeu 19 Sep 13:48:44 UTC 2013
Il ne faut pas prendre "boundary" au pied de la lettre...
Avec 2 relations, on se retrouvera à devoir recopier les tags sur les deux
à moins que l'on pointe de l'un vers l'autre et on va avoir le choix de
pointer d'un sens vers l'autre ou l'inverse (donc le débat et le bazar qui
va avec).
En quoi est-ce que ça gêne plus d'avoir des relations membres avec un rôle
subarea que d'avoir déjà actuellement des nœuds admin_centre ou label ?
Je préfère un seul objet OSM pour représenter une unique entité sur le
terrain (la région machinchose, le département trucmuche).
Ne serait-ce pas ton point de vue de géomaticien qui tique avec un objet
représentant en même temps une surface et un linéaire ? ;)
Le 19 septembre 2013 15:34, V de Chateau-Thierry <vdct at laposte.net> a écrit
:
>
> 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
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130919/462cc9b3/attachment.htm>
Plus d'informations sur la liste de diffusion Talk-fr