====== Jour 7 – Filtres géographiques ======

Nous nous sommes jusqu'ici intéressés aux filtres sur les tags, en nous contentant d'un simple ''%%({{bbox}})%%'' pour le filtre géographique.

Tout d'abord précisons que la forme ''%%({{bbox}})%%'' ne fait pas partie de la syntaxe //Overpass API//. Il s'agit d'un raccourci //Overpass Turbo//, qui se charge de convertir les limites définies par la carte dans la syntaxe ''(lat_min, lon_min, lat_max, lon_max)'', comprise par l'API Overpass. Cela vaut aussi pour la forme ''%%[bbox:{{bbox}}]%%'' placée en entête de requête :

<code>
[bbox:46.892,-2.322,47.037,-2.144];
nwr[amenity=restaurant];
out geom;
</code>

===== Recherche dans une surface =====

Effectuer une recherche à l'intérieur du périmètre d'une collectivité peut fonctionner avec une requête très simple. Exemple avec les restaurants de Rezé : 

<code>
area[name="Rezé"];
nwr[amenity=restaurant](area);
out geom;
</code>

Cette requête mérite quelques explications. 

==== L'instruction area ====
La première ligne trouve les surfaces dont le nom est "Rezé". Des **surfaces** ? Oui, un serveur Overpass stocke, en complément des nodes, ways et relations, des surfaces dans un format adapté à l'exécution de tests comme « ce point est-il à l'intérieur ? ». Ces surfaces sont créées à partir des données OSM, pour toutes les relations de type multipolygon, et un grand nombre de ways fermés comme le décrit la page https://wiki.osm.org/wiki/Overpass_turbo/Polygon_Features. L'instruction **area** permet d'accéder à ces surfaces, en y appliquant les filtres habituels.

==== Lot de données courant ====
Comme pour les instructions node, way, rel et nwr, la première ligne produit un lot de données. Celui-ci peut l'être avec l'instruction out), mais constitue le « lot de données courant ». Celui-ci est utilisé par la seconde instruction, qui recherche les restaurants se trouvant dans les surfaces faisant partie de ce lot de données.

**Attention !** Si ce lot de données contient plusieurs surfaces, la seconde instruction s'applique alors à chacune d'elles. L'instruction ''area[name="Rezé"];'' retourne toutes les surfaces avec name=Rezé, il se trouve qu'il n'en existe qu'une dans toute la base OSM. Mais si vous remplacez Rezé par Saint-Denis, vous obtenez des restaurants à Saint-Denis en Seine Saint-Denis, mais aussi à l'Île de la Réunion, dans le Val d'Aoste et un village de l'Aude.

===== Chercher dans la bonne surface =====

Vous pouvez examiner le résultat de la première instruction exécutant la requête :

<code>
area[name="Saint-Denis"];
out;
</code>

Aucune surface ne s'affiche sur la carte (nous y reviendrons), mais le résultat est visible dans l'onglet Données. On y trouve non seulement les limites des communes nommées Saint-Denis, mais également des arrondissements, une gare, un parc, et trois églises !

Pour restreindre la requête à Saint-Denis en Seine Saint-Denis, il convient d'appliquer les bons filtres sur les tags à la première instruction. En examinant les tags des différentes surfaces, on identifie la clef "ref:INSEE" comme le filtre le plus sélectif. Le filtre sur le nom devient même inutile : on obtient la requête suivante.

<code>
area["ref:INSEE"="93066"];  // Saint-Denis du 93
nwr[amenity=restaurant](area);
out;
</code>

Cette façon de limiter le résultat de la recherche dans une surface pose quelques questions. Nous y revenons demain :o)

© CC-by-sa Carto’Cité