Ein Offener Ansatz zur Ermittlung von Verkehrsaufkommen anhand des Internet of Things
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 107 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61198 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
WebcamMultitier architectureInternetMoment (mathematics)Internet der DingeLecture/Conference
01:00
Annual average daily trafficOrganic computingInternetComputer animation
01:41
Annual average daily trafficInternetPascal's triangleInternetStudent's t-testMassXMLComputer animation
02:09
Data conversionScalar potentialSQLCodeAPIBilderkennungLinieWebcamInterface (computing)Raw image formatZahlInformationInternetDirection (geometry)Social classScalar potentialParticle detectorAlgorithmGeometryGeometryMultitier architectureObject (grammar)RivenSystems <München>SequenceFluxComputer fileGeomaticsScientific modellingComputer animation
07:54
IndexData modelReading (process)Tomcat <Programm>SQLData managementInterface (computing)DatabaseSound <Multimedia>Visualization (computer graphics)CodeAPIData conversionScalar potentialVisualization (computer graphics)AlgorithmCodeImplementationLink (knot theory)Source codeCountingInternet der DingeParticle detectorZugriffPrototypeVerschneidungPositionData conversionInternetTimestampLevel (video gaming)Server (computing)GeodesicSocial classObject (grammar)GeometryData streamWEBTransmitterSoftwareComputer animation
13:39
Scalar potentialScalar potentialInternet der DingeComputer animation
14:29
UMLLecture/Conference
14:46
WebcamJSONXMLUML
15:05
Interface (computing)Direction (geometry)WebcamZahlFRAMEWORK <Programm>Spielraum <Wahrscheinlichkeitstheorie>ZugriffSpeciesSupremumImplementationTOUR <Programm>SurfaceDataflowServer (computing)Computer animation
Transcript: German(auto-generated)
00:07
Ja, dann fangen wir an. Wir hören jetzt einen Vortrag von Sarah Schütz. Sie kommt ebenfalls von der Hochschule Mainz, ist dort Masterstudentin und wird uns die Ergebnisse von ihrer Bachelorarbeit vorstellen. Und sie hat Sensoren und freie Webcams untersucht und sich angeschaut, wie man
00:25
daraus, also anhand eines solchen Internet of Things, den Verkehrsfluss ableiten und und dafür Open-Source-Technologien eingesetzt. Ich bin gespannt, welche das sind. Viel Spaß. Okay, ja, dann auch von mir. Herzlich willkommen und vielen Dank, dass Sie da sind. Ich würde
00:43
den Vortrag ganz gerne mit einem kleinen Beispiel anfangen, um den Moment einfach zu nutzen, eine Einleitung zu finden, aber auch ein gewisses Bewusstsein allgemein nochmal zu schaffen. Sie sehen hier fünf Symbole, die repräsentativ für die fünf Sinnesorgane des Menschen und von Tieren. Der Körper eines Menschen und von Tieren ist generell schon
01:05
ein sehr geniales Objekt der Natur, da die Sinnesorgane einen sehr großen Beitrag zu leisten. Mir geht es aber heute mehr um die Funktion dieser Organe, denn uns als Menschen ist es möglich, über die Organe äußere Einflüsse oder Reize wahrzunehmen. Sie werden
01:20
verarbeitet und lösen bei uns eine Emotion und meistens eine Reaktion aus. Ein kleines Beispiel, ich mag zum Beispiel Hunde ganz gerne. Wenn ich einen Hund sehe, freue ich mich und setze mich meistens schon in Bewegung, um diesen zu streichen. Nur mal als Beispiel. Was das jetzt mit meinem Thema zu tun hat, da werden wir jetzt darauf eingehen. Das Thema lautet ein offener Ansatz zur Ermittlung von Verkehrsaufkommen anhand des Internet
01:44
of Things. Wie eben schon vorgestellt, mein Name ist Sarah Schütz. Ich bin aktuell Masterstudentin an der Hochschule Mainz und habe dieses Thema während meiner Bachelorarbeit letztes Jahr in Zusammenarbeit mit dem Herr Professor Neist bearbeitet. Das große Stichwort heute ist das Internet of Things, was im groben Rahmen das Äquivalent zu
02:06
den Sinnesorganen des Menschen darstellt. Denn auch im Internet finden wir sehr viele Sensoren, die Daten von äußeren Situationen aufnehmen. So zum Beispiel über Kameras, Thermometer oder Bewegungssensoren, die durch Geräte, die mit dem Internet verbunden
02:27
sind, erfasst werden können. Der große Unterschied hierbei ist jetzt der, dass wir im Internet diese Daten als Rohdaten vorliegen haben und als Nutzer dieser Daten die freie Entscheidung haben, was wir damit machen. Bei Menschen ist diese Reaktion
02:41
meistens aus Gewohnheit immer dieselbe. Und genau das habe ich in meinem Fall auch gemacht, dass ich mir Verkehrswebcamps angeschaut habe, die mir Bilder geliefert haben, die in etwa so aussehen. Nämlich eine Situation auf einer Straße von Fahrzeugen. Und ich wollte dann aus diesen Bildern ein Workflow entwickeln, um eine Aussage
03:04
darüber treffen zu können, wie stark ist die Verkehrsauslastung gerade auf dieser Straße, wo das Bild aufgenommen wurde. Und Anforderung war, dass der Workflow möglichst nachhaltig, offen und übertragbar auf andere Situationen sein soll. Denn die Webcams,
03:21
die die Straße beobachten, sind ja nicht der einzige Sensor in meinem Workflow. Ich werde zunächst dafür erstmal auf den Workflow an sich eingehen, danach auf die Besonderheiten und zum Schluss nochmal auf das große Potential dieses Anwendungsfalls. Erstmal zum Workflow an sich. Die Ausgangssituation war ein bisschen ernüchternd,
03:45
sage ich mal. Und zwar habe ich mir das Stadtgebiet von Mainz angeschaut, da dort meine Hochschule liegt und ich das als Anwendungsfall verwenden wollte. Dort lagen insgesamt 30 Verkehrswebcams vor, die mir Bilder zur Straßensituation liefern sollten. Nur, wie es ja meistens so ist, läuft es nicht immer ganz so glatt.
04:03
In dem Fall habe ich kein einziges Bild der Verkehrswebcams abgreifen können letztes Jahr im Sommer und bis heute immer noch nicht. Denn aufgrund der Kriegssituation in der Ukraine sind alle Verkehrswebcams innerhalb von Deutschland abgeschaltet, dass keine Verkehrsflüsse von Militärfahrzeugen nachvollzogen werden können.
04:22
Das stellt in erster Linie mir jetzt mal kein Problem dar, denn ich habe für Mainz dann zufällig erzeugte Werte verwendet, um diese Daten zu ersetzen und habe für den Workflow an sich, um die Daten aus Bildern zu gewinnen, Alternativen aus England mir gesucht. Zwei bis drei Webcams.
04:40
Sie sehen hier einmal den Workflow im Überblick. Ist auf den ersten Blick jetzt vielleicht ein bisschen viel. Wir werden aber im Folgenden auf jeden einzelnen Schritt noch mal näher eingehen. Zunächst mal zu meinen Datenquellen. Ich habe, wie eben auf dem Bild schon gezeigt, die Webcam-Positionen und Bilder über eine Schnittstelle abrufen können. Zudem habe ich für weitere Verarbeitung noch die Verwaltungsgrenzen
05:03
und die Straßengeometrien innerhalb der Stadt Mainz jeweils über ein WFS und OSM-Daten heranziehen können. Und ich denke, es wird schon relativ schnell klar, dass man in diesem Workflow versucht, aus einfachen Daten bessere Daten oder besser nutzbare Daten zu machen. Denn ich hatte in dem Fall, wie auf dem Bild mal beispielhaft
05:23
für drei Kamera-Stunde-Auto zu sehen, nur Punktobjekte vorliegen. Und wenn man sich jetzt mal überlegt, dass externe Nutzer, die eine Information über die Verkehrsauslastung wissen möchten, sich das anschauen und kriegen z.B. eine Zahl von 50 Fahrzeugen zu einem Punkt gesagt,
05:40
bringt das ja erst mal nicht so viel. Das heißt, ich möchte als Nutzer ja wissen, ist gerade in Richtung A oder Richtung B die größte Auslastung. Deshalb habe ich dann eine Auswertung vorgenommen, dass ich für jede Webcam einen Sichtbereich erfasst habe. In dem Fall händig, wenn mir die Daten nicht vorlagen.
06:00
Sie sehen den einmal hier in dunkelgrau, den ich dann mit den Straßengeometrien von OSM verschnitten habe, so dass ich nach einer kleinen Aufbereitung dann jeweils die Straßenabschnitte vorliegen hatte, die jede Webcam beobachtet hat. Zusammengefasst zu den Ergebnistaten
06:22
hatte ich dann, wie vorher auch schon, die Webcam-Standorte vorliegen, die einzelnen Straßengeometrien, also die Fahrspuren innerhalb der Sichtbereiche und jeweils die Relation, welche Kamera welche Fahrspurgeometrie beobachtet. So viel zu den Daten. Und ich denke in der Geoinformatik,
06:42
das kennen Sie wahrscheinlich, ist es ziemlich cool, dass man es sehr umfassend interaktiv oder interdisziplinär ausgestalten kann, was auch die nächste Methode zeigt. Denn, wie gesagt, habe ich Bilder als Eingangsgröße verwendet für diese Auswertung zu machen.
07:02
Für uns als Menschen, wir schauen auf das Bild und können zählen, wie viele Fahrzeuge sehe ich gerade. Doch für einen Computer ist es erst mal relativ schwierig zu sagen, wie viele Fahrzeuge sehe ich gerade dort. Dieser braucht nämlich meistens trainierte Modelle, Algorithmen oder andere Systeme,
07:21
um diese Auswertung zu machen. In meinem Fall habe ich auch auf einen Algorithmus zurückgegriffen, der eine Detektion innerhalb von Bildern machen kann. In dem Fall war das der YOLO V3-Algorithmus. YOLO steht in dem Fall für You Only Look Once. Das ist ein Algorithmus, der auf bereits ein trainiertes CNN zurückgreift.
07:40
Und für bestimmte Klassen eine Detektion vornehmen kann. Sie sehen das einmal hier, dass die Fahrzeuge, ich konnte angeben, welche ich detektieren möchte, mit einer Bounding Box und der jeweiligen Wahrscheinlichkeit der Klassenzugehörigkeit dargestellt ist. So war es dann möglich, dass ich diese Fahrzeuge, die detektiert wurden,
08:02
einfach zählen konnte. Auf Seite des Codes sieht das, Sie sehen hier mal nur einen kleinen Ausschnitt, einfach nur zur Demonstration, dass dieser Algorithmus relativ einfach zu bedienen ist. Sie sehen rechts die einzelnen Klassen, es sind noch viele mehr, in dem Fall nur 11 dargestellte,
08:21
die ich angeben kann, die ich detektiert haben möchte. In meinem Fall waren das Autos, Motorräder, Busse und LKWs, die ich dann, sehen Sie das bei dem zweiten Fall, angegeben habe zur Detektion. Die Daten an sich, die ich gezählt habe
08:41
und mit einer bestimmten Implementierung für jede einzelne Kamera und Straßenabschnitt nun vorliegen hatte, bringen mir ohne eine gute und entsprechende Speicherung erst mal relativ wenig. Weshalb wir jetzt zum, ich sag mal Herzstück des Workflows kommen, nämlich der Sensor Things API.
09:01
Vielleicht kennen Sie sie, es ist ein OGC-Standard, der eine IoT-Schnittstelle darstellt, also genau auf den Anwendungsfall des Internet of Things zugeschnitten ist. Sie sehen einmal die Klassenstruktur hier, die genau unseren Anwendungsfall abdeckt. Sie sehen oben links,
09:21
ich weiß nicht, ob Sie die Maus sehen, die Sensoren, das ist in dem Fall die Kamera, die die Bilder erfasst. Dann die Beobachtungsgröße, das ist in dem Fall die Anzahl der Fahrzeuge. Dann die einzelnen Observations, also die Beobachtung, das ist eine Anzahl,
09:41
die zu einem bestimmten Zeitpunkt, also eine Observation ist eine Anzahl, in dem Fall mit einem Zeitstempel, die erfasst wird von einem bestimmten Sensor und jeweils individuell zu einem Thing, also zu einem Objekt, einer Sache des Internets gehört. In dem Fall ist es unser Straßenabschnitt,
10:01
der von der Kamera beobachtet wird. Dieser hat eine Relation zu einer Location. Das sind die Geodaten, die wir zuvor durch die Verarbeitung gewonnen haben, nämlich durch diese Verschneidung, die einzelnen Straßengeometrien. Das in der Mitte, der Data Stream, sind genau die Daten, die von einem Sensor an einem bestimmten Straßenabschnitt
10:24
die Beobachtungswerte enthält. Ich denke, das wird gleich noch mal klar. Diese API habe ich, dass man einen besseren Zugriff hat, verwendet in einer Implementierung
10:40
in einem Web-Server. Dieser sogenannte Frost-Server ist vom Fraunhofer Institut veröffentlicht. Frost steht in dem Fall für Fraunhofer Open-Sensor-Things-API-Server. Somit war es relativ einfach, Daten auf diesen zu posten, aber auch abzufragen.
11:01
Die finale Visualisierung von den Daten, die ich erfasst habe, aus diesen Bildern, bringt für einen Nutzer, denke ich, am meisten in einer Web-Map, zumindest für private Nutzer, die zum Beispiel wissen wollen, wie stark ist die Straße ausgelastet, bevor ich losfahre, dass ich in keinen Stau komme.
11:21
In dem Fall habe ich auch eine Implementierung verwendet, nämlich die Sensor-Things-API-Map, oder STEM kurz gesagt. Die greift jeweils auf den Frost-Server zu und stellt genau die hinterlegten Locations der Things dar. Sie sehen das hier in blau. Das sind die einzelnen Geometrieobjekte, die wir auch vorher
11:41
aus der Verschneidung gewonnen haben. Die Karte ist interaktiv, sodass ich beim Draufklicken auf ein einzelnes Objekt dann den Namen der Things, also den Straßenabschnitt, in dem Fall eine spezielle Auffahrt in Mainz, angezeigt bekomme. Dort haben wir jetzt den Link zu einem Count-Objekt oder zu einer Count-Seite.
12:02
Das ist genau die Beobachtungsgröße, die vom Sensor erfasst wurde, genau an dieser Stelle. Wir haben in dem Fall nur die Anzahl, also nur eine Beobachtungsgröße. Hätten wir mehrere, würden dort mehrere stehen. Durch Klicken auf diesen Count bekommt man dann eine zeitliche Verteilung
12:21
der Beobachtungsdaten angezeigt. Also genau den Inhalt des Data Streams, genau an dieser Position. Denn jede Beobachtung hat ja einen bestimmten Zeitstempel und eine Anzahl der Fahrzeuge, die gezählt wurde. Das ist in dem Fall jetzt ziemliches Zickzack, weil ich für Mainz, da ich ja keine Bilder vorliegen hatte,
12:42
zufällige Werte erzeugt habe. Aber zu Demonstrationen vollkommen ausreichend. Wir sehen dann hier nochmal den Workflow in der Übersicht. Und ich denke, es wird schon klar, dass der Workflow an sich einen Prototypen darstellt, aber grundsätzlich die Hauptaufgaben
13:01
eines QS-Systems erfüllt. Nämlich die Eingabe, also die Eingangsdaten, die Verarbeitung, Verwaltung und am Ende die Präsentation. Ich würde jetzt gerne nochmal kurz auf die Besonderheiten der Umsetzung eingehen, besonders im Hinblick auf die Ziele, dass der Workflow möglich offen, übertragbar und nachhaltig
13:22
sein soll. Sie sehen hier einmal in der Übersicht meine verwendete Software, den Source Code und die Daten. Und es sind alles Bestandteile von Open Data. Das heißt, dieser Workflow ist für jeden möglich nachzubauen und zu implementieren.
13:41
Zum Ende nochmal kurz auf das Potential des Workflows. Da würde ich gerne nochmal auf das Beispiel vom Anfang zurückkommen. Denn wir als Menschen haben ja fünf Sinnesorgane. Im Internet of Things sind es unendlich viele. Und jeder hat ja individuell die Möglichkeit,
14:02
eine Auswertung daraus zu machen und bestimmte Ergebnisse für besondere Anforderungen zu kreieren. Demnach stellt dieser Workflow mit anderen Sensoren und anderen Auswertungen ein enormes Potential zum Beispiel für Städte dar, um andere Sensoren auszuwerten und so eine Weiterentwicklung
14:21
für Wirtschaft, die Stadtstrukturen, die Gesellschaft, aber auch für die Umwelt darzustellen. Damit bedanke ich mich für Ihre Aufmerksamkeit. Und Sie haben hier nochmal die Möglichkeit, die Präsentation kriegen Sie sowieso, das Projekt auf GitHub
14:41
sich nochmal anzuschauen oder die Präsentation herunterzuladen. Ja, ganz vielen Dank. Das war sehr, sehr spannend, sehr beeindruckend. Und wir haben auch ein paar Fragen bekommen.
15:00
Ach, da kommt gerade noch eine neue Frage dazu. Starten wir mal mit der ersten. Überlappen sich die Datenquellen? Kann man das gegebenenfalls rausrechnen? Also ich vermute jetzt mal, wenn zwei Webcams vielleicht den gleichen Straßenbereich erfassen. In dem Fall habe ich für die Stadt Mainz ja händisch Sichtbereiche erfasst, da ich keine Bilder
15:20
vorliegen hatte, wo ich erkennen konnte, welche Sichtbereiche jetzt erkannt werden. Natürlich kann man, wenn man diese Bilder vorliegen hat, versuchen, eine Georeferenzierung einzubauen, dass man genau erkennt, wo dieser Bereich jetzt genau liegt. In dem Fall habe ich es händisch erfasst und keine Überlappungen eingebaut. Okay, also in dem Fall hatten wir keine Überlappungen.
15:40
Dann wurde noch gefragt, wie die Unterscheidung zwischen den Fahrtrichtungen funktioniert. Ja, das ist tatsächlich noch ein Punkt, der sehr viel Spielraum lässt in dem Workflow. Da ich verschiedene Ansätze zur Segmentation der Bilder getestet habe,
16:00
dass ich die einzelnen Fahrspuren alleine ausgewertet habe und dann dem Sensor zugeordnet habe. Was man natürlich automatisiert auch noch machen kann, dass automatisch die Fahrspur erkannt wird und dementsprechend die Zahl der Richtung zugeordnet wird. Jetzt kommen hier gerade immer mehr Fragen.
16:22
Wurden auch nicht visuelle Sensoren getestet? Wo war es auch drin? In dem Fall nicht, nein. In dem Fall nicht. Und wir haben noch eine letzte Frage. Könnte man mit diesem Workflow theoretisch auch die Auslastung von Parkplätzen erfassen? Sicherlich auch eine spannende Frage. Auf jeden Fall, ja.
16:41
Ich könnte jetzt nochmal zurückgehen auf die Folie, wo die Fahrzeuge z.B. detektiert wurden, wie hier. Es ist so, dass diese Webcams mir auch im Minutentakt nur Bilder zur Verfügung stellen und keine Videos. Demnach würde sie sich das gut anbieten, einfach auch Bilder von Parkplätzen, wenn dort eine Kamera installiert ist,
17:01
die Bilder dazu auszuwerten. Ja, super. Alles sehr spannend. Wir haben auch erst 14 oder 47. Falls es noch weitere Fragen gibt hier im Raum, können wir die auch gerne noch... Wir hätten noch ein bisschen Zeit. Okay, ich würde mit dem Mikro gerade einmal rumgehen.
17:22
Und genau, dann kommt nochmal eine Frage aus dem Publikum. Genau, ich hatte die Frage gestellt mit den nicht visuellen Sensoren. Wäre der Framework generell für andere Arten von Sensoren geeignet? Ja. Also darum geht es in dem Workflow. Ich meine, die Verkehrsauswertung an sich bestellt jetzt am Ende auch nur eine Anzahl
17:40
der Fahrzeuge da, ohne Relation zu einer Maximalanzahl, weil es mir in diesem Workflow an sich nur um die Auswertung der Sensoren und die Verwaltung der Daten darstellt. Das heißt, man könnte diesen Part der Webcams auch einfach durch einen anderen Sensor austauschen und dann eine gewünschte Endimplementierung noch einbauen.
18:00
Zum Beispiel über ein Dashboard oder eine Karte oder irgendwas anderes. Jetzt kommt hier gerade auch nochmal eine weitere Frage. Vielleicht nehmen wir die noch gerade als letzte Frage, bevor wir schließen. Und zwar wird hier nochmal darauf verwiesen, dass Fahrzeuge, also Autos, auch an sich ja schon sehr viele Sensoren haben, zum Beispiel Temperatur
18:22
oder für die Schilderkennung. Könnte man solche mobilen Sensoren auch integrieren? Weiß nicht. Da bin ich jetzt nicht genau sicher. Es kommt natürlich auch immer darauf an, ob die Schnittstelle frei verfügbar ist, ob man Zugriff darauf hat. Aber an sich sind Fahrzeuge ja auch relativ smart heute.
18:42
Weshalb das bestimmt möglich ist, aber genau kann ich dazu jetzt auch nicht sagen. Super. Dann vielen Dank nochmal und vielleicht nochmal einen ganz herzlichen Applaus.