Mode d'emploi d'API Overpass

Enchainer

Comment on peut enchainer plusieures instructions de manière à pouvoir requêter par des critères relatifs à d'autres objets.

Nous avons déjà vu des exemples de filtres indirects dans Requêter par surface et Polygone et autour. Les objets peuvent également être référencés en les enchaînant, qui ne sont même pas inclus dans le résultat final.

Prenons l'exemple, pour trouver tous les cafés de Cologne:

area[name="Köln"];
nwr[amenity=cafe](area);
out center;

Le filtre (area) de la ligne 2 est ici central. Le filtre filtre par la surface ou les surfaces, qu'il trouve dans l'ensemble _. Il fonctionne en commun avec le filtre [amenity=cafe], c'est-à-dire que nous recherchons tous les objets dans la ligne 2, qui sont des nœuds, des chemins ou des relations (nwr) et qui ont l'attribut amenity avec la valeur cafe et se trouvent dans les surfaces déposées en _.

Ainsi nous pouvons reformuler la requête ci-dessus et obtenir exactement le même résultat :

area[name="Köln"];
nwr[amenity=cafe](area._);
out center;

et

area[name="Köln"]->._;
nwr[amenity=cafe](area);
out center;

et

area[name="Köln"]->._;
nwr[amenity=cafe](area._);
out center;

Dans tous les cas, la surface de la ligne 1 à la ligne 2 est médiée par l'ensemble _. Les ensembles sont présentés dans une section de l'introduction.

Nous pouvons également utiliser un ensemble avec n'importe quel nom:

area[name="Köln"]->.nomextremementlong;
nwr[amenity=cafe](area.nomextremementlong);
out center;

Mais ça ne marche pas, si le nom des ensembles des deux lignes ne correspond pas :

area[name="Köln"]->.nomextremementlong;
nwr[amenity=cafe](area.nomextrementlong);
out center;

Les noms pour les ensembles alors deviennent utiles, si vous voulez contrôler plusieurs filtres. Par exemple, nous pouvons chercher des cafés à Münster, mais l'API Overpass ne le sait pas, de quelle Münster nous parlons, parce qu'il y a beaucoup d'endroits plus petits avec le nom en plus de la grande ville et il y a là aussi des cafés:

area[name="Münster"];
nwr[amenity=cafe](area);
out center;

Mais nous pouvons exiger que le café doit être situé à la fois à Münster et en Rhénanie-du-Nord-Westphalie:

area[name="Nordrhein-Westfalen"]->.a;
area[name="Münster"]->.b;
nwr[amenity=cafe](area.a)(area.b);
out center;

Les cafés sont sélectionnés à la ligne 3: Nous sélectionnons les objets de type node, way ou relation, qui portent l'attribut amenity=cafe et qui sont situées à la fois dans l'une des surfaces stockées en a (1 seule zone, à savoir le Land de Rhénanie-du-Nord-Westphalie Nordrhein-Westfalen) ainsi que dans l'une des zones stockées en b (toutes les villes, districts et villages du nom de Münster). Ce ne sont que les cafés de Münster en Westphalie.

L'interaction entre plusieurs filtres et la concaténation est approfondie dans la section suivante.

Par souci d'exhaustivité, nous le soulignons, que le principe des filtres indirects existe pour tous les types. Nous voulons trouver tous les ponts sur la rivière Alster.

Nous pouvons trouver la rivière Alster de deux façons différentes, d'abord par le chemin:

way[name="Alster"][waterway=river];
out geom;

Nous cherchons tous les objets de type way, qui ont l'attribut name avec la valeur Alster et l'attribut waterway avec la valeur river. Celles-ci sont situées après la ligne 1 dans l'ensemble _ et sont éditées à partir de là dans la ligne 2.

Nous trouvons les ponts au lieu de la rivière comme suit:

way[name="Alster"][waterway=river];
way(around:0)[bridge=yes];
out geom;

Ici (around:0) dans la ligne 2 est le filtre indirect. Dans la ligne 2, nous cherchons toutes les chemins, qui ont l'attribut bridge avec la valeur yes et qui ont une distance de 0 aux objets de l'ensemble _. Nous avons rempli l'ensemble _ à la ligne 1 avec les chemins dans le rayon desquelles nous voulons chercher, toutes les chemins qui ont un attribut name avec la valeur Alster et un attribut waterway avec la valeur river.

Le tout fonctionne aussi avec relations ...

relation[name="Alster"][waterway=river];
out geom;

... donc avec des ponts:

relation[name="Alster"][waterway=river];
way(around:0)[bridge=yes];
out geom;

Nous avons rencontré une application de concaténation complètement différente dans les sections Relations et Relations sur relations dans Géométries: Parce que le modèle de données OSM traditionnel ne permet que des coordonnées sur les nœuds, mais aussi la géométrie des autres objets est intéressante, chemins et relations doivent être complétés par les objets d'aide correspondants dans le modèle de données OSM traditionnel.

Les aspects d'chaînage sont expliqués à l'aide d'un exemple: Certes la ligne de métro Waterloo & City à Londres peut être obtenue comme suit:

