Pl:Overpass API/FAQ
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 problemyOverpass 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
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.