Pl:Overpass API/FAQ

From OpenStreetMap Wiki
Jump to navigation Jump to search
Overpass API logo.svg
edit
Overpass API · Odniesienie do języka API · Przewodnik językowy · Terminologia fachowa · Obszary · Przykłady zapytań · Rzadkie edycje · Stałe ID · FAQ · więcej (polski) · Strona internetowa
Status serwerów · Wersje · Rozwój · Projekt techniczny · Instalacja OSM3S servera · Warstwa zgodności XAPI · Render linii transportu publicznego · Aplikacje · Kod źródłowy i problemy
Overpass turbo · Asystant · Skróty Overpass'a turbo · Arkusze stylów MapCSS · Eksport do GeoJSON · więcej (polski) · Rozwój · Kod źródłowy i problemy · Strona internetowa
Overpass Ultra · Examples · Overpass Ultra extensions · Arkusze stylów MapLibre · URL Params · więcej (polski) · Kod źródłowy i problemy · Strona internetowa

Zapytania

Dlaczego moje zapytanie nie pokazuje oczekiwanych linie (way) na mapie?

Upewnij się, że zapytanie zwraca również węzły używane przez linie. Zazwyczaj można to zrobić za pomocą:

  <union>
    <recurse type="way-node"/>
  </union> 

Dlaczego moje zapytanie nie zwraca niczego? Dlaczego strona z mapą testową zawiesza się na "Wyszukiwaniu ..."?

Upewnij się, że zapytanie jest poprawne pod względem składni. Na przykład, jeśli korzystasz z XML, upewnij się, że nie brakuje ci ukośnika (/) lub tagu zamykającego.

Czy dwa zapytania znajdują się w zespole AND lub OR?

One są OR.

Jak wyglądałoby zapytanie, aby wszystkie relacje zostały otagowane za pomocą type=boundary lub type=multipolygon i ich way-members oraz węzły używane przez te way-members?

Można to zrobić w ten sposób:

[timeout:86400];
( rel[type=boundary];
 rel[type=multipolygon];
);
( ._;
way(r);
node(w);
);
out;

Przejdźmy przez przykład:

[timeout:86400];

jest konieczny w tym przypadku, ponieważ spodziewamy się naprawdę dużego wyniku. 86400 to ilość czasu w sekundach i oznacza, że spodziewamy się, że środowisko wykonawcze będzie działać przez cały dzień. Domyślna wartość to 180 sek., co dobrze pasuje do zwykłych limitów czasu przeglądarek lub innych klientów HTTP.

rel[type=boundary];

zbiera wszystkie relacje z bazy danych, które mają znacznik z kluczem "typ" i wartością "boundary". Wynik jest przechowywany w pamięci serwera zapytań, w kontenerze "_", ponieważ jest to zachowanie domyślne.

Jeśli chcesz zobaczyć, co się wydarzyło do tej pory, możesz wydrukować zawartość kontenera w tym momencie:

http://overpass-api.de/api/interpreter?data=rel[type=boundary];out;

Podobnie, rel[type=multipolygon]; zbiera wszystkie relacje z bazy danych, które mają znacznik z kluczem "type" i wartością "multipolygon". Sprawdź wyniki za pomocą

http://overpass-api.de/api/interpreter?data=rel[type=multipolygon];out;

To jest dość dużo danych.

Teraz union statement wchodzi w życie. Wykonuje kopię każdego wyjścia i tworzy w wyniku union każdego wyjścia.

( rel[type=boundary];
  rel[type=multipolygon];
);

Oznacza to, że tutaj, najpierw wyjście z rel[type=boundary]; jest zbierane, a następnie wyjście z rel[type=multipolygon]; jest zbierane.
Związek obu jest przechowywany na końcu deklaracji w kontenerze "_" i zastępuje zawartość kontenera "_" po ostatniej poddeklaracji, "rel[type=multipolygon];".
Aby zobaczyć zawartość kontenera "_" w tym miejscu, uruchamiamy

http://overpass-api.de/api/interpreter?data=(rel[type=boundary];rel[type=multipolygon];);out;

Na poziomie semantycznym mamy teraz w kontenerze "_" wszystkie relacje, które są type=boundary lub type=multipolygon.
Przechodzimy teraz do drugiego bloku union:

