ES:API de Overpass/Guía de lenguaje
Estado de servidores · Versiones · Desarrollo · Diseño técnico · Instalación · Capa de compatibilidad XAPI · Esquemas de transporte público · Aplicaciones · Código fuente e incidenciasOverpass turbo · Asistente · Atajos de Overpass turbo · Hojas de estilo MapCSS · Exportar a GeoJSON · más (español) · Desarrollo · Código fuente e incidencias · Sitio webOverpass Ultra · Examples · Overpass Ultra extensions · Hojas de estilo MapLibre · URL Params · más (español) · Código fuente e incidencias · Sitio web
Esta guía muestra ejemplos de consultas a un servidor de la API de Overpass. Te invitamos a adaptar las consultas a tu necesidad particular.
- Para demostraciones prácticas (probablemente mejor para principiantes), véase API de Overpass/Overpass por ejemplo.
- Para una guía de referencia completa sobre el lenguaje de consulta utilizado, véase Overpass QL
Esta página wiki no cubre algunas de las características más recientes de la API de Overpass. Para obtener una lista completa de las características, por favor, consulta la página wiki Overpass QL. |
Antecedentes y conceptos
La API de Overpass te permite consultar los datos de OSM según tus propios criterios de búsqueda. Para ello, tienes dos lenguajes de consulta específicamente diseñados: Overpass XML y Overpass QL.
La semántica básica de la API de Overpass consiste en que los flujos de datos de OSM (nodos, vías...) se generan y modifican mediante declaraciones, que se ejecutan una tras otra. La siguiente consulta simple puede, por ejemplo, generar un flujo de datos que contenga todos los nodos de un determinado recuadro delimitador y mostrar los resultados:
node(50.745,7.17,50.75,7.18);
out;
Luego puedes filtrar más el flujo resultante, buscando solo las paradas de bus:
node(50.745,7.17,50.75,7.18)[highway=bus_stop];
out;
O también se podría ampliar el resultado para incluir las vías a las que hacen referencia empleando los nodos seleccionados. En este caso, puede que también quieras ampliar el resultado a todos los nodos referenciados por estas vías:
node(50.745,7.17,50.75,7.18);way(bn);
( ._; >; );
out;
Estas declaraciones y su sintaxis se describen con más detalle a continuación.
Lenguajes de la API de Overpass
La API de Overpass ahora ofrece toda su potencia expresiva en una sola solicitud HTTP GET. Para ello, se introduce el nuevo lenguaje de consulta Overpass QL en paralelo al lenguaje de consulta XML establecido. Siempre se puede convertir entre los dos: solo hay que pegar uno de los ejemplos siguientes en este formulario. Allí puedes elegir obtener la salida en:
- Formato de consulta XML: esto coincide con la forma XML que aparece abajo en todos los ejemplos.
- Overpass QL: esto coincide con el formulario Overpass QL de abajo.
- Overpass QL conciso: esto produce una petición HTTP GET de una línea para la misma expresión.
Para ejecutar la consulta, usa en su lugar este formulario.
Básicos de Overpass QL
A continuación, un breve resumen de Overpass QL. Para una referencia completa y actualizada del lenguaje de programación Overpass QL, por favor, consulta la página wiki Referencia de lenguaje Overpass QL. |
A continuación se facilitan algunos ejemplos de sintaxis QL. La sintaxis QL es más concisa que la sintaxis Overpass XML, y, hasta cierto punto, es similar a los lenguajes de programación tipo C. Una declaración siempre termina con un punto y coma «;». Además, una declaración es cualquiera de las dos siguientes:
- una declaración de consulta, que comienza con «node», «way», «relation», «rel» (abreviatura de «relation»), «nwr» (abreviatura de una unión de node+way+relation) o una de las declaraciones de consulta de recursividad «>», «>>», «<», o «<<», o
- una declaración de salida, que empieza por «out».
Las declaraciones de consulta consisten en el tipo de objeto a ser recuperado
node
way
rel
y de al menos una cláusula que describa el objeto a recuperar, por ejemplo,
["name"="Berlin"]
para dar, por ejemplo, esta consulta
node["name"="Berlin"];
que recupera todos los nodos con nombre «Berlin».
Cláusulas de Overpass QL
Hay diferentes tipos de cláusulas que puedes usar:
- para filtrar objetos (nodos, vías, relaciones y áreas de Overpass) que están presentes en el conjunto de resultados de entrada, o
- para realizar consultas de recursividad en ellos para reemplazarlos a todos por la unión de todos sus objetos recursivamente relacionados.
Todas las declaraciones de Overpass QL para filtros (o consultas de recursividad) solo pueden usarse después de especificar un tipo de consulta principal (o .conjuntoresultante), no son consultas por sí mismas.
Cláusulas de solicitud de etiquetas (o «filtros de etiquetas»)
Todas las variantes de solicitudes de etiquetas; por ejemplo,
["key"] /* filtrar los objetos etiquetados con esta clave y cualquier valor */
[!"key"] /* filtrar los objetos no etiquetados con esta clave y cualquier valor */
["key"="value"] /* filtrar los objetos etiquetados con esta clave y este valor */
["key"!="value"] /* filtrar los objetos etiquetados con esta clave pero no con este valor, o no etiquetados con esta clave */
["key"~"value"] /* filtrar los objetos etiquetados con esta clave y un valor que coincida con una expresión regular */
["key"!~"value"] /* filtrar los objetos etiquetados con esta clave pero un valor que no coincide con una expresión regular */
[~"key"~"value"] /* filtrar los objetos etiquetados con una clave y un valor que coincidan con las expresiones regulares */
[~"key"~"value",i] /* filtrar los objetos etiquetados con una clave y un valor que coinciden con las expresiones regulares sin distinguir entre mayúsculas y minúsculas */
Cláusulas de recuadro delimitador («consulta de recuadro delimitador», «filtro de recuadro delimitador»)
Las cláusulas de recuadro delimitador (como todas las demás cláusulas para los filtros o las consultas de recursividad) solo pueden usar como filtros después de especificar un tipo de consulta principal (o .conjuntoresultante), no son consultas por sí mismas. En la sintaxis de Overpass QL Overpass, tienen una forma como en este ejemplo:
/*aquí tu consulta*/(51.0, 7.0, 52.0, 8.0)
Las cláusulas del recuadro de delimitador siempre comienzan con la latitud más baja (la más meridional) seguida de la longitud más baja (la más occidental), luego la latitud más alta (la más septentrional) y luego la longitud más alta (la más oriental). Observa que esto es diferente del ordenamiento en la sintaxis XAPI.
La sintaxis de Overpass XML se salvaguarda mediante el uso de parámetros con nombre (más explícitos) (pero nótese que su nombre puede seguir siendo engañoso, ya que siguen tomando valores negativos para todas las coordenadas absolutas en los hemisferios sur u occidental, y valores positivos para todas las coordenadas absolutas en los hemisferios norte u oriental):
<query><!-- reemplazar por un tipo de consulta efectivo; si este elemento falta, se asume un valor predeterminado <query type="node"> -->
<bbox-query s="51.0" w="7.0" n="52.0" e="8.0"/>
</query><!-- sustituir por un tipo de consulta eficaz -->
Un recuadro delimitador que atraviesa el antimeridiano (que de otro modo intercambiaría las dos longitudes) equivale a una unión de dos subconsultas para cada lado del antimeridiano. Por ejemplo, la banda larga que complementa el recuadro delimitador anterior en el mismo tramo de latitudes equivale a esta unión de consultas en dos cuadros delimitadores (como se trata de una zona muy amplia que abarca demasiados datos, es probable que esta consulta falle, a menos que las consultas principales incluyan filtros más selectivos, como los filtros de etiquetas):
(
/*aquí tu consulta*/(51.0, 7.0, 52.0, 180); /* Un recuadro delimitador que se extiende a través del lado opuesto del antimeridiano (hasta la longitud positiva 180°E) */
/*aquí tu consulta*/(51.0, -180, 52.0, 8.0); /* Lado este del antimeridiano (desde la longitud negativa 180°O) */
);
Ten en cuenta que debes especificar la consulta principal aquí (al menos «nodo», «vía», «rel», «area» o un «.nombreconjuntoresultante», opcionalmente seguido de otros filtros o recursiones) en cada subconsulta. Actualmente, la API de Overpass no ofrece ninguna posibilidad de realizar esta transformación automáticamente si se intercambian las longitudes; en cambio, la API de Overpass devuelve un error si la primera longitud especificada es mayor que la segunda longitud.
Y todavía no es posible crear un filtro compuesto único que contenga una unión de recuadro delimitadores (u otras formas poligonales basadas en una lista ordenada de pares de coordenadas, u otras formas de circulares basadas en las coordenadas de un nodo central y un radio máximo, o exclusiones basadas en la substracción de dos formas simples o compuestas). Además, la API de Overpass no ofrece ninguna forma de transformar geométricamente esas formas simples o compuestas empleando amortiguadores positivos o negativos, a fin de usar filtros limitadores más complejos: las consultas deben repetirse usando diferentes formas simples pretransformadas. Para más detalles, véanse las secciones siguientes relacionadas con las uniones de consultas soportadas, y con (around: ...)
o (poly: "...")
, filtros especiales para otros tipos de formas delimitadoras simples.
Cláusulas de áreas («filtros de áreas»)
Los objetos de «área» no son directamente objetos OSM, son generados (y almacenados en caché en el servidor de la API de Overpass) por un procesamiento por lotes que se ejecuta periódicamente en este servidor para procesar todos los cambios de datos nuevos o modificados en la base de datos, y buscar objetos no nodales que describan una superficie cerrada; estos objetos incluyen vías cerradas o relaciones (en particular relaciones de límite y multipolígono) cuyos miembros incluyen una o más vías unidas para crear anillos cerrados internos o externos que delimitan una superficie. Overpass procesa estos objetos para extraer su geometría (y reconectarlos y ordenarlos adecuadamente en el caso de las relaciones) como un conjunto de límites poligonales. El servidor de la API de Overpass almacena entonces la geometría calculada y la asocia (por su identificador) con el objeto vía o relación de OSM enumerando sus etiquetas; el procesamiento por lotes también reconoce algunas etiquetas de nombres que serán útiles para identificarlos más fácilmente.
Las «áreas» de Overpass son útiles para evitar el uso de consultas de recursividad explícitas y también como filtros precalculados que no devuelven relaciones y vías que de hecho no encierran ninguna área. Pero como se generan por lotes periódicos, es posible que no reflejen el estado más reciente de la base de datos de OSM (o incluso todos los diffs más recientes que ya se reciben y almacenan en el servidor de la API de Overpass). Pero pueden simplificar y acelerar enormemente las consultas, sobre todo en el caso de grandes superficies con geometrías complejas, utilizando normalmente relaciones de límite o multipolígono (como los límites de los países o sus subdivisiones regionales, o los complejos límites de grandes zonas de uso del suelo o características naturales).
Esas áreas pueden emplearse luego como filtros delimitadores más selectivos (en lugar de usar simples recuadros delimitadores), o pueden usarse también como consultas (en cuyo caso devolverán todos los nodos de la superficie delimitada por la geometría del área).
Si las áreas están referenciadas por su identificador interno en Overpass (y esa área ha sido incluida), cualquier área presente en el conjunto de entrada se ignora y solo los objetos OSM del conjunto de entrada que se intersectan con esa área especificada se mantendrán tal cual:
(area:2400000001) /* filtrar los objetos en el área cuya superficie está delimitada por la vía con id=1 en OSM */
(area:3600000001) /* filtrar los objetos en el área cuya superficie está delimitada por los miembros de la relación con id=1 en OSM */
Las identificaciones de las áreas de paso superior precalculadas se asignan actualmente añadiendo simplemente grandes constantes estáticas a la identificación de OSM (siempre que los objetos OSM asociados encierren efectivamente una superficie).
Seleccionar áreas por nombre
Sin embargo, las áreas se seleccionan normalmente ejecutando una consulta especial independiente (con el apoyo del cliente Overpass turbo) sobre sus etiquetas de denominación conocidas para el objeto OSM que representan (Nominatim se emplea para procesar, reconocer e indexar varias etiquetas de denominación, incluidas las etiquetas para nombres traducidos) y almacenando las áreas encontradas en un conjunto de resultados con nombre: cualquier área que coincida con las etiquetas pertinentes se almacenará en ese conjunto de resultados con nombre:
{{geocodeArea:"United Kingdom"}}->.a; /* encuentra un área etiquetada con "name"="United Kingdom" */
{{geocodeArea:"GB"}}->.a; /* encuentra un área etiquetada con "ISO3166-1"="GB" */
Obsérvese que las consultas «geocodeArea» anteriores devolverán (en el conjunto de resultados «a») solo las áreas Overpass que coincidan con el nombre indicado, pero no los objetos OSM (nodos, vías o relaciones). No todas las áreas posibles son devueltas por estas consultas, solo la primera que coincida: esto se hace usando una extensión de sintaxis de Overpass turbo, que permite realizar una búsqueda por nombre (a través de Nominatim) y luego convirtiendo el objeto devuelto en un identificador de área de Overpass adecuado. Estas consultas no funcionarán directamente en los servidores básicos de la API de Overpass, y tú mismo tendrás que especificar el identificador de área constante.
Sin emplear la extensión Overpass Turbo (que es más limitada y puede que no devuelva el área que se espera), se puede seguir usando la estructura de la API Overpass para obtener lo mismo (pero sin limitarse a una sola área en el conjunto de resultados, y con más posibilidades de filtrar el área de unión seleccionada mediante etiquetas explícitas):
( area[name="United Kingdom"]; )->.a; /* o más selectivamente: */
( area["ISO3166-1"="GB"][admin_level=2]; )->.a;
Entonces este conjunto de resultados nombrado puede ser usado para filtrar objetos por intersección con esta área. La siguiente cláusula de filtrado mantendrá solo los objetos del conjunto de resultados actual que se intersecten con cualquier área presente en el conjunto de resultados con nombre «a»:
/*aquí tu consulta*/(area.a)
Obsérvese que este filtro mantendrá cualquier objeto (nodos, vías, relaciones o áreas) en la consulta principal que esté completamente contenido en cualquier área en «a», o parcialmente cubierto por cualquiera de ellas, o cualquier objeto en la consulta cuya superficie encierre completamente cualquier área en «a». Por ejemplo, si el área seleccionada es el área de una ciudad, el filtro devolverá todas las subdivisiones locales (distritos, barrios) de esa ciudad, todas las características naturales (como lagos) de esa ciudad, y todas las subdivisiones que incluyen esa ciudad (nodos, vías, relaciones y áreas en el conjunto de entrada), a menos que se empleen filtros de etiquetas adicionales en la consulta principal para ser más selectivos (como ["admin_level"="8"] para seleccionar simplemente objetos OSM que representen esa ciudad; los objetos cerrados para las ciudades circundantes que también están etiquetados con ["admin_level"="8"] y que están compartiendo solo un borde común con la ciudad seleccionada normalmente no se devolverán porque la superficie de su intersección mutua debería estar vacía y limitada a estos bordes comunes; sin embargo, cualquier nodo y vía que esté en el conjunto de entrada, y que también caiga exactamente en el borde del área seleccionada, se devolverá, independientemente de otras relaciones o vías cerradas de las que pudieran ser miembros).
Cláusulas de recursividad («filtros de recursividad»)
O la recursividad hacia adelante o hacia atrás sobre los vínculos de membresía
(r)
(w)
(n)
(br)
(bw)
(bn)
(>)
(>>)
(<)
(<<)
Cláusulas especiales («filtros especiales»)
O cláusulas especiales de forma «(type:value)», p. ej., la cláusula «(around:value)».
En las partes respectivas de ejemplos de uso se dan más detalles.
Sobre los enlaces
La mayoría de los ejemplos se ilustran con enlaces a un mapa. Esta es todavía una solución muy experimental. El recuadro delimitador está fijado para mostrar siempre la ciudad alemana de Bonn. Y algunas consultas toman bastante tiempo, tal vez más de un minuto si ninguno de los datos necesarios está en el caché del servidor. Los símbolos son feos, pero esto también podría cambiarse por una capa mashup dirigida a los usuarios finales. Deberían ser principalmente fáciles de encontrar.
Ejemplos de uso: Todos los datos en un recuadro delimitador
Comencemos a ver algunos ejemplos de consultas analizando la consulta por recuadro delimitador.
El recuadro delimitador
La consulta de recuadro delimitador permite descargar todos los nodos, vías o relaciones del recuadro delimitador especificado, Específica con:
- s el límite meridional en grados decimales (la latitud más baja, medida a lo largo de un meridiano desde el punto más cercano en el Ecuador, negativo en el hemisferio sur)
- w el límite occidental en grados decimales (la longitud más baja, medida a lo largo de un paralelo desde el punto más cercano en el meridiano de Greenwich, negativo en el hemisferio occidental)
- n el límite norte en grados decimales (latitud más alta, medida a lo largo de un meridiano desde el punto más cercano en el Ecuador, positivo en el hemisferio norte)
- e el límite oriental en grados decimales (la longitud más alta, medida a lo largo de un paralelo desde el punto más cercano en el meridiano de Greenwich, positivo en el hemisferio oriental)
Estas coordenadas se especifican en la base de datos de OSM y en la API de OverPass proyectando verticalmente los puntos reales a los nodos en el elipsoide WGS84.
Ten en cuenta también que la fórmula de Overpass QL tiene el orden implícito (s, w, n, e). Esto es más conciso que la sintaxis explícita de XML, pero por supuesto requiere cierto cuidado para conseguir el orden correcto. El límite occidental es más alto que el oriental si y solo si tu consulta supera la longitud ±180,0 grados con un recuadro delimitador que atraviese el antemeridiano (en ese caso la consulta equivale a la unión de dos recuadros delimitadores a cada lado del antemeridiano).
Para las áreas que no son recuadros, véase el comando Poly.
Recuperar todos los nodos dentro de un recuadro delimitador
Todos los nodos en un pequeño recuadro delimitador de ejemplo:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<bbox-query e="7.157" n="50.748" s="50.746" w="7.154"/>
<print/>
</osm-script>
|
node(50.746,7.154,50.748,7.157);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Vías
De manera similar, puedes obtener todas las vías del recuadro delimitador. Una vía se encuentra no solo si tiene un nodo dentro del recuadro delimitador, sino también si simplemente cruza el recuadro en algún lugar.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="way">
<bbox-query e="7.157" n="50.748" s="50.746" w="7.154"/>
</query>
<print/>
</osm-script>
|
way(50.746,7.154,50.748,7.157);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Relaciones
Una relación se encuentra en un recuadro delimitador si tiene un miembro de tipo nodo o vía dentro del recuadro.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="relation">
<bbox-query e="7.157" n="50.748" s="50.746" w="7.154"/>
</query>
<print/>
</osm-script>
|
relation(50.746,7.154,50.748,7.157);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Ejemplos de uso: Consultas sencillas para etiquetas y recuadros delimitadores
Esta sección está incompleta. Por favor, dirígete a la página wiki Overpass QL. |
Dondequiera que veas este símbolo: , puedes hacer clic en él para usar Overpass turbo para inspeccionar la consulta y sus resultados.
Encontrar algo en los datos de OpenStreetMap siempre significa buscar una ubicación o los valores de ciertas etiquetas. Puedes elegir cualquier clave para la etiqueta en los siguientes ejemplos. En un primer paso, encontramos los objetos por sus nombres, por lo que buscamos ciertos valores de la clave «name».
Por nombre exacto
En nuestro primer ejemplo, buscaremos un nodo por el valor de su etiqueta de nombre:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
</query>
<print/>
</osm-script>
|
node["name"="Gielgen"];
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Por nombre exacto y ubicación aproximada
Si esto no es lo suficientemente exacto, también se podría especificar un recuadro delimitador para obtener resultados solo dentro de un determinado recuadro delimitador. El orden de las coordenadas es (latitud inferior, longitud inferior, latitud superior, longitud superior). Si no tienes un recuadro delimitador, el siguiente ejemplo puede adaptarse mejor:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["name"="Gielgen"]
(50.7,7.1,50.8,7.2);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Nombres no exactos
Pero incluso cuando no sabes el nombre exacto, puedes encontrar el objeto. Para ello, la API de Overpass soporta expresiones regulares (POSIX extendido). Damos un par de ejemplos de expresiones regulares útiles.
El primer ejemplo busca cualquier nodo que contenga la subcadena «holtorf» en su nombre:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="holtorf"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["name"~"holtorf"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
El segundo ejemplo busca cualquier nodo que tenga la subcadena «Holtorf» al principio del nombre:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="^Holtorf"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["name"~"^Holtorf"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
El tercer ejemplo busca cualquier nodo que tenga la subcadena «holtorf» como final del nombre:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="Holtorf$"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["name"~"holtorf$"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Por supuesto, también podrías buscar «^Holtorf$», pero esto es lo mismo que una simple búsqueda de igual valor.
Y puedes buscar sin distinguir mayúsculas y minúsculas con expresiones regulares encerrando ambas variantes entre paréntesis:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="[hH]oltorf"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["name"~"[hH]oltorf"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Acentos y caracteres decorados
Muchas lenguas europeas tienen variantes modificadas de los conocidos caracteres latinos, no solo «e» sino también «é» o «ê». Se pueden obtener con una expresión regular.
Por lista de candidatos:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="H[oôóòö]ltorf" />
<bbox-query s="50.7" w="7.1" n="50.8" e="7.25" />
</query>
<print />
</osm-script>
|
node
["name"~"H[oôóòö]ltorf"]
(50.7,7.1,50.8,7.25);
out body;
|
O dejando un punto comodín:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="H.ltorf" />
<bbox-query s="50.7" w="7.1" n="50.8" e="7.25" />
</query>
<print />
</osm-script>
|
node
["name"~"H.ltorf"]
(50.7,7.1,50.8,7.25);
out body;
|
Por favor, ten en cuenta:
- Un solo punto comodín reemplaza un solo punto de código codificado en UTF-8, no necesariamente un solo byte en esa codificación (solo los caracteres del subconjunto US-ASCII de 7 bits están codificados en UTF-8 en un byte). Así que un solo punto coincide con «e» así como con «é» o «ê» (pero también cualquier otra letra, incluyendo las no latinas; «-» o un espacio), pero no «ø̄» que no es codificable como un solo punto de código, sino como la letra o precombinada seguida de la combinación de macrón, o como la letra o con macrón precombinada seguida de la combinación de barras, o como la letra o de base seguida en cualquier orden por la combinación de macrón y la combinación de barras).
- Las letras con diacríticos deben ser almacenadas en la base de datos en Unicode «Normalized Form Composed» o NFC. La mayoría de las letras con diacríticos empleadas en los idiomas europeos modernos se pueden componer en NFC, pero no todos los pares que consisten en una letra base con un solo diacrítico se pueden componer en un solo punto de código, y algunas letras con dos diacríticos siguen siendo codificables en NFC con un solo punto de código, como «ế» empleado en Vietnam y que será emparejado por un solo punto comodín), en lugar de la codificación canónicamente equivalente como la letra base «e» seguida de los dos diacríticos distintos en cualquier orden (uno de este orden es la «Normalized Form Decomposed» (NFD) usada por algunos sistemas operativos como MacOS (que prefiere almacenar nombres de archivos codificados como NFD en su sistema de archivos), o por algunos controladores de teclado o editores de texto.
- Por esta razón no es fácil hacer coincidir todas las formas de codificación posibles de la misma letra base e (incluidas las variantes en mayúsculas y minúsculas) con o sin uno o más diacríticos de combinación: la API de Overpass sigue sin admitir la coincidencia de expresiones regulares basadas en el cotejo (cuyas reglas dependen del lenguaje y la escritura utilizados, y del cotejador utilizado para ese lenguaje y escritura, y de los parámetros de fuerza de cotejo (como la sensibilidad a las mayúsculas y minúsculas). En su lugar, se pueden enumerar las variantes de letras esperadas entre corchetes [cuadrados], o utilizar uniones de consultas para cada ortografía o codificación de la letra que se busca.
Uno u otro nombre
Si quieres permitir dos valores alternativos, puedes usar una tubería para eso.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" regv="holtorf|Gielgen"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["name"~"holtorf|Gielgen"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Más información sobre las expresiones regulares (POSIX extendido) se puede encontrar en la consola o en tu buscador favorito con «man 7 regex».
Negación
Las expresiones regulares no permiten la negación por sí mismas. Por eso, hay un operador de negación explícita en Overpass QL.
Por ejemplo, la siguiente consulta arroja todas las vías que no tienen un valor de clave de vial:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="way">
<has-kv k="highway" modv="not" regv="."/>
<bbox-query e="7.18" n="50.75" s="50.74" w="7.17"/>
</query>
<print limit="" mode="body" order="id"/>
</osm-script>
|
way
["highway"!~"."]
(50.74,7.17,50.75,7.18);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Como segundo ejemplo, se puede restringir la consulta de las paradas de bus a las que tengan un refugio. Técnicamente, buscamos los nodos con "highway"="bus_stop" y la etiqueta «shelter», que no tenga valor «no».
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="highway" v="bus_stop"/>
<has-kv k="shelter"/>
<has-kv k="shelter" modv="not" v="no"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["highway"="bus_stop"]
["shelter"]
["shelter"!="no"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Lo mismo con expresiones regulares:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="highway" v="bus_stop"/>
<has-kv k="shelter"/>
<has-kv k="shelter" modv="not" regv="no"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["highway"="bus_stop"]
["shelter"]
["shelter"!~"no"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar etiquetas: mapa OpenLayers, JSON, XML.
Múltiples etiquetas
Por supuesto, también puedes buscar los nodos que tienen una etiqueta «highway» con valor «bus_stop» y una etiqueta «shelter» con valor «yes»:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="highway" v="bus_stop"/>
<has-kv k="shelter" v="yes"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
node
["highway"="bus_stop"]
["shelter"="yes"]
(50.7,7.1,50.8,7.25);
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Calles y otras vías
Cada una de las consultas anteriores también funcionan para las vías o relaciones. Buscamos la calle «Gielgenstraße» dentro del ya conocido recuadro delimitador:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="way">
<has-kv k="name" v="Gielgenstraße"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<print/>
</osm-script>
|
way
["name"="Gielgenstraße"]
(50.7,7.1,50.8,7.25);
out;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Ten en cuenta que también debes solicitar los nodos de la vía si deseas mostrar la vía en el mapa (o necesitas las coordenadas por otra razón). Esto se hace con una declaración extra de recursividad hacia abajo. Para obtener también la vía, ponemos ambos en una declaración de unión. Todas estas declaraciones se explican más abajo.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="way">
<has-kv k="name" v="Gielgenstraße"/>
<bbox-query e="7.25" n="50.8" s="50.7" w="7.1"/>
</query>
<union>
<item />
<recurse type="way-node"/>
</union>
<print/>
</osm-script>
|
(
way
["name"="Gielgenstraße"]
(50.7,7.1,50.8,7.25);
>;
);
out;
|
Relaciones
Y ahora buscamos la relación de "network"="VRS" y "ref"="636". Este es un servicio de bus local. Como el atajo de la red es único, no necesitamos un recuadro delimitador o cualquier otra ayuda similar.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="relation">
<has-kv k="network" v="VRS"/>
<has-kv k="ref" v="636"/>
</query>
<print/>
</osm-script>
|
relation
["network"="VRS"]
["ref"="636"];
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Consulta por identificador de elemento
Esta sección está incompleta. Por favor, dirígete a la página wiki Overpass QL. |
Si quieres un identificador específico de la base de datos, puedes realizar una consulta por él.. Te damos
- un ejemplo para un nodo:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<id-query ref="507464799" type="node"/>
<print/>
</osm-script>
|
node(507464799);
out;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
- un ejemplo para una vía:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<id-query ref="24777894" type="way"/>
<print/>
</osm-script>
|
way(24777894);
out;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
- un ejemplo para una relación:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<id-query ref="1745069" type="relation"/>
<print/>
</osm-script>
|
relation(1745069);
out;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
El operador de unión: combinación de resultados y formación de conjuntos
Combinación de resultados con el operador de unión
La declaración «unión» equivale al conjunto de paréntesis «(...);» en QL. La salida de esa unión se coloca en «_».
Y, por último, buscamos todo tipo de objetos con una cierta etiqueta dentro de un recuadro delimitador. Si no se usa «nwr», hay que repetir la etiqueta para cada tipo y usar el operador de «unión». Para permitirnos mostrar todo en un mapa, también pedimos los nodos y vías que son referenciadas por las relaciones y vías en el resultado:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<union>
<query type="node">
<has-kv k="amenity" v="fire_station"/>
<bbox-query e="7.3" n="50.8" s="50.6" w="7.0"/>
</query>
<query type="way">
<has-kv k="amenity" modv="" v="fire_station"/>
<bbox-query e="7.3" n="50.8" s="50.6" w="7.0"/>
</query>
<query type="relation">
<has-kv k="amenity" modv="" v="fire_station"/>
<bbox-query e="7.3" n="50.8" s="50.6" w="7.0"/>
</query>
</union>
<union>
<item/>
<recurse type="down"/>
</union>
<print/>
</osm-script>
|
(
node
["amenity"="fire_station"]
(50.6,7.0,50.8,7.3);
way
["amenity"="fire_station"]
(50.6,7.0,50.8,7.3);
rel
["amenity"="fire_station"]
(50.6,7.0,50.8,7.3);
);
(._;>;);
out;
|
Mostrar resultado: mapa OpenLayers JSON, XML.
El conjunto predeterminado «_» y la llamada al conjunto predeterminado «._»
Similar a una variable predeterminada en el lenguaje de programación PERL, Overpass QL tiene un conjunto por defecto, llamado «_». Veamos de nuevo la última consulta:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<union>
<query type="node">
<has-kv k="amenity" v="fire_station"/>
<bbox-query e="7.3" n="50.8" s="50.6" w="7.0"/>
</query>
<query type="way">
<has-kv k="amenity" modv="" v="fire_station"/>
<bbox-query e="7.3" n="50.8" s="50.6" w="7.0"/>
</query>
<query type="relation">
<has-kv k="amenity" modv="" v="fire_station"/>
<bbox-query e="7.3" n="50.8" s="50.6" w="7.0"/>
</query>
</union>
<union>
<item/>
<recurse type="down"/>
</union>
<print/>
</osm-script>
|
(
node
["amenity"="fire_station"]
(50.6,7.0,50.8,7.3);
way
["amenity"="fire_station"]
(50.6,7.0,50.8,7.3);
rel
["amenity"="fire_station"]
(50.6,7.0,50.8,7.3);
);
(
._;
>;
);
out;
|
Mostrar resultado: mapa OpenLayers JSON, XML.
La consulta consiste en
- Una primera unión (nodos, vías, relaciones), indicada por la declaración de «unión» o el primer conjunto de paréntesis «(...);» en QL. La salida de esa unión se coloca en «_».
- Una segunda unión «(._;>;);» en QL, que consiste en
- llamada al conjunto predeterminado («item» o «._;» en QL)
- recursividad hacia abajo, («>;» en QL)
La salida de esa segunda unión se coloca de nuevo en «_», que luego se imprime.
El comando print imprime el contenido del contenedor «_» en el momento de la ejecución. Esto se acerca mucho al «último conjunto definido».
Otros conjuntos con nombre
La consulta independiente de elemento consiste solo en un prefijo de entrada. Toma el conjunto de entrada especificado por su prefijo. Esto es particularmente útil para las declaraciones de unión: reproduce su conjunto de entrada como (parte del) resultado de la declaración de unión. El uso más común es el uso con el conjunto de entrada predeterminado.
._;
En el contexto de una declaración de unión, lo siguiente devolverá todos los elementos en el conjunto de entrada predeterminado junto con el resultado de recursividad hacia abajo.
(._; >;);
Aunque, por supuestos, otros conjuntos también son posibles:
.a;
En el contexto de una declaración de unión:
(.a; .a >;);
Nota: Las declaraciones subsiguientes en una declaración de unión no se ven afectadas por la declaración de elemento. En particular, «.a;» no añade el contenido del conjunto de entrada al conjunto de elementos predeterminado «_».
La declaración de elemento también se puede usar como filtro.
Unión y asignación de conjuntos: .->a
Overpass tiene un modelo de ejecución imperativo. En particular, las declaraciones se ejecutan una después de otra, y cada declaración termina con un punto y coma. Cada declaración pone sus resultados en un contenedor en su memoria llamado de forma predeterminada «_». Si una declaración necesita algún dato de entrada, lee su entrada desde «_». Por ejemplo, la declaración impresa se lee desde «_». A veces es útil utilizar más de un contenedor durante una consulta más compleja. En este caso, la salida puede redirigirse a otro contenedor, por ejemplo, con el nombre «x». Esto es lo que controla la sintaxis anterior.
La declaración de bloque unión se escribe como un par de paréntesis. Dentro de la unión, se puede colocar cualquier secuencia de declaraciones, incluyendo declaraciones anidadas de unión y foreach.
(declaración_1; declaración_2; …)[->.conjunto_resultados];
No se necesita ningún conjunto de entrada. Produce un conjunto de resultados. Su conjunto de resultados es la unión de los conjuntos de resultados de todas las subdeclaraciones, independientemente de si una subdeclaración tiene un conjunto de resultados redirigido o no.
Ejemplo:
(node[name="Foo"];way[name="Foo"];);
Esto recoge en la primera declaración todos los nodos que tienen una etiqueta de nombre «Foo» y en la segunda declaración todas las vías que tienen una etiqueta de nombre «Foo». Después de la declaración de unión, el conjunto de resultados es la unión de los conjuntos de resultados de ambas declaraciones.
El conjunto de resultados de la declaración de unión puede ser redirigido con la notación posfija habitual.
Ejemplo:
(node[name="Foo"];way[name="Foo"];)->.a;
Igual que el ejemplo anterior, pero el resultado se escribe en la variable a.
Limitación: Ten en cuenta que las declaraciones foreach y print no pueden ser un subelemento del elemento unión.
Recursividad: «>», «<», etc.
Cláusulas de recursividad
Ya conocemos las cláusulas de recursividad:
(r)
(w)
(n)
(br)
(bw)
(bn)
(>)
(>>)
(<)
(<<)
Ahora echaremos un vistazo a algunas de ellas.
Por qué necesitamos la recursividad
En general, te interesarán los datos completos, más que los elementos de un solo tipo. En primer lugar, hay varias definiciones válidas de lo que significa «datos completos de mapas». El primer tema poco claro es qué hacer con los nodos que se encuentran fuera del recuadro delimitador y que son miembros de vías que se encuentran parcialmente dentro del recuadro delimitador.
La misma pregunta se repite para las relaciones. Si esperas trabajar con restricciones de giro, puede que prefieras incluir todos los elementos de la relación. Si, por ejemplo, tu recuadro delimitador llega a la frontera de Rusia, es probable que no quieras descargar diez mil kilómetros de límites alrededor de la mitad del mundo.
Una segunda pregunta para las relaciones es si las relaciones sobre las relaciones deben ser incluidas.
Por esa razón, a continuación damos ejemplos de varias variantes de llamadas de mapas. Es una disciplina en la que el paradigma de consulta muestra su fuerza: puedes construir una consulta de cualquier tipo que quieras. Solo tienes que elegir entre los ejemplos siguientes o modificarlos según tus necesidades.
Los enunciados particulares de las llamadas se explican en las secciones más avanzadas más abajo.
Recursividad hacia abajo: «>» y «>>»
Esta sección está incompleta. Por favor, dirígete a la página wiki Overpass QL. |
Recursividad hacia arriba: «<» y «<<»
Esta llamada incluye todos los nodos del recuadro delimitador, todas las vías que tienen tales nodos como miembros y todas las relaciones que tienen tales nodos o tales vías como miembros. Por favor, observa que no todas las vías o relaciones devueltas se muestran en OpenLayers, ya que Open Layers requiere que todos los nodos de una vía o miembros de una relación estén presentes.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<union into="_">
<bbox-query e="7.157" n="50.748" s="50.746" w="7.154"/>
<recurse type="up"/>
</union>
<print mode="meta"/>
</osm-script>
|
(
node(50.746,7.154,50.748,7.157);
<;
);
out meta;
|
Más sobre esta consulta a continuación.
Recursividad hacia arriba y hacia abajo: Vías y relaciones completas
Esta llamada incluye todos los nodos del recuadro delimitador, todas las vías que refieren cualquiera de estos nodos, todos los nodos miembros de estas vías que estén o no dentro del recuadro delimitador, todas las relaciones que tengan tales nodos o tales vías como miembros, y su nodo y vía miembro, e incluso los nodos de estas vías. Nótese que debido a las relaciones involucradas, se incluyen objetos situados bastante lejos del recuadro delimitador.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<union into="_">
<bbox-query e="7.157" n="50.748" s="50.746" w="7.154"/>
<recurse type="up"/>
<recurse type="down"/>
</union>
<print limit="" mode="meta" order="id"/>
</osm-script>
|
(
node(50.746,7.154,50.748,7.157);
<;
>;
);
out meta;
|
Más sobre esta consulta a continuación.
Recursividad más compleja
Véase API de Overpass/Ejemplos avanzados.
Cláusulas especiales: around y poly
«around» - encontrar algo cerca de otra cosa
Esta sección está incompleta, por favor, dirígete a la página wiki Overpass QL. |
Una forma menos técnica de obtener uno de los múltiples resultados puede ser encontrar algo proporcionando una ubicación cercana. Por ejemplo, se puede buscar una ubicación llamada «Gielgen» en un radio de 1000 metros de una ubicación llamada «Bonn».
(Ten en cuenta que los cálculos se hacen con una fórmula no esferoidal (véanse más detalles aquí (en)), que pueden causar algunas aproximaciones.)
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Bonn"/>
</query>
<query type="node">
<around radius="1000"/>
<has-kv k="name" v="Gielgen"/>
</query>
<print/>
</osm-script>
|
node["name"="Bonn"];
node
(around:1000)
["name"="Gielgen"];
out body;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Seleccionar región por polígono
Esta sección está incompleta. Por favor, consulta la página wiki Overpass QL. |
Además de los recuadros delimitadores, ahora también se pueden usar polígonos para recortar una región a descargar. Un ejemplo sencillo es una parte de la ciudad Venusberg en Alemania:
(
node(poly:"50.7 7.1 50.7 7.12 50.71 7.11");
<;
);
out meta;
Más en general, los ejemplos de arriba pueden adaptarse a la variante del polígono: Solo hay que reemplazar la condición del recuadro por la condición poligonal. La única restricción es que los polígonos solo pueden usarse como bordes para los nodos. Por favor, usa una de las varias declaraciones de recursividad para obtener vías y relaciones a partir de ellos.
Si quieres usar un polígono como salida de rel2poly.pl como límite, puedes convertirlo con la siguiente secuencia script poly2request.sh:
#!/usr/bin/env bash
echo -n '(node(poly:"'
awk '{ if ($1 != "1" && $1 != "polygon" && $1 != "END") printf $2" "$1" "; }'
echo '");<;);out;'
Ahora se puede obtener la descarga con, p. ej.,
./poly2request.sh <polygon.txt >request.txt
wget --post-file=request.txt http://overpass-api.de/api/interpreter
Controlar el formato de salida (print, out)
Esta sección está incompleta. Por favor, dirígete a la página wiki Overpass QL. |
Print hace lo que su nombre permite esperar: imprime los contenidos consultados hasta ahora como datos de resultados. Así, casi todas las consultas terminan con una declaración print. En aras de la brevedad, print ha sido renombrado a out; en Overpass QL.
Grado de verbosidad
Print existe en cuatro grados diferentes de verbosidad, que se especifican por el atributo mode: body (predeterminado), skeleton, ids_only y meta. Estos se explican en los siguientes ejemplos, en los que se indican las partes pertinentes de la consulta y el resultado. Cuanto más conciso sea el resultado, más rápido se ejecutará la consulta. Por esa razón, skeleton se usa en esta guía para las capas de OpenLayers. meta es probable que sea la mejor opción si quieres editar los datos. Si no estás seguro de lo que necesitas, prueba primero con body.
XML | QL | Descripción |
<print/> | out; o out body; |
Modo de salida normal. |
<print mode="skeleton"> | out skel; | El modo skeleton es un modo de impresión algo más corto que el modo de impresión habitual: No se imprimen etiquetas en este modo, solo identificadores, elementos hijos y coordenadas de los nodos. |
<print mode="ids_only"> | out ids; | ids_only es el modo de impresión más corto; solo se imprimen los identificadores. ids_only se abrevia a ids en Overpass QL. Ten en cuenta que esto no funciona con OpenLayers porque no se devuelven las coordenadas. |
<print mode="meta"> | out meta; | meta es el modo más completo. Además de elementos y etiquetas de elementos hijo, también se imprimen los metadatos (fecha y hora, versión, conjunto de cambios, nombre de usuario e identificador). |
Normal (body)
body es el modo predeterminado: se imprimen los identificadores, los elementos hijos y las etiquetas. Si quieres el modo body, puedes omitir el atributo de mode
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
<has-kv k="place" v="suburb"/>
</query>
<print/>
</osm-script>
|
node
["name"="Gielgen"]
["place"="suburb"];
out;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Conciso (skeleton, skel)
El modo de impresión skeleton es algo más corto: No se imprimen etiquetas en este modo, solo identificadores, elementos hijo y coordenadas de los nodos:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
<has-kv k="place" v="suburb"/>
</query>
<print mode="skeleton"/>
</osm-script>
|
node
["name"="Gielgen"]
["place"="suburb"];
out skel;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Breve (ids_only, ids)
ids_only es el modo de impresión más corto: solo se imprimen los identificadores. ids_only se abrevia a ids en Overpass QL. Ten en cuenta que esto no funciona con OpenLayers porque no se devuelven las coordenadas.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
<has-kv k="place" v="suburb"/>
</query>
<print mode="ids_only"/>
</osm-script>
|
node
["name"="Gielgen"]
["place"="suburb"];
out ids;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Verboso (meta, meta)
meta es el modo más completo. Además de los elementos hijo y las etiquetas, también se imprimen los metadatos (marcas de tiempo, versión, conjunto de cambios, nombre de usuario e identificador):
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
<has-kv k="place" v="suburb"/>
</query>
<print mode="meta"/>
</osm-script>
|
node
["name"="Gielgen"]
["place"="suburb"];
out meta;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Estos metadatos son, en particular, necesarios para manipular el resultado en JOSM.
Atributo de orden para resultados más rápidos (quadtile, qt)
Puedes cambiar el orden de los elementos. De forma predeterminada, los elementos se ordenan por sus identificadores (es decir, order="id"). Se obtienen resultados más rápidos si se permite ordenar los elementos por su ubicación (es decir, order="quadtile", o qt en Overpass QL).
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
<has-kv k="place" v="suburb"/>
</query>
<print order="quadtile"/>
</osm-script>
|
node
["name"="Gielgen"]
["place"="suburb"];
out qt;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Atributo de límite para limitar elementos (limit, n)
También es posible limitar el número de elementos impresos:
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="node">
<has-kv k="name" v="Gielgen"/>
</query>
<print limit="2"/>
</osm-script>
|
node["name"="Gielgen"];
out 2;
|
Mostrar resultado: mapa OpenLayers, JSON, XML.
Esto limita la salida a un máximo de dos nodos.
Atributos de geometría
XML | QL | Descripción |
<print mode="geom"> | out geom; | geom: por favor, dirígete a la página wiki Overpass QL. |
<print mode="center"> | out center; | center añade el centro del recuadro delimitador del objeto a la salida. No se garantiza que esté en el área del objeto. |
<print mode="bb"> | out bb; | bb: por favor, dirígete a la página wiki Overpass QL. |
Véase también API de Overpass/API de Overpass por ejemplo.
Atributo de geometría (center, center)
Añade el centro del recuadro delimitador del objeto a la salida. No se garantiza que esté en el área del objeto.
Overpass XML | Overpass QL |
---|---|
<osm-script>
<query type="relation">
<has-kv k="boundary" v="postal_code"/>
<has-kv k="postal_code" v="65343"/>
</query>
<print geometry="center"/>
</osm-script>
|
rel["boundary"="postal_code"][postal_code=65343];
out center;
|
Opciones de script de OSM
Esta sección está incompleta. Por favor, dirígete a la página wiki Overpass QL. |
Escoger el formato de archivo (output="json", [out:json])
Puedes obtener el resultado como JSON o como XML. De forma predeterminada, los datos se obtienen como XML. Para obtener el resultado como JSON, solo hay que añadir una petición JSON en el encabezado de la consulta (antes de la primera declaración):
Overpass XML | Overpass QL |
---|---|
<osm-script output="json">
<query type="node">
<has-kv k="name" v="Gielgen"/>
</query>
<print/>
</osm-script>
|
[out:json];
node["name"="Gielgen"];
out body;
|
Formato CSV (valores separados por comas): véase página wiki Overpass QL.
Mostrar resultado: mapa OpenLayers, JSON, XML.
Opciones de gestión de recursos (osm-script)
El osm-script se añade silenciosamente si no se especifica explícitamente al usar la sintaxis XML. La razón para especificar uno explícitamente es ajustar las opciones de gestión de recursos mediante el establecimiento de atributos XML opcionales (las opciones equivalentes entre corchetes también pueden especificarse en una declaración vacía al inicio de la consulta cuando se utiliza la sintaxis QL).
Overpass XML | Overpass QL |
---|---|
<osm-script timeout="900" element-limit="1073741824">
<bbox-query s="51.15" w="7.0" n="51.35" e="7.3"/>
<print/>
</osm-script>
|
[timeout:900][maxsize:1073741824];
node(51.15,7.0,51.35,7.3);
out;
|
Esta consulta extiende el tiempo de espera de 3 a 15 minutos (escrito como 900 segundos). Además, la cuota baja de uso de memoria se establece en 1 GiB (equivalente a 1073741824 byte).
Advertencia: al ejecutar este ejemplo se recuperarán más de 100 MiB de datos (aunque no se recupere hasta dar todos los detalles como en el primer ejemplo, aquí solo se recuperará una lista plana de nodos con sus etiquetas). Overpass te avisará si lo ejecutas directamente en tu navegador para representar los datos en el mapa, la pestaña del navegador puede fallar si continúas cargándolo. Los resultados de solicitudes tan grandes deben ser descargados para ser procesados por otras herramientas.
Estos límites de recursos no pueden establecerse a valores altos arbitrarios: cada instancia de la API de Overpass puede negarse a extenderlos por encima de algún umbral (dependiendo de las capacidades del servidor o de la carga actual del servidor), o la consulta puede simplemente fallar con un mensaje de error (y un estado de error del servidor HTTP no OK).
Véase también
- Overpass API
- Referencia de lenguaje
- Ejemplos
- Ejemplos avanzados
- Preguntas frecuentes
- Edición dispersa
- Introducción a la API de Overpass (fr) por Boris Mericskay
- Consultas de OSM (en), una colección de consultas para ayudarte a usar la API de Overpass de OpenStreetMap.