rel[ref="Waterloo & City"];
out geom;

Mais nous avons besoin d'un modèle de données étendu, que quelques applications ne supportent pas. Si, en revanche, nous utilisons le niveau de détail traditionnel out pour la sortie, nous ne voyons rien:

rel[ref="Waterloo & City"];
out;

La relation est toujours dans l'ensemble _ après la sortie de la ligne 2. Par conséquent, nous pouvons collecter les chemins et les nœuds correspondants, en combinant l'union expliquée dans la section suivante avec le chaînage:

rel[ref="Waterloo & City"];
out;
(
  way(r);
  node(w);
);
out skel;

Avant la ligne 3 l'ensemble _ contient les relations trouvées comme indiqué précédemment. Les lignes 3 à 6 sont l'instruction union. La ligne 4 way(r) est donc la ligne suivante après la ligne 2 et obtient les relations en entrée. Il recherche les chemins qui satisfont le filtre (r), c'est-à-dire sont référencés par une ou plusieurs relations dans l'entrée. Comme résultat, il écrit maintenant ces chemins dans l'ensemble _. L'instruction union en conserve une copie pour son résultat selon sa sémantique.

La ligne 5 node(w) trouve donc les chemins de la ligne 4 comme entrées dans l'ensemble _. Il recherche les nœuds qui satisfont le filtre (w), c'est-à-dire référencés par une ou plusieurs chemins dans l'entrée. Comme résultat, il écrit ces chemins dans l'ensemble _, mais union remplace l'ensemble par son propre résultat de toute façon.

Comme résultat de la ligne 6, l'instruction union écrit l'unification des résultats dans l'ensemble _. Nous obtenons donc toutes les chemins qui ont été référencés par les relations et tous les nœuds référencés par ces chemins.

Cependant, les relations peuvent aussi avoir des nœuds directement en tant que membres, et ces relations ont réellement; vous pouvez le voir dans l'onglet de données ou par requête:

rel[ref="Waterloo & City"];
node(r);
out;

On remplace ainsi les relations de la ligne 2 de l'ensemble _ par les nœuds référencés. Ensuite, nous avons ces nœuds disponibles pour la sortie de la ligne 3, mais ils auraient à nouveau besoin de ces relations, pour obtenir les chemins référencés. Peut-on éviter la double recherche?

Oui, avec des ensembles nommés:

rel[ref="Waterloo & City"];
out;
(
  node(r)->.directement_references_par_les_relations;
  way(r);
  node(w);
);
out skel;

En détail:

• Après la ligne 1, l'ensemble _ contient toutes les relations, qui ont un attribut ref d'une valeur de Waterloo & City.
• Celles-ci sont sorties sur la ligne 2. L'ensemble _ contient toujours les relations.
• L'instruction de bloc union de la ligne 3 à la ligne 7 exécute le bloc qui s'y trouve.
• la ligne 4, (r) utilise donc le contenu d'ensemble _, à savoir les relations de la ligne 1. Ainsi, ces nœuds sont maintenant stockés dans l'ensemble directement_references_par_les_relations, qui sont référencées par l'une des relations. L'instruction union conserve une copie du résultat. Sinon, le résultat ne nous intéresse pas, mais voulons seulement empêcher l'instruction d'écraser l'ensemble _.
• la ligne 5, (r) utilise à nouveau le contenu d'ensemble _, et ce sont toujours les relations, parce qu'on ne les a pas écrasées. L'ensemble _ contient maintenant les chemins qui sont référencées par les relations. L'instruction union conserve une copie du résultat.
• la ligne 6, (w) utilise à nouveau le contenu d'ensemble _. Ce sont maintenant les chemins écrites à la ligne 5. Les nœuds référencés par ces chemins sont donc maintenant stockés dans l'ensemble _. L'instruction union conserve une copie du résultat.
• L'instruction union compose maintenant le résultat global à partir de ses résultats partiels des lignes 4, 5 et 6 et l'écrire dans l'ensemble _.
• L'ensemble _ est maintenant sorti sur la ligne 8.

Puisqu'il s'agit d'un problème très courant, il y a une abréviation pour cette tâche:

rel[ref="Waterloo & City"];
out;
>;
out skel;

Les lignes 1 et 2 fonctionnent exactement comme avant, et la ligne 4 fonctionne exactement comme la ligne 8 avant: Parce que la flèche de la ligne 3 a une sémantique, qu'il trouve les chemins et nœuds directement et indirectement référencés aux relations dans l'ensemble _ et le dépenser sur l'ensemble _.

Maintenant, certains programmes sont surtaxés, si l'ordre dans le fichier n'est pas exactement tous les nœuds, alors tous les chemins, puis toutes les relations.

Pour l'approche détaillée, cet objectif est atteint, en déplaçant la demande initiale vers l'instruction bloc union:

(
  rel[ref="Waterloo & City"];
  node(r)->.direkt_von_den_relations_referenziert;
  way(r);
  node(w);
);
out;

La même chose avec la flèche:

(
  rel[ref="Waterloo & City"];
  >;
);
out;

prochaine: Opérations ET et OU