Anzahl der Edits in einer Region pro Tag (Ganglinie)

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?

Danke, Michael

ist die Aufgabe gar nicht lösbar, auch nicht auf anderem Weg als Overpass?

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.

Kann man als Kurve plotten. Ist es so etwas? Lässt sich auch skripten, https://docs.ohsome.org/ohsome-api/v1/

Vielen Dank,

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

Datum      nodes    ways  relations
01.01.2022  220     33      4
02.01.2022  230     35      6

die später in einem Diagramm dargestellt (== Ganglinie) werden kann.

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.

Danke

Prima, (wie) kann ich da noch eine area und einen User mitgeben

area(3600062484)->.searchArea;
user:UserName

mitgeben?

Klar, das geht auch: https://overpass-turbo.eu/s/1f7b

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.

Vielen Dank!

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.

Vielen Dank für die Erläuterungen.

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.

Ich bin mir relativ sicher (weiß es aber nicht), dass er eine eigene PostgreSQL/PostGIS database nutzt und von der abfrägt.

Mit etwas copy&pasta kann man das auch schnell zusammenklimpern: https://overpass-turbo.eu/s/1f7l

Das Datum nach dem “timestamp()” ist immer das vom jeweiligen Vortag.

Danke für Deine Mühe und Geduld!

Leider liefert das aber nur NULLen, auch wenn ich den “anotherUser” gelöscht habe.

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:


@count	@count:nodes	@count:ways	@count:relations
19	19	0	0
25	19	6	0
9	5	4	0
5	2	3	0
5	4	1	0
10	1	9	0
12	4	8	0
14	13	1	0
66	48	18	0
23	21	2	0
9	7	2	0
16	13	3	0
16	10	6	0
0	0	0	0
34	24	10	0


runtime error: Query timed out in "query" at line 22 after 124 seconds.

(Diese Query ist super teuer, deshalb auch der Timeout nach 2 Minuten)

OK, danke

Mein Fehler! Trotzdem sehe ich auch mit Anpassung der Region die Zählung meiner Änderung gestern / vorgestern nicht.

Argh, da war ein Tippfehler in Zeile 20 hinter timestamp() drin… https://overpass-turbo.eu/s/1f7r sollte besser klappen (mit Relation 29996).

Das ganze nochmal auf einer Karte dargestellt: https://overpass-turbo.eu/s/1f7s

Herzlichen Dank!

Das funktioniert prima … für wenige Tage bzw. Nutzer und kleine Gebiete. Die Lösung merke ich mir für zukünftige Aufgaben.
Mein aktuelles Ziel

  • Mehrere Nutzer
  • Ganglinie über einige Wochen / Monate
  • größere Gebiete, z.B. NRW oder Bayern
    erreiche ich so nicht. Falls also jemand noch eine Idee hat …

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.