OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2015-02-02 12:55:08

Lübeck
Member
Registered: 2009-02-17
Posts: 2,555

Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Moin !

vor längerer Zeit haben wir uns auf dem Stammtisch darauf geeinigt, dass immer nur die Adresse einmal pro Haus erfaßt werden sollte und dann über eine site-Relation die POI damit verknüpft werden sollen. (doppelte Datenhaltung etc.)

siehe auch https://wiki.openstreetmap.org/wiki/L%C … n_Adressen

Ich möchte jetzt keine Diskussion über Sinn oder nicht hier herbeiführen. Meine Frage geht dahin ob man Geschäfte, aktuell Apotheken, abfragen kann und im Rückgabe-Ergebnis des POI auch die Adresse des Gebäudes wieder zu finden ist.

Gruß Jan :-)


Android 2.2 & 4.1.1 / Webkit 3.1 / PC: Win7 64bit

Offline

#2 2015-02-02 13:00:50

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Wenn die Auswertung so nicht klappt, dann ist das Ziel des Schemas vielleicht verfehlt? Abgesehen davon wie oft ändern sich in Lübeck die Hausnummern?

Offline

#3 2015-02-02 14:59:13

Lübeck
Member
Registered: 2009-02-17
Posts: 2,555

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Moin !

Abgesehen davon wie oft ändern sich in Lübeck die Hausnummern?

Das ist ja nicht das Thema - die Adressen sind ansonsten redundant und nicht alle POI werden in allen Karten gerendert. Dann wäre die Hausnummer oftmals mehrmals dargestellt.

Sicher wir taggen nicht für den Renderer - aber Außenstehende sehen unser Ergebnis jetzt und halten es ansonsten für unqualifiziert.

Nicht umsonst steht auf unserer Wikiseite:

Die hier beschriebene Vorgehensweise ist als vorübergehend zu betrachten. Wenn die Render (die Mehrheit der auswertenden Programme) in der Lage sind Relationsangaben (Adresse) korrekt zu rendern, dann ist es beabsichtigt die Angaben an die Relationen zu übertragen. Derzeit wird die Adresse an dem Haus / Eingang geführt um diese den Nutzern mehrheitlich in Kartenform anbieten zu können.

Gruß Jan


Android 2.2 & 4.1.1 / Webkit 3.1 / PC: Win7 64bit

Offline

#4 2015-02-02 17:24:15

kartler175
Member
Registered: 2012-09-10
Posts: 233

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Mit folgender Abfrage erhälst Du Apotheken (als amenity-node) und die zugehörigen Releationen und deren Mitglieder:

<osm-script output="xml">
    <query type="node">
      <bbox-query {{bbox}}/>
      <has-kv k="amenity" v="pharmacy" />
    </query>    
  <union>
    <item/>
    <recurse type="node-relation"/>
    <union>
       <item/>
      <recurse type="down"/>   
    </union>
  </union>
  <print limit="" mode="meta" order="quadtile"/>
</osm-script>

Für die konkrete Zuordnung der Apotheken zu bestimmten Adressen brauchst Du wohl eine Auswertung der gelieferten Daten.
Ich glaube, Overpass ist prinzipell nicht geeignet zur Übertragung von Informationen zwischen Objekten.

Offline

#5 2015-02-02 19:24:26

Lübeck
Member
Registered: 2009-02-17
Posts: 2,555

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Moin !

der Ansatz ist ja schon gut - jetzt hätte ich gerne nur noch gleich am liebsten die Adress-Daten mit angezeigt.

Gruß Jan :-)


Android 2.2 & 4.1.1 / Webkit 3.1 / PC: Win7 64bit

Offline

#6 2015-02-02 20:04:44

TheFive
Member
Registered: 2009-05-03
Posts: 1,566
Website

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Hi Jan,

Ich hatte da schonmal bei mmd und Roland nachgefragt:
https://github.com/drolbr/Overpass-API/issues/187
Dort gibt es von mmd auch einige interessante Abfragen.

Parallel hab ich einen Branch in meiner Software, der für jede Apotheke eine Nominatimabfrage macht, um die Adresse rauszusuchen.
Prinzipiell klappt das gut, aber um das täglich aktuell zu halten muss ich dann die Änderungen bei den Apotheken in meiner DB nachziehen.
Ist also noch nicht in einem Live Status, ich bin aber dran, meine Erfahrung, das OSM Count in der ersten Nacht gleich die Grätsche gemacht hat, hat mich aber zurückhaltend werden lassen :-)

(Hintergrund: Nominatim bittet bei Heavy Usage, was 22.000 Apotheken ja wären, um caching, ausserdem sind die bei der Erlaubnis von Massengeocodierungen zurückhaltend).

