um die Datenmenge bei einer overpass-Apo-Abfrage zu minimieren möchte ich eine spezielle Abfrage definieren.Kann mir einer dabei behilflich sein ? Gesucht werden
highway=primary & oneway=yes ohne junction=roundabout und wenn dann noch möglich einer Max. Länge und wenn dann noch möglich ein in sich geschlossener way - letzteres muss ich wohl später prüfen.
Ebenfalls offtopic: Bei den immer mal wieder thematisierten Sammelrelationen (von denen ich absolut kein Anhänger bin) wird immer mal wieder darauf verwiesen, dass man “alle Theater in Hamburg” oder die Badeseen eines bestimmten Landkreises etc. doch über die Overpass-API abfragen könnte, aber wenn ich das richtig verstehe, geht das bisher nur unscharf, also mit (rechteckiger) Bbox bzw. mit (vermutlich kreisförmiger) Suche um einen Mittelpunkt, oder hab ich da was übersehen?
Sehr interessant und sehr gut versteckt …
Kannst du mal ein Beispiel für die Benutzung von “area-query” posten ?
Vielleicht mit der Grenze (admin_level 6) für Münster: rel 62591
Habe mal die Abfrage mit url wie Brogo in #5 geschrieben hat, dann kann ich bei einer Fensterauswahl sehen das Elemente da sind - aber sichtbar sind keine.
kann man immerhin jetzt schon direkter alle vorhandenen Areas finden. Bald sollte dann auch eine Abfrage im Stil von
area[name="Münster"];>;out meta;
einen kompletten Extrakt liefern, aber das ist noch nicht implementiert und wird wahrscheinlich auch nicht genau die Syntax bekommen. Die Erweiterungen werden wahrscheinlich Ende Oktober bis Mitte November fertig sein. Dann schreibe ich auch eine korrespondierende Dokumentation. Die alte Syntax wird aber weiterhin funktionieren.
Roland, danke für die Arbeit! Das ist noch mal wieder eine sehr nützliche Erweiterung. Auf die 3.6 Mrd muss man allerdings auch erstmal kommen, aber irgendeinen Grund wird’s schon haben.
Dann können wir uns ja im Spätherbst mal die Collection-Relationen vornehmen, Ersteller anschreiben etc.
wo es mir (und einigen anderen) drum geht, wäre die Möglichkeit alternativ zu einer Bounding-Box ein Polygon angeben zu können.
Also irgendwie so etwas:
Münster ist ein gutes Beispiel, da es mehrere Orte mit dem Namen Münster gibt (siehe den EIntrag bei Wikipedia) und Münster sowohl eine kreisfreie Stadt als auch ein Regierungsbezirk ist. Name wird also kaum zur Identifizierung ausreichen.
Innerhalb des Query-Statements können alle Kriterien (Keys, Values, Bounding-Boxen, Way-/Relation-Mitgliedschaften etc., und eben auch, in einer Area zu liegen) frei kombiniert werden.
Die 3.6 Mrd sind ein historisches Artefakt: irgendwie wollte ich die IDs kanonisch von den Element-IDs ableiten, aber alle Elementarten zulassen. Je nach Art des Basiselements werden entweder 0 (für Nodes), 2.4 Mrd (für Ways) oder 3.6 Mrd (für Relations) zur Id dazuaddiert. Areas, die sich von Nodes ableiten, hat es bisher nicht gegeben, Areas, die sich von Ways ableiten, teilweise schon. Die Größenordnungen beruhen auf Schätzungen, wie weit der Nummernraum ausgenutzt wird, und nutzen den Nummernraum von 0 bis 2 hoch 32 = etwa 4.2 Mrd recht gut aus.
Bei den Node-Ids werden wir sicherlich im Laufe von 2013 an die Grenze von 2.4 Mrd kommen, so dass ich umnummieren müsste und daher auch jetzt von einem expliziten Id-Zusammenhang herunter will. Daher auch die zurückhaltende Dokumentation und bessere Suchtools.