Hallo,
die Overpass API bietet die Möglichkeit, den Stand der OSM-Daten zu einem Stichtag zu ermitteln.
Wie kann man eine CSV-Liste der Anzahl der Edits in der Region pro Tag ermitteln, um eine Ganglinie zu zeigen. Ggf. noch mit Definition eines Startdatums oder Definition bestimmter User?
Was ist eine Ganglinie? So etwas wie eine Fieberkurve?
Hier https://ohsome.org/apps/dashboard/ kann ich eine (kleine) Region auswählen; Dann Filter LEER, Osm-Type auf NODE+WAY (Relation nicht, das dauert, konnte es nicht erwarten), Gruppierung auf TYPE, Zeitbereich auf zB 8.1.2022T0:00 bis 9.1.2022T0:00 Intervall Stündlich und recht schnell erscheint ein Plot.
CSV holen unter “Download”, dann seh ich im office calc, in dem Bereich wurden an dem Tag ein Weg und zwei Knoten gelöscht um 17:00 und um 11:00 ein Knoten angelegt.
Sorry, deren Benutzer-Schnittstelle ist so intelligent, dass ich gar nichts eingeben kann. Ich schaffe es nicht einmal, den SEND-Button aktiv zu halten …
Dieses Beispiel; also Anzahl der NWR in einer Region, aber z.B. für die letzten 100 Tage und / oder für einen definierten User. Das soll dann eine Liste ergeben
Geniales Tool, konnte es auch gleich intuitiv bedienen.
Ganz klar sind mir allerdings die Ergebnisse nicht:
Für meine Abfrage ist die Anzahl der Nodes immer deutlich kleiner als die Anzahl der Ways.
Da Ways typischerweise aus mehreren Knoten bestehen, erwarte ich es umgekehrt.
Aber vielleicht werden nur Nodes mit tags gezählt ?
Was mich am meisten erstaunt, wie schnell das Ohsome dashboard geht!
Stimmt, die Rechnung geht nicht auf. Die Vermutung leuchtet ein; Filtern geht ja nach Tags; Leerer Filter heißt dann wahrscheinlich, egal welcher Tag, die ohne Tag bleiben aber trotzdem außen vor?
Was geht noch unter: Änderungen am Verlauf eines Wegs oder am Umriss einer Fläche zB.
Das API hat noch andere Endpunkte als “elements”, ich seh aber nicht, wie man mit einem von denen vollständigere Ergebnisse bekommen könnte.
https://overpass-turbo.eu/s/1f63 zeigt in der aktuellen bounding box die Zahl der Nodes und Ways auf Monatsbasis (von 2021-01 bis 2022-01). Relationen habe ich ausgeklammert, ebenso die Areas, weil beides unnötig teuer ist. Die Query läuft auf der offiziellen instanz je nach bbox bisweilen recht lange oder auch gar nicht.
Ich habe mal 2 User eingebaut, dann ist gleich klar, wie das läuft. Wenn Overpass noch sauber mit Monaten rechnen könnte, könnte man auch die ganzen retros durch eine Schleife ersetzen.
Sehr vorausschauend von Dir! Die Query läuft und liefert Zahlen, die Ergebnisse verstehe ich nicht: Als Erfolgskontrolle und insbesondere Motivationshilfe möchte ich eine Gangline der von unserer Gruppe bearbeiteten (und ggf. auch der neu erstellten) Nodes / Ways.
Die aktuelle Abfrage liefert für die letzten Tage (ab 12.01.2022) identische Zahlen, obwohl ich vorgestern definitiv Punkte bearbeitet (nicht neu erstellt) habe.
Ich sehe da zwei Effekte. Zum einen läuft die Query auf einer Entwicklungsinstanz mit einer randvollen SSD. Damit das ganze nicht irgendwann unkontrolliert zusammenbricht, hatte ich die Updates gestern angehalten. Im Moment laufen die Updates wieder…
Zur Zählweise: mir sind einige Nodes aufgefallen, die schon vor 4 Monaten von dir bearbeitet wurden (https://www.openstreetmap.org/node/8736355755/history), und dann gestern wieder. Die Aufwertung schaut jeweils zum Stichtag auf die Objekte und den jeweiligen letzten Bearbeiter. Ändert sich da nichts, bleibt die Zahl auch weiter unverändert.
Um nur die Änderungen seit dem letzten Tag zu zählen, müsste die Query weiter aufgebohrt werden und jeweils ein (if:timestamp >= “… zeitstempel von gestern”) ergänzt werden. Das klappt dann aber nicht mehr mit overpass turbo und müsste irgendwie per Script oder so generiert werden.
Mist! Wie entsteht denn der “grüne Teppich” von Pascal Neis in HDYC? Eigentlich suche ich ja dieses Ergebnis, allerdings als Zahlen-Liste, nicht als Bild.
Das dachte ich zunächst auch, aber in Zeile 12 sind “6 Nodes” drin. Der Rest ist aber 0. Wichtig: deine Änderungen müssen auch immer in der Relation https://www.openstreetmap.org/relation/62484 drin sein, sonst zählt das nicht mit.
Wenn ich die Einschränkung auf Landshut rausnehme, sehen die Zahlen so aus:
Also für Bayern (Relation 2145268) kann ich die Query für ~ 15 Tage ausführen. Die Instanz hat ein hartes Resourcenlimit und bricht Queries nach 2 Minuten ab. Das soll auch dazu dienen, dass die Leute nicht zuviel Kapa auf der Entwicklingsinstanz verbraten oder das ganze produktiv nutzen wollen.
Schick mir am besten mal ein Beispiel, was genau nicht funktioniert. Vielleicht reicht es schon aus, das ganze auf mehrere Queries aufzusplitten. Auf den produktiven Instanzen benötigt 1 Tag etwa 1,5 Minuten, da das Coding für solche Abfragen nicht (genug) optimiert ist.
Alternative ist natürlich immer ein Extrakt zu verwenden (die gibt’s auch als Full History) und dann die Dateien selbst weiter zu analysieren.