Eine Nominatim Abfrage um die Adresse für eine ID rauszubekommen, ist aber echt simple, und geht wohl flott (ich gehe davon aus, das die das für eine OSM ID im Speicher haben).

Christoph

Offline

#7 2015-02-02 20:13:14

kartler175
Member
Registered: 2012-09-10
Posts: 233

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Lübeck wrote:

jetzt hätte ich gerne nur noch gleich am liebsten die Adress-Daten mit angezeigt.

Wo? Wie? Die Daten dazu sind ja vorhanden. Du musst sie halt zusammenführen und zur Anzeige bringen. Das ist das einzige, was ich mit deinen dürftigen Informationen sagen kann.

Offline

#8 2015-02-02 23:20:04

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Nahmd,

Lübeck wrote:

der Ansatz ist ja schon gut - jetzt hätte ich gerne nur noch gleich am liebsten die Adress-Daten mit angezeigt.

Bei mir schaut es so aus. Spalten 1 bis 7 aus dem Feature, ab Spalte 8 (Namen in []) über die Relation.

Gruß Wolf

Offline

#9 2015-02-03 20:27:15

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Netzwolf wrote:

Bei mir schaut es so aus.

So, jetzt zeig uns noch deine Overpass Query dafür. tongue

Offline

#10 2015-02-03 20:46:28

Lübeck
Member
Registered: 2009-02-17
Posts: 2,555

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

da bin ich auch mehr als gespannt !

Jan


Android 2.2 & 4.1.1 / Webkit 3.1 / PC: Win7 64bit

Offline

#11 2015-02-04 10:09:37

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Er hat eine eigene Datenbank! Wahrscheinlich benutzt er die für die Abfrage.

Offline

#12 2015-02-04 13:41:34

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Nahmd,

Lübeck wrote:

da bin ich auch mehr als gespannt !

Es gibt keine. Mit Overpass kenne ich mich nicht aus. Sorry für das OT. Mich interessieren einfach ungewöhnlich Anfragen als Futter, um zu sehen, ob ich die hinbekomme.

Als oller Unix-Freak hab ich mir ein paar Tools gezimmert, mit denen ich auf einer täglich aktualisierten binären Version des Planets suchen kann, und baue mir eine Kommandozeile, die das gewünschte Resultat produziert. Abfragesprach ist also "/bin/sh". smile

Deine Abfrage ist interessant, weil die bisher komplizierteste: sie besteht aus 6+1 Kommandos (das "+1" steht nicht für eine Bewertung, sondern für die nicht wirklich nötige abschließende Sortierung der POIS); die banale Adressabfrage hat die komplexere Bestimmung der PLZ-Irrläufer (5+1) überholt.

Zurück zum Thema:

ich halte die Building-Relation für den beabsichtigten Zweck für ungeeignet. Ich halte es mehr für die Eigenschaft eines Pois, in einem Gebäude zu residieren, als für eine Eigenschaft des Gebäudes, den Poi zu beherbergen. Besteht ein Building aus mehreren Teilen, so impliziert das rel[type=building], dass alle Pois in jeweils allen Gebäudeteilen residieren. Speichere ich die Zuordnung dagegen beim Poi, so bin ich flexibler: ich kann einen Poi in nur einen Gebäudeteil setzen oder auch in zwei Gebäude.

Meine Vorschläge wären (mir ist klar, dass beide nicht mehrheitsfähig ist):

1. Einführung eines neuen Objekt-Typen "Feature" zur Aufnahme von Attributen, dem die Geometrie ähnlich Member bei Relationen zugeordnet wird. Das bildet die bei unserer Konkurrenz verwendete Unterscheidung zwischen Feature und Geometrie ab. Einer der Vorteile ist, dass die Feature-Id unveränderlich ist, auch wenn die Geometrie von einer ersten Node über eine Darstellung als Fläche(Way area=yes) bis zu einer Darstellung als Area mit Löchern oder aus mehreren Komponenten bestehenden Fläche oder einer Fläche mit Löchern (Area/Relation tyle=multipolygon), dass die Feature-Geometrie als Handle zum Anbinden externer DB genutzt werden kann. Unrealistisch, weil Änderung der DB-Struktur nötig)