( ._;
 way(r);
 node(w);
);

Pierwsza poddeklaracja, "._;", jest użyteczna tylko w bloku union: Ma jako wyjście w kontenerze "_" dane wejściowe z kontenera "_". Chociaż nie zmienia to kontenera "_", pozwala on na zbiorowe skopiowanie aktualnej zawartości kontenera "_" do własnego wyjścia.

Tak więc mamy teraz wszystkie relacje interesującego typu zarówno w kontenerze "_", jak i wewnętrznym pojemniku union.

Następna poddeklaracja, "way(r);" odczytuje dane wejściowe z pojemnika "_" i ponownie zapisuje dane wyjściowe do pojemnika "_", zastępując dane wejściowe. Tak więc na poziomie semantycznym "way(r);" umieszcza wszystkie "<code<ways" będące członami relacji interesującego typu w kontenerze "_". Ponieważ jest to podmenu union, ten blok union dodaje ten wynik do pamięci wewnętrznej.

Następna deklaracja "node(w);" ponownie odczytuje dane wejściowe z kontenera "_" i zapisuje jego dane wyjściowe do kontenera "_". Wyszukuje wszystkie "<node>", które są członami "way" wprowadzania danych. Ponieważ kontener "_" zawiera w tym momencie wszystkie way, które są członami relacji interesującego typu do kontenera "_", mamy teraz dokładnie te node, które chcemy w kontenerze "_". A ponieważ wciąż znajdujemy się w bloku union, wewnętrzne magazynowanie union zawiera teraz relacje (od "._"), drogi (od "way(r);") i węzły (od "node(w);"), czyli to chcemy. Na końcu deklaracji union, w kodzie źródłowym w ");", deklaracja umieszcza ją w kontenerze "_".

Jako ostatni krok wystarczy wydrukować to, dodając deklarację "out;". Jeśli chcemy meta informację, możemy użyć "out meta;". Jeśli chcemy przyspieszyć całość, spróbujmy "out qt;" który porządkuje elementy nie według typu, a następnie id, ale raczej według typu, a następnie lokalizacji, która jest szybsza dla danych wyjściowych. Należy zwrócić uwagę, że "+" to cgi escaping, co powoduje, że link jest klikalny, a nie jest częścią składni Overpass QL, ale jest automatycznie konwertowany przez serwer:

http://overpass-api.de/api/interpreter?data=[timeout:86400];(rel[type=boundary];rel[type=multipolygon];);(._;way(r);node(w););out+qt;

(najszybszy)

http://overpass-api.de/api/interpreter?data=[timeout:86400];(rel[type=boundary];rel[type=multipolygon];);(._;way(r);node(w););out;

(najczęściej)

http://overpass-api.de/api/interpreter?data=[timeout:86400];(rel[type=boundary];rel[type=multipolygon];);(._;way(r);node(w););out+meta;

(najbardziej wyraźny)

Drukowanie

Czy polecenie drukowania wydrukuje wszystkie wyniki wszystkich union lub tylko ostatniego?

Drukuje zawartość kontenera "_" w czasie wykonywania. Jest to bardzo zbliżone do "ostatniego".

Języki zapytań i składnia

Który język zapytań jest odpowiedni do czego?

Sugeruję użycie składni Overpass QL. Ten i język XML oferują tę samą semantykę, ale funkcja Overpass QL jest bardziej zwięzła. Overpass QL został utworzony, ponieważ język XML wygląda na zbyt uciążliwy dla większości ludzi.

O co chodzi z .->x or .->_?

Overpass ma imperatywny model wykonania. W szczególności deklaracje są wykonywane jedna po drugiej, a każda deklaracja zakończona jest średnikiem. Każde zdanie umieszcza swoje wyniki w pojemniku w swojej pamięci o nazwie, domyślnie "_". Jeśli deklaracja wymaga danych wejściowych, odczytuje ona dane wejściowe z "_". Na przykład deklaracja "print" czyta z "_".

Czasami przydatne jest użycie więcej niż jednego kontenera podczas bardziej złożonego zapytania. W takim przypadku dane wyjściowe można przekierować do innego kontenera, np. z nazwą "x". To właśnie jeśli chodzi o składnię kontroli.