[OSM-talk-fr] Extraire une géométrie représentative d'une relation

Lun 22 Aou 17:18:47 UTC 2016

il serait intéressant de compléter cet exemple avec quelque chose de
significatif, notamment car il y a souvent plusieurs rôles ("outer",
"inner", ainsi que le rôle vide souvent mis à la place de "outer" quand il
n'y a aucune enclave)

On peut faire l'union des rôles.
Attention aussi à la requête de récursion avec "(._;>;);" qui récupère
absolument tous les éléments fils dans une union avec l'élément parent (ici
dans le jeu de données "_" par défaut).

Ensuite attention à l'instruction "out;" qui possède plusieurs options pour
déterminer le niveau de détails demandés (sans les tags avec "skel", ou
avec les tag avec l'option par défault "body", ou avec en plus des
métadonnées avec l'option "meta", telles que le dernier changeset, sa date
et l'utilisateur).

Sur une des instances Overpass on a aussi des données historiques ("Attic")
mais c'est souvent très lent (et actuellement cette instance a des
problèmes de surcharge serveur).

Ci-dessous j'annote les noms de resultsets temporaires avec des noms
explicites, plutôt que d'utiliser et écraser le resultset "_" par défaut
entre chacune des 3 requêtes principales :

  // Première requête : la relation cherchée (cela ne sort pas la liste des
membres)
  // Ce resultset temporaire ne sera pas inclus dans le résultat final
  rel(5430194 <http://www.openstreetmap.org/relation/5430194>)->TMP1;

  // Deuxième requête: récursion sur certains membres en fonction des rôles
à garder, le tout dans une (union)
  // Ce resultset temporaire contenant des ways ne sera pas inclus dans le
résultat final
  ( way(r.TMP1:"outer");
    way(r.TMP1:"inner");
    way(r.TMP1:"");
  )->TMP2;

  // Troisième requête : on garde dans le resultset final une union tous
les ways et la récursion sur tous leurs noeuds membres
  ( .TMP2;
    .TMP2>;
  )->TMP3;

  // Résultats de la troisième requête.
 .TMP3 out skel;

Le résultat ici cependant reste un ensemble de "ways" (la deuxième
récursion avec l'opérateur ">" ne les connecte pas automatiquement.
l'interface graphique Overpass Turbo cependant fait cette connexion côté
client (pas côté serveur) pour créer des lignes "lines" continue ou des
aires fermées ("area"), elle analyse les chemins pour aussi déterminer ceux
qui sont internes ou externes pour remplir les surfaces, avec la liste des
noeuds.

Overpass API permet pas mal de souplesse dans la façon de faire des
requêtes et sous-requêtes. Nommer les resultsets d'entrée (indiqués après
un ".") ou de sortie (après un "->") n'a aucun impact en performance, mais
cela permet des requêtes plus complexes ou plus fines selon les besoins.

Mais Overpass API ne sait pas encore transformer sur le serveur les objets
d'un resultset (par exemple créer des buffers, des simplifications de
géométrie, joindre les lignes, déterminer les surfaces fermées dans un
objet parent), c'est à faire côté client (Overpass Turbo le fait via le
javascript qu'il envoie au client, c'est ce javascript également qui fait
un rendu vectoriel MapCSS dans une couche superposée sur le fond de carte;
ce client fait également les calculs de projection pour correspondre à
l'échelle de visualisation et n'afficher et positionner que les objets qui
sont dans le rectangle visible, car Overpass API ne retourne que des
coordonnées WGS84 telles qu'elles sont sur le serveur de données OSM,
indépendamment de la vue courante ou du niveau de zoom).

Overpass sait visiblement de lui-même purger les resultsets nommés dès
qu'ils ne sont plus utiles à d'autres requêtes ou à une instruction "out"
qui suit.

Le 22 août 2016 à 16:45, Christian Quest <cquest at openstreetmap.fr> a écrit :

> Dans overpass une requête permet de ne sélectionner que les membres
> portant un certain rôle dans la relation:
>
> rel(5430194 <http://www.openstreetmap.org/relation/5430194>);
> way(r:"line");
> (._;>;);out skel;
>
> Après il faut en récupérer la version geojson...
>
> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>
> Bonjour Philippe, Guillaume,
>
> Personne n'est a coté de la plaque ;)
>
> Cependant, seule la méthode m’intéresse.
> En effet il y a déjà quelques outils qui parviennent à présenter
> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>
> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
> géométrie unique. Il affiche tous les objets de la relation et c'est vite
> le fouillis, en plus de devoir être découpé pour être intégré dans du
> geojson.
> Voir ici : http://www.openstreetmap.org/relation/5430194
> Je m'attends à récupérer une ligne toute simple sans les deux polygones
> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>
> Et ça me semble très dur de trouver une méthode générique qui puisse faire
> cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
> cas :'(
>
> François
>
> Le 22 août 2016 à 14:45, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>> Le site web OSM le fait déjà quand on "explore" une relation: ça
>> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
>> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
>> aussi sur ses cartes (mais elle requête son propre serveur pour obtenir
>> aussi des POIs géolocalisés sur Wikipédia ou des photos géolocalisées sur
>> Commons)
>> Attention en cas d'inclusion dans un script web : l'API ne doit pas
>> surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
>> Overpass API avec des centaines de milliers de requêtes par heure au lieu
>> de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
>> plusieurs fois de suite, peut-être à cause d'un script d'un réseau
>> publicitaire abusif ou d'une appli non-officielle type Pokemon).
>> Bref gérer des caches sur votre serveur et éviter de faire des requêtes
>> automatiques en boucle par le client sur chaque page web du site ou chaque
>> page de l'appli mobile, respecter les protocoles !
>>
>>
>> Le 22 août 2016 à 14:30, François Lacombe <fl.infosreseaux at gmail.com> a
>> écrit :
>>
>>> Bonjour à tous,
>>>
>>> Avec la récente mise en place et adoption croissante d'open event
>>> database, je me pose une question que certains ont déjà du résoudre.
>>>
>>> Existe-t-il une méthode générique pour convertir une relation OSM en
>>> geojson ?
>>> Cela reviendrait à convertir la relation en géométrie simple (points /
>>> polyline).
>>>
>>> Le besoin est d'attribuer une géométrie représentative à des événements
>>> dégagés par des ouvrages décrit avec une relation.
>>> Après on peut les envoyer sur open event db.
>>>
>>> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter
>>> à cet exemple.
>>>
>>> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler
>>> tel ou tel type de relation, à la recherche de tel ou tel objet qui au
>>> final n'est pas forcé de se trouver là où on l'attend, etc...
>>>
>>>
>>> Merci par avance pour vos retours
>>>
>>> François
>>>
>>>
>>> --
>>> *François Lacombe*
>>>
>>> fl dot infosreseaux At gmail dot com
>>> www.infos-reseaux.com
>>> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> _______________________________________________
> Talk-fr mailing listTalk-fr at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> _______________________________________________
> 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/20160822/49be3304/attachment.htm>