2. Einführung eines Relation(type=feature). Im Grunde identisch zu 1 mit allen Vorteilen, auch der (von Vandalismus/Unkenntnis agesehen) unveränderlichen Id. Zuordnung der Geometrie über eine noch zu definierende Role. Damit lassen sich beliebig viele POIs in einer Geometrie (einem Gebäude) unterbringen; die Zuordnung ist datenbanktechnisch über Verweise realisiert (inklusive referentieller Integrität) statt über Text- und/oder räumliche Suche und daher um ein Vielfaches schneller abzufragen. Unrealistisch technisch wegen der Behandlung von Relationen in den Editor-Programmen; ich möchte die Relationsbox von JOSM beim Laden einer größeren Innenstadt mir nicht vorstellen; unrealistisch auch wegen der allgemeinen Abneigung gegen die Verwendung von Relationen. Daher gefällt mir 1 besser, weil das Wort "Relation" dort nicht auftaucht. Aus gleichem Grund wäre ich auch für die Einführung von Area-Objekten, auch wenn die sich technisch nicht von Relation(type=multipolygon) bei Durchsetzung von Integritätsbedingungen auf dem DB-Server unterscheiden.

Zurück zur Abfrage selbst:

Schade finde ich, dass niemand mit einer PG-Datenbank Deine Abfrage programmiert hat. Das sollte mit zwei Joins erledigt sein, und wenn die geometrische Ausdehnung der rel[type=building] in der DB enthalten ist und bei der Abfrage berücksichtigt wird, sollten nur sehr wenige Objekte an der Abfrage beteiligt sein: mich hätte die Performance sehr interessiert.

Denn meine Abfrage der Apotheken in Lübeck mit per rel(type=building) zugeordneten Adressen über die Kommandozeilen-Toolchain braucht mit 2.9 Sekunden für die wenigen Zeilen Ergebnis viel zu lang und ist letztendlich ungeeignet, eine Postgres-Abfrage dürfte deutlich schneller ein.

Mein Thema sind aber Batchanfragen mit großen Ergebnissen, und in der Tat braucht die gleiche Anfrage für *alle* Amenities mit 3.5s nur unwesentlich mehr Zeit.

Zurück zu Deiner Anfrage:

nimm die bereits vorgeschlagen OP-Abfrage, lass das Ergebnis in XML-Form liefern und wandle es per XSLT in die von Dir gewünschte Form.

Gruß Wolf

Edit: URLS

Last edited by Netzwolf (2015-02-08 23:10:16)

Offline

#13 2015-02-04 17:58:50

stephan75
Member
Registered: 2008-05-28
Posts: 2,713

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Hallo Wolf,

kannst du mit deiner Datenbank auch viellecht folgende Abfrage umsetzen?

Finde in Deutschland alle Grenzrelationen mit admin_level=[6,7,8]
Ermittle für jede einzelne Grenzrelation mit name=abc123 alle Nodes innerhalb dieser Grenzrelation mit name=irgendwas,
Prüfe somit jeweils alle Nodes, ob einer davon den gleichen Namen mit name=abc123 hat,
Wenn dort KEIN gleichnamiger place-Node drin ist, sammle diese Grenzrelation in einer Liste.

oder in Kurzform:
finde alle Grenzrelationen ohne gleichnamige Orts-Node.

Geht das?

PS: jaa, sowas hatte ich schon vor einiger Zeit mal angefragt / zur Sprache gebracht ...

Offline

#14 2015-02-04 19:37:17

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

stephan75 wrote:

finde alle Grenzrelationen ohne gleichnamige Orts-Node.

Mit overpass geht nur die Variante: relation ohne Orts-Node: http://overpass-turbo.eu/s/7u6

Das mit dem Vergleich klappt heute noch nicht.

Offline

#15 2015-02-04 19:39:32

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

Netzwolf wrote:

täglich aktualisierten binären Version des Planets suchen

Interessant. Details?

Offline

#16 2015-02-04 20:37:46

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Spezielle Turbo-Overpass-Abfrage (über Relation hinweg)

stephan75 wrote:

Finde in Deutschland alle Grenzrelationen mit admin_level=[6,7,8]
Ermittle für jede einzelne Grenzrelation mit name=abc123 alle Nodes innerhalb dieser Grenzrelation mit name=irgendwas,

Ich interpretiere das als “alle place=*-Nodes”; Restaurants mit dem Namen einer Stadt sind wohl eher nicht erwünscht.

Prüfe somit jeweils alle Nodes, ob einer davon den gleichen Namen mit name=abc123 hat,
Wenn dort KEIN gleichnamiger place-Node drin ist, sammle diese Grenzrelation in einer Liste.

oder in Kurzform:
finde alle Grenzrelationen ohne gleichnamige Orts-Node.

Mit der heißen Nadel gestrickt:
Admin-Areas *mit* passender Place-Node (166k),
Admin-Areas *ohne* passende Place-Node (24k),
Admin-Areas *ohne* passende Place-Node mit allen unpassenden Place-Nodes (1.2M).
Braucht zusammen 28 Sekunden.

Gruß Wolf

Last edited by Netzwolf (2015-02-10 02:47:12)

Offline

Board footer

Powered by FluxBB