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.)
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 
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?
Moin !
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:
Gruß Jan
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.
Moin !
der Ansatz ist ja schon gut - jetzt hätte ich gerne nur noch gleich am liebsten die Adress-Daten mit angezeigt.
Gruß Jan
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
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.
Nahmd,
Bei mir schaut es so aus. Spalten 1 bis 7 aus dem Feature, ab Spalte 8 (Namen in []) über die Relation.
Gruß Wolf
So, jetzt zeig uns noch deine Overpass Query dafür. 
da bin ich auch mehr als gespannt !
Jan
Er hat eine eigene Datenbank! Wahrscheinlich benutzt er die für die Abfrage.
Nahmd,
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”.
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):
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)
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
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 …
Mit overpass geht nur die Variante: relation ohne Orts-Node: http://overpass-turbo.eu/s/7u6
Das mit dem Vergleich klappt heute noch nicht.
Interessant. Details?
Ich interpretiere das als “alle place=*-Nodes”; Restaurants mit dem Namen einer Stadt sind wohl eher nicht erwünscht.
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