Daten des Fahrradzählers an der Gurlittinsel sind online

    Gefunden auf facebook: https://www.facebook.com/photo.php?fbid…pe=3&permPage=1

    Die Daten des Fahrradzählers an der Gurlittinsel sind online: https://geoportal-hamburg.de/verkehrsportal/#

    Das ist total super: Oben links auf „Themen“ klicken, dann „Fachdaten“ aufklappen, dann „Planungsdaten“ aufklappen, dann „Verkehrszählstellen Hamburg“ aufklappen, dann die „Zählstellen Radverkehr“ anwählen. Wie man nun an die Daten kommt muss ich mir mal anschauen. Das Ding ist kompliziert, da hilft auch ein Informatikstudium nicht weiter.

    wenn man tatsächlich nur die aktuellen daten (heutigen tag oder halt aggregate der tageswerte der aktuellen woche oder wochenwerte des aktuellen jahres) bekommt, dann wäre es super wenn da jemand einen cron-job einrichten könnte. nudge, nudge

    siehe auch http://suche.transparenz.hamburg.de/dataset/radver…saulen-hamburg2 . Wenn man bohrt findet man zwar, dass es Daten seit 2018-02-21T00:00:00 gibt, aber die Daten selbst finde ich wieder nur für heute.

    In https://geodienste.hamburg.de/HH_WFS_Radverk…ies&SERVICE=WFS steht irgendwas über temporal filtering. Ab hier bräuchte es dann doch einen Geoinformatiker oder jemand mit mehr Zeit/Interesse als mich.

    Bisher kriege ich auch nur einen Tag. Stellen sich noch die Fragen...

    -wann der letzte Tag bereitgestellt wird

    -ob man an detailliertere Daten rankommt. In den Originaldaten vom Zähler wird z.B. nach Richtung gezählt.

    Ja, witzig, heute Nacht um 2 Uhr kamen noch die Daten vom 10. April, jetzt kommen die für den 11. April. Das ist jetzt nicht so cool wie ich mir das erhofft hatte.

    Ich habe mal über das dortige Kontaktformular eine Anfrage rausgeschickt.

    Wo ist da jetzt das Problem? Kannst du ja einfach jeden Tag um Mitternacht automatisiert von einem Skript die Daten abgreifen und in eine DB schreiben. Dann kannst du es in Ruhe weiterverarbeiten.

    Ich mache sowas immer am Raspberry Pi in Perl per Cronjob

    Code
    no warnings 'utf8';
use LWP::Simple;

my $Site = @ARGV[0];
my $Site_Content = get($Site);
print $Site_Content;

    perl Skript.pl Seitenname > Output.txt

    Und dann 'Output.txt' lokal weiterverarbeiten

    Ich habe schon versucht einen TIME-Parameter zu senden, aber der wird ignoriert. Ich vermute dass deren Anwendung nur immer den letzten Tag rausgibt.

    Einfach täglich auslesen und speichern (Lizenz beachten!), dann passt das.

    Solange Dummheit als plausible Erklärung ausreicht, sollte man keinen Vorsatz annehmen.

    Zitat von David Scott

    Wo ist da jetzt das Problem? Kannst du ja einfach jeden Tag um Mitternacht automatisiert von einem Skript die Daten abgreifen und in eine DB schreiben. Dann kannst du es in Ruhe weiterverarbeiten.

    Mitternacht haut schon mal nicht so ganz hin, das passiert irgendwann zwischen 2 Uhr und 8 Uhr.

    Aber theoretisch hast du recht, das ist kein Problem. Problematisch ist es nur, wenn:

    1. mein Server mal kaputt ist und die Daten nicht einsammelt
    2. deren Server zu jener Zeit oder womöglich mehrere Tage lang defekt ist
    3. sich das Format der Ausgabe verändert und ich das nicht gleich binnen eines Tages anpasse

    Schon fehlen plötzlich Daten, was wiederum recht ärgerlich ist, wenn man kontinuierlich über das ganze Jahr hindurch eine Summe bilden möchte. Insofern wäre es schöner, wenn man einfach den Tag angeben und die Werte einsammeln könnte, gerade wenn man gerne ab dem 1. Januar eine Summe bilden möchte.

    Schöner wäre es, keine Frage. Wenn aber immer in der Nacht die Daten des Vortages bereitgestellt werden hast du ja quasi 24 Stunden Zeit die herunterladen.

    Zu 1: Ja, das Skript muss halt irgendwann innerhalb von 24 Stunden mindestens einmal erfolgreich durchlaufen, hast ja aber mehrere Versuche dabei

    Zu 2: Das wäre wirklich blöd, da kann man dann nichts machen, entsprechende Lücken würde ich in der Auswertung extra hervorheben

    Zu 3: Kein großes Problem, einfach z.B. für jeden Wochentag ein eigenes Textfile erstellen, Auswertung_Mo.txt, ... und erst nach einer Woche überschreiben

    Witzig, dass hier alles das Ding technisch betrachten, mich eingeschlossen. Ich frage mich aber eher etwas anderes: hat das Ding ohne eingebautes Archiv einen großen Mehrwert? Was sehe ich da am 2. Januar 2019? Nix?

    Die Aussage eines solchen Zählers ist eigentlich "es wird das ganz Jahr durch viel Rad gefahren, hier sind die Zahlen aus den vergangenen Jahren. Radinfra ist wichtig". Das fehlt mir hier bisher. Ja okay, besser als nix, aber da ist schon noch Luft nach oben.

    Gab es eigentliche eine PM zu dem Ding? Ist es fertig oder eher noch work in progress?

    Zitat von Gerhart

    Ich habe schon versucht einen TIME-Parameter zu senden, aber der wird ignoriert.

    Angesichts der grundsätzlichen Benamung der Parameter halte ich es ja für ausgesprochen optimistisch, da etwas mit time zu versuchen ;)

    Zitat von David Scott

    Zu 3: Kein großes Problem, einfach z.B. für jeden Wochentag ein eigenes Textfile erstellen, Auswertung_Mo.txt, ... und erst nach einer Woche überschreiben

    Ah, jetzt kapiere ich, was du oben schon meintest. Das wäre in der Tat eine gute Lösung.

    So, bei mir läuft nun der folgende Cron-Job:

    Code
    curl 'https://geodienste.hamburg.de/HH_WFS_Radverkehrszaehlsaeulen?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&typename=app:zaehlsaeulen' -o "/var/www/vhosts/fahrradstadt.org/meter-data/data-$(date +'%Y-%m-%d-%H-%M-%S').xml"

    alte Daten macht zumindest diese Schnittstelle offenbar nicht verfügbar. Jedenfalls sagt es bei "REQUEST=DescribeFeatureType" nur, dass alle Daten vom Typ String seien. Da es kein Wissen darüber hat, dass es sich um zeitbasierte Daten handelt, dann kann es auch nicht zeitbasiert einschränken.

    Malte, was hast Du die Leute denn gefragt? Wahrscheinlich die relevanteste Frage wäre wohl, wie/über welche API ihre Daten täglich aktualisiert werden und wer da der Ansprechpartner ist.