MQTT ist ein Internetprotokoll für die zeitnahe Bereiststellung von Echtzeit- und Sensordaten. MQTT ist Teil der Implementierung der SensorThings API. Mit der Erweiterung SensorThings MQTT können Beobachtungswerte erstellt und an den SensorThings-Dienst übermittelt werden.
MQTT-Broker: iot.hamburg.de
Das Abonnement auf ein Topic erfolgt unter:
- v1.0/Observations ODER
- v1.0/Datastreams({id})/Observations
Ein Beispiel zur Visualierung der Echtzeitdaten mit MQTT besteht im Masterportal des LGV: https://www.masterportal.org/
Raumbezug
Lage der Geodaten (in WGS84)
| SW Länge/Breite | NO Länge/Breite | |
|---|---|---|
| Hamburg (02000000) | 8.421°/53.395° | 10.326°/53.964° |
| Regionalschlüssel |
|---|
| Koordinatensystem |
|---|
Verweise und Downloads
Querverweise (7)
Geodatensatz
Elektro Ladestandorte Hamburg
Der Datensatz enthält die Standorte der öffentlich zugänglichen Ladeeinrichtungen für Elektrofahrzeuge in der Modellregion Elektromobilität Hamburg. Die zugehörigen Sachinformationen wie z.B. Anzahl der Ladepunkte, Steckertypen und Zugangsmöglichkeiten sind enthalten. Zusätzlich wird in Echtzeit der Betriebsstatus (UNKNOWN, AVAILABLE, OCCUPIED, RESERVED, UNAVAILABLE, FAULTED, PREPARING, CHARGING, SUSPENDEDEV, SUSPENDEDEVSE, FINISHING) der Ladepunkte angegeben.
Weitere Informationen zum Echtzeitdienst:
Der Echtzeitdatendienst enthält die Standorte der öffentlich zugänglichen Ladeeinrichtungen für Elektrofahrzeuge in der Modellregion Elektromobilität Hamburg im JSON-Format bereitgestellt über die SensorThings API (STA). Für die E-Ladestationen in der SensorThings API (STA) wurde je Station ein Objekt in der Entität "Thing" angelegt. Für jeden Ladepunkt steht ein Objekt in der Entität "Datastreams". Die Echtzeitdaten zum Status des Ladepunktes wird in der STA in der Entität "Observations" veröffentlicht.
Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.
In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt.
{
"properties":{
"serviceName": "HH_STA_E-Ladestationen",
"layerName": "Status_E-Ladepunkt",
"key":"value"}
}
Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://iot.hamburg.de/v1.1/Datastreams?$filter=properties/serviceName eq 'HH_STA_E-Ladestationen' and properties/layerName eq 'Status_E-Ladepunkt'
Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:
MQTT-Broker: iot.hamburg.de
Topic: v1.1/Datastream({id})/Observations
Kartenansicht öffnen
Geodatendienst
SensorThings API (STA)
Verweis zu Dienst
Die SensorThings API (STA) ist eine vom Open Geospatial Consortium (OGC) entwickelte Anwendungsprogrammierschnittstelle zum Management von Sensoren und Aktoren im Internet der Ding (IoT) . Während IoT-Netzwerkprotokolle wie MQTT und HTTP die Fähigkeit verschiedener IoT-Systeme zum Informationsaustausch ansprechen, adressiert SensorThings API die Fähigkeit verschiedener IoT-Systeme, die ausgetauschten Informationen zu verwenden und zu verstehen. Die SensorThings API bietet hierbei eine offene, raumbezogene und einheitliche Möglichkeit zur Verbindung von IoT-Geräten, Daten und Anwendungen über das Internet. Im Rahmen dieser Schnittstelle lassen sich zwei Hauptfunktionen zuordnen, welche sich in den sog. „Sensing-Part“ und „Tasking-Part“ unterteilen lassen. Der Erfassungsteil („Sensing-Part“) bietet eine Standardmethodik zum Verwalten bzw. Abrufen von Beobachtungen und Metadaten aus heterogenen IoT-Sensorsystemen. Mit der hier vorliegenden Schnittstelle ist der erste Part der STA ("Tasking") umgesetzt.
Aktuell gibt es im LGV eine Instanz der SensorThings API d.h. einen Sensordienst (s. Verweise), in dem alle Sensordaten enthalten sind. Verwendet wird dazu der FROST-Server von Fraunhofer, der eine komplette und open-source Implementierung der OGC SensorThings API Part1:Sensing ist. Es wird neben dem HTTP-Protokoll auch das MQTT-Protokoll unterstützt, womit eine Möglichkeit zum Veröffentlichen und Abonnieren von Sensordaten gegeben ist.
Mit der Schnittstelle können folgende Aktionen ausgeführt werden:
- Recherche nach allen auf dem FROST-Server bereitgestellten Sensordaten
- Veröffentlichen und Abonnieren von Beobachtungswerten mittels MQTT-Broker
- Editieren, Löschen und Neuerfassen von Sensordaten (Authentifizierung erforderlich)
Die im FROST-Server enthaltenen Sensordaten stehen in Verantwortung der Datenhalter (siehe Ansprechpartner bei den Datensätzen).
Zur genaueren Beschreibung der Daten und Datenverantwortung nutzen Sie bitte den Verweis zu den Datensatzbeschreibungen der jeweiligen Geobasisdaten.
Kartenansicht öffnen
Geodatensatz
StadtRAD-Stationen Hamburg
Der Datensatz enthält die Position aller StadtRAD-Stationen im Hamburger Stadtgebiet und die Anzahl der aktuell zur Ausleihe zur Verfügung stehenden Fahrräder und Lastenpedelecs.
Weitere Informationen zum Echtzeitdienst:
Der Echtzeitdatendienst enthält die Position aller StadtRAD-Stationen im Hamburger Stadtgebiet und die Anzahl der aktuell zur Ausleihe zur Verfügung stehenden Fahrräder und Lastenpedelecs im JSON-Format bereitgestellt in der SensorThings API (STA). In der SensorThings API (STA) steht die Entität "Thing" für jeweils eine StadtRad-Stationen. Für die Anzahl der verfügbaren Räder und die Lastenpedelecs gibt es jeweils eine Entität "Datastream" je "Thing". Die Anzahl der verfügbaren Räder (Echtzeitdaten) erhält man über die Entität "Observations".
Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.
In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt.
{
"properties":{
"serviceName": "HH_STA_StadtRad",
"layerName": "E-Lastenraeder",
"key":"value"}
}
Verfügbare Layer im layerName sind:
* E-Lastenraeder
* Fahrraeder
Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://iot.hamburg.de/v1.0/Datastreams?$filter=properties/serviceName eq 'HH_STA_StadtRad' and properties/layerName eq 'E-Lastenraeder'
Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:
MQTT-Broker: iot.hamburg.de
Topic: v1.0/Datastream({id})/Observations
Kartenansicht öffnen
Geodatensatz
TEC Energiedaten HH-Bergedorf
An den Anlagen des Competence Centers für Erneuerbare Energien und EnergieEffizienz (CC4E) zur Erzeugung von Wärme und Strom werden die Betriebszustände kontinuierlich erfasst. In diesem Datensatz sind die zeitlichen Verläufe der Leistungsdaten der Erzeuger wie die Photovoltaikanlage (PV) und das Blockheizkraftwerk (BHKW) (Wärme und Strom) sowie der (Strom-)Verbrauchern wie die Wärmepumpe und die E-Auto Ladesäule enthalten. Außerdem wird die Leistung des stromseitigen Hausanschlusses gemessen. So können Bezug und Einspeisung verschiedener Anlagen oder Messpunkte im zeitlichen Verlauf nachvollzogen werden. Die Daten geben beispielweise Aufschluss darüber, wann die PV Anlage des Gebäudes wie viel Strom produziert hat. In Verbindung mit den Daten des Hausanschlusses kann nachvollzogen werden, ob der Strom aus PV eingespeist oder im Gebäude verbraucht wurde. Die Messpunkte befinden sich in Anlagen und Räumen des CC4E der HAW-Hamburg und werden zur Forschung verwendet.
Weitere Informationen zum Echtzeitdienst:
Der Echtzeitdatendienst enthält den Standort des Competence Centers für Erneuerbare Energien und EnergieEffizienz (CC4E) sowie die Messergebnisse diverser Energieerzeugungs- und -verbrauchsmessungen im JSON-Format bereitgestellt in der SensorThings API (STA). In der STA steht die Entität "Thing" für diesen Standort. Je Energieverbrauchs oder -erzeugungsmessung gibt es einen Datastream. Die jeweilige Energieerzeugung bzw. -verbrauch (Echtzeitdaten) erhält man über die Entität "Observations".
Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.
In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt.
{
"properties":{
"serviceName": "HH_STA_TEC_Energiedaten_HH-Bergedorf",
"layerName": "Gesamtertrag_pv_elektrisch",
"key":"value"}
}
Verfügbare Layer im layerName sind:
* Erzeugung_pv_elektrisch
* Verbrauch_hausanschluss_elektrisch
* Erzeugung_BHKW_elektrisch
* Verbrauch_wp_thermisch
* Erzeugung_BHKW_thermisch
* Verbrauch_km_elektrisch
* Verbrauch_km_thermisch
* Verbrauch_el_elektrisch
* Verbrauch_ma_elektrisch
* Temperatur_speicher_heizstaebe
* Verbrauch_eautoladestation_elektrisch
* Gesamtertrag_pv_elektrisch
Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://iot.hamburg.de/v1.0/Datastreams?$filter=properties/serviceName eq 'HH_STA_TEC_Energiedaten_HH-Bergedorf",' and properties/layerName eq 'Gesamtertrag_pv_elektrisch'
Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:
MQTT-Broker: iot.hamburg.de
Topic: v1.0/Datastream({id})/Observations
Kartenansicht öffnen
Geodatensatz
Traffic Lights Data Hamburg
LSA-Prozessdaten
Der Datensatz umfasst momentan die LSA-Prozessdaten für rund die Hälfte aller am Verkehrsrechnernetz angeschlossenen Knoten in Hamburg und enthält aktuelle Signalausprägungen in Echtzeit. Zusätzlich werden Daten zu Detektoren wie Fahrrad-, Fußgänger- und Kfz- Anforderungen sowie Busmeldungen übertragen.
Folgende Punkte sollten bei der Nutzung der Daten berücksichtigt werden:
Durch Wartungsarbeiten kann es vereinzelt zu kurzen Ausfällen bei der Signalübertragung für mehrere Straßenzüge kommen.
In wenigen Fällen gib es außerdem fehlerhafte Zeitstempel aus den LSA-Steuergeräten (phenomenonTime), die für unplausible Werte bei der Latenz verantwortlich sind.
Für ein besseres Verständnis der Daten, ist im Bereich Verweise und Downloads ein Benutzerhandbuch verlinkt.
Weitere Informationen zum Echtzeitdienst:
Der OGC SensorThings API konforme Echtzeitdatendienst enthält Datenströme und Positionen von Fahrspurbeziehungen an Kreuzungen mit Lichtsignalanlagen für Fahrradfahrer, Fußgänger sowie Kraftfahrzeuge im Hamburger Stadtgebiet. Wenn an der Lichtsignalanlage bereitgestellt, werden folgende Datenströme als JSON-Objekte ausgeliefert: Primärsignale, Sekundärsignale, Hilfssignale, Akustiksignale, KFZ-Signalanforderungen, Fahrradfahrersignalanforderungen, Fußgängersignalanforderungen, Akustiksignalanforderung, ÖPNV-Voranmeldung, ÖPNV-Anmeldung, ÖPNV-Abmeldung, Signalprogramm und Wellensekunde.
In der OGC SensorThings API sind die Informationen zu den Fahrspurbeziehungen in der Entität Thing hinterlegt. Für die oben aufgelisteten Datenströme, die an einem konkreten Thing verfügbar sind, wird ein Eintrag in der Entität Datastreams erstellt, der das entsprechende Thing referenziert.
Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.
In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt.
Hier ein Beispiel:
{
"properties": {
"serviceName": "HH_STA_traffic_lights",
"layerName": "primay_signal",
"key":"value"
}
}
Alle möglichen values für “layerName”:
* primay_signal (Primärsignal),
* secondäary_signal (Sekundärsignal),
* auxiliary_signal (Hilfssignal),
* acoustic_signal (Akustiksignal),
* detector_car (KFZ-Signalanforderung),
* detector_cyclist (Fahrradfahrersignalanforderung),
* detector_pedestrian (Fußgängersignalanforderung),
* detector_acoustic_traffic_request (Akustiksignalanforderung),
* bus_pre-request_point (ÖPNV-Voranmeldung),
* bus_request_point (ÖPNV-Anmeldung),
* bus_checkout (ÖPNV-Abmeldung),
* signal_program (Nummer des Signalprogramms),
* cycle_second (Wellensekunde)
Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://tld.iot.hamburg.de/v1.1/Datastreams?$filter=properties/serviceName eq 'HH_STA_traffic_lights' and properties/layerName eq 'primary_signal'
Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:
MQTT-Broker: tld.iot.hamburg.de
Topic: v1.1/Datastreams({id})/Observations
Ferner können über folgenden Link die MAP-Dateien (.xml- und .kml) aller bereits veröffentlichter Knoten abgerufen werden:
https://daten-hamburg.de/tlf_public/
Kartenansicht öffnen
Geodatensatz
Verkehrsdaten Kfz (Infrarotdetektoren) Hamburg
Allgemeine Informationen:
Der Datensatz umfasst Verkehrsdaten aller Standorte in Hamburg, an denen der Kraftfahrzeugverkehr (Kfz-Verkehr) mittels Infrarotdetektoren an 24h am Tag und allen Tagen des Jahres erfasst wird.
Die Daten enthalten Verkehrsstärken in Echtzeit und werden an für den Straßenquerschnitt zusammengefassten Zählstellen in 15-Minuten, 60-Minuten, Tages- und Wochen-Intervallen zur Verfügung gestellt.
Die Daten der Zählstellen werden außerdem in den entsprechenden Geoportalen der FHH, z.B. in Geo-Online und dem Verkehrsportal, visualisiert.
Neben den Echtzeitdaten sind auch historische Daten in folgendem Umfang verfügbar:
alle Daten für die letzten zwei Wochen in 15-Minuten-Intervallen, alle Daten für die letzten zwei Monate für die 60-Minutenintervalle, alle Daten für das aktuelle und das letzte Jahr in Tagesintervallen sowie alle Daten seit Beginn der Erfassung in Wochenintervallen.
Informationen zur Technik:
Die Infrarotdetektoren sind in der Regel an Lichtsignalanlagen, zu einem geringen Teil aber auch an anderen Masten, installiert. Die Detektoren erfassen und zählen den Verkehr über die Wärmeabstrahlung der einzelnen Verkehrsteilnehmenden. Da ausschließlich Infrarotbilder ausgewertet werden, ist der Datenschutz zu jeder Zeit gewährleistet.
Hinweise zur Datenqualität:
Die Daten werden in Echtzeit an die Urban Data Platform der FHH übertragen. So sind diese zeitnah für alle Nutzenden und Interessierten verfügbar. Durch die Echtzeitkomponente sind allerdings verschiedene Rahmenbedingungen zu beachten: Die Daten sind nicht umfassend qualitätsgesichert. Ungewöhnliche Abweichungen von den zu erwartenden Daten und Datenlücken werden zwar automatisch vom System erkannt, können aber nicht in Echtzeit korrigiert werden. Lücken, die z.B. durch einen Abriss der Datenübertragung auftreten, können im Nachhinein noch nachgeliefert werden. Unter Umständen und bei längeren Ausfällen können folglich noch nach ein paar Tagen Änderungen in den historischen Daten erfolgen.
Die Daten erhalten deswegen täglich eine Aktualisierung für die folgenden Zeiträume:
Vortag: 15-Min-Intervalle
Tag vor sechs Tagen: 15-Min-Intervalle und Tages-Intervalle
Tag vor 28 Tagen: Tages-Intervalle
Die Wochenwerte erhalten wöchentlich eine Aktualisierung für die Werte der Vorwoche und der Woche vor vier Wochen.
Es handelt sich bei den hier veröffentlichten Daten nicht um amtlich geprüfte Daten der FHH. Werden derartige Daten benötigt, kann z.B. der Datensatz "Verkehrsstärken Hamburg" herangezogen werden, der die „Durchschnittlichen (werk)täglichen Verkehre“ in der Entwicklung der letzten Jahre enthält.
Wie bei jeder Verkehrszählung, egal ob automatisiert oder manuell, gibt es gewisse Toleranzen in der Messgenauigkeit. Anspruch an das hier verwendete System sind Genauigkeiten von +/- 5% bei der Erfassung der Kfz-Verkehrsstärken.
Weitere Informationen zum Echtzeitdienst:
Der Echtzeitdatendienst enthält die Standorte der Zählstellen für das Kfz-Aufkommen, das mit Infrarotdetektoren erfasst wird. Die Daten werden im JSON-Format über die SensorThings API (STA) bereitgestellt . Für jede Zählstelle in der SensorThings API (STA) wurde ein Objekt in der Entität "Thing" angelegt. Für jede zeitliche Auflösungsebene bei den Zählstellen bzw. jeder verkehrlichen Bezugsgröße steht ein Objekt in der Entität "Datastreams". Die Echtzeitdaten zur Anzahl Kfz je Zählstelle und Zeitintervall wird in der STA in der Entität "Observations" veröffentlicht.
Es werden folgende räumlichen und zeitlichen Ebenen differenziert:
-Zählstelle 15-Min, 1-Stunde, 1-Tag, 1-Woche: Anzahl Kfz
Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.
In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt. Hier ein Beispiel:
{
"properties":{
"serviceName": "HH_STA_AutomatisierteVerkehrsmengenerfassung",
"layerName": "Anzahl_Kfz_Zaehlstelle_15-Min",
"key":"value"}
}
Verfügbare Layer im layerName sind:
* Anzahl_Kfz_Zaehlstelle_15-Min
* Anzahl_Kfz_Zaehlstelle_1-Stunde
* Anzahl_Kfz_Zaehlstelle_1-Tag
* Anzahl_Kfz_Zaehlstelle_1-Woche
Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://iot.hamburg.de/v1.1/Datastreams?$filter=properties/serviceName eq 'HH_STA_AutomatisierteVerkehrsmengenerfassung' and properties/layerName eq 'Anzahl_Kfz_Zaehlstelle_15-Min'
Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:
MQTT-Broker: iot.hamburg.de
Topic: v1.1/Datastream({id})/Observations
Kartenansicht öffnen
Geodatensatz
Verkehrsdaten Rad (Infrarotdetektoren) Hamburg
Allgemeine Informationen:
Der Datensatz umfasst Verkehrsdaten aller Standorte in Hamburg, an denen der Radverkehr mittels Infrarotdetektoren an 24h am Tag und allen Tagen des Jahres erfasst wird.
Der Datensatz enthält sowohl die Verkehrsstärken einzelner Zählfelder als auch aus mehreren Zählfeldern aggregierte Zählstellen in Echtzeit.
Der schematische Aufbau der Datenerfassung und Datenaggregation ist in einem separaten Dokument beschrieben, welches in den Verweisen zu finden ist.
Die Daten der Zählfelder werden in 5-Minuten-Intervallen bereitgestellt.
Die Daten der Zählstellen liegen aggregiert in 15- und 60-Minuten-Intervallen sowie in Tages- und Wochenwerten vor. Die Daten der Zählstellen werden außerdem in den entsprechenden Geoportalen der FHH, z.B. in Geo-Online und dem Verkehrsportal, visualisiert.
Neben den Echtzeitdaten sind auch historische Daten in folgendem Umfang verfügbar:
Zählfelder: alle Daten seit Beginn der Erfassung in 5-Minuten-Intervallen.
Zählstellen: alle Daten für die letzten zwei Wochen in 15-Minuten-Intervallen, alle Daten für die letzten zwei Monate in Stundenintervallen, alle Daten für das aktuelle und das letzte Jahr in Tagesintervallen sowie alle Daten seit Beginn der Erfassung in Wochenintervallen.
Informationen zur Technik:
Die Infrarotdetektoren sind in der Regel an Beleuchtungsmasten, zum Teil aber auch an anderen Masten, installiert. Die Detektoren erfassen und zählen den Verkehr über die Wärmeabstrahlung der einzelnen Verkehrsteilnehmenden. Da ausschließlich Infrarotbilder ausgewertet werden, ist der Datenschutz zu jeder Zeit gewährleistet.
Hinweise zur Datenqualität:
Die Daten werden in Echtzeit an die Urban Data Platform der FHH übertragen. So sind diese zeitnah für alle Nutzenden und Interessierten verfügbar. Durch die Echtzeitkomponente sind allerdings verschiedene Rahmenbedingungen zu beachten: Die Daten sind nicht umfassend qualitätsgesichert. Ungewöhnliche Abweichungen von den zu erwartenden Daten und Datenlücken werden zwar automatisch vom System erkannt, können aber nicht in Echtzeit korrigiert werden. Lücken, die z.B. durch einen Abriss der Datenübertragung auftreten, können im Nachhinein noch nachgeliefert werden. Unter Umständen und bei längeren Ausfällen können folglich noch nach ein paar Tagen Änderungen in den historischen Daten erfolgen.
Die Daten erhalten deswegen täglich eine Aktualisierung für die folgenden Zeiträume:
Vortag: 5-Min-Intervalle, 15-Min-Intervalle und 60-Min-Intervalle
Tag vor sechs Tagen: 5-Min-Intervalle, 15-Min-Intervalle, 60-Min-Intervalle und Tages-Intervalle
Tag vor 28 Tagen: 5-Min-Intervalle, 60-Min-Intervalle, Tages-Intervalle
Die Wochenwerte erhalten wöchentlich eine Aktualisierung für die Werte der Vorwoche und der Woche vor vier Wochen.
Es handelt sich bei den hier veröffentlichten Daten nicht um amtlich geprüfte Daten der FHH.
Wie bei jeder Verkehrszählung, egal ob automatisiert oder manuell, gibt es gewisse Toleranzen in der Messgenauigkeit. Anspruch an das hier verwendete System sind Genauigkeiten für die Zählfelder von +/- 10% bei der Erfassung des Radverkehrs auf Gehwegen, Radwegen und Radverkehrsstreifen sowie +/-20% bei der Erfassung des Radverkehrs im Mischverkehr mit Kraftfahrzeugen. Da Zählstellen aus einer Kombination verschiedener Zählfelder gebildet werden, kann die Abweichung bis zu +/-20% betragen.
Weitere Informationen zum Echtzeitdienst:
Der Echtzeitdatendienst enthält die aktiven Standorte der Zählfelder und Zählstellen über die mittels Infrarotdetektoren das aktuelle Fahrradaufkommen am Standort ermittelt wird. Die Daten werden im JSON-Format über die SensorThings API (STA) bereitgestellt . Für jedes Zählfeld und jede Zählstelle in der SensorThings API (STA) steht ein Objekt in der Entität "Thing". Für jede zeitliche (jeweiliges Zeitintervall) und räumliche Auflösungsebene (Zählfelder/Zählstellen) steht ein Objekt in der Entität "Datastreams". Die Echtzeitdaten zur Anzahl Fahrräder je Zeitintervall und Raumeinheit wird in der STA in der Entität "Observations" veröffentlicht.
Die zeitlichen und räumlichen Auflösungsebenen sind der Datensatzbeschreibung zu entnehmen.
Alle Zeitangaben sind in der koordinierten Weltzeit (UTC) angegeben.
In der Entität Datastreams gibt es im JSON-Objekt unter dem "key" "properties" weitere "key-value-Paare". In Anlehnung an die Service- und Layerstruktur im GIS haben wir Service und Layer als zusätzliche "key-value-Paare" unter dem JSON-Objekt properties eingeführt. Hier ein Beispiel:
{
"properties":{
"serviceName": "HH_STA_HamburgerRadzaehlnetz",
"layerName": "Anzahl_Fahrraeder_Zaehlfeld_5-Min",
"key":"value"}
}
Verfügbare Layer im layerName sind:
* Anzahl_Fahrraeder_Zaehlfeld_5-Min
* Anzahl_Fahrraeder_Zaehlstelle_15-Min
* Anzahl_Fahrraeder_Zaehlstelle_1-Stunde
* Anzahl_Fahrraeder_Zaehlstelle_1-Tag
* Anzahl_Fahrraeder_Zaehlstelle_1-Woche
Mit Hilfe dieser "key-value-Paare" können dann Filter für die REST-Anfrage definiert werden, bspw.
https://iot.hamburg.de/v1.0/Datastreams?$filter=properties/serviceName eq 'HH_STA_HamburgerRadzaehlnetz' and properties/layerName eq 'Anzahl_Fahrraeder_Zaehlfeld_5-Min'
Die Echtzeitdaten kann man auch über einen MQTT-Broker erhalten. Die dafür notwendigen IDs können über eine REST-Anfrage bezogen werden und dann für das Abonnement auf einen Datastream verwendet werden:
MQTT-Broker: iot.hamburg.de
Topic: v1.0/Datastream({id})/Observations
Kartenansicht öffnen
Weitere Verweise (2)
Beschreibung der Erweiterung der SensorThings API mit der MQTT-Extension
Übergeordnete Objekte (1)
Geodatendienst
SensorThings API (STA)
Die SensorThings API (STA) ist eine vom Open Geospatial Consortium (OGC) entwickelte Anwendungsprogrammierschnittstelle zum Management von Sensoren und Aktoren im Internet der Ding (IoT) . Während IoT-Netzwerkprotokolle wie MQTT und HTTP die Fähigkeit verschiedener IoT-Systeme zum Informationsaustausch ansprechen, adressiert SensorThings API die Fähigkeit verschiedener IoT-Systeme, die ausgetauschten Informationen zu verwenden und zu verstehen. Die SensorThings API bietet hierbei eine offene, raumbezogene und einheitliche Möglichkeit zur Verbindung von IoT-Geräten, Daten und Anwendungen über das Internet. Im Rahmen dieser Schnittstelle lassen sich zwei Hauptfunktionen zuordnen, welche sich in den sog. „Sensing-Part“ und „Tasking-Part“ unterteilen lassen. Der Erfassungsteil („Sensing-Part“) bietet eine Standardmethodik zum Verwalten bzw. Abrufen von Beobachtungen und Metadaten aus heterogenen IoT-Sensorsystemen. Mit der hier vorliegenden Schnittstelle ist der erste Part der STA ("Tasking") umgesetzt.
Aktuell gibt es im LGV eine Instanz der SensorThings API d.h. einen Sensordienst (s. Verweise), in dem alle Sensordaten enthalten sind. Verwendet wird dazu der FROST-Server von Fraunhofer, der eine komplette und open-source Implementierung der OGC SensorThings API Part1:Sensing ist. Es wird neben dem HTTP-Protokoll auch das MQTT-Protokoll unterstützt, womit eine Möglichkeit zum Veröffentlichen und Abonnieren von Sensordaten gegeben ist.
Mit der Schnittstelle können folgende Aktionen ausgeführt werden:
- Recherche nach allen auf dem FROST-Server bereitgestellten Sensordaten
- Veröffentlichen und Abonnieren von Beobachtungswerten mittels MQTT-Broker
- Editieren, Löschen und Neuerfassen von Sensordaten (Authentifizierung erforderlich)
Die im FROST-Server enthaltenen Sensordaten stehen in Verantwortung der Datenhalter (siehe Ansprechpartner bei den Datensätzen).
Zur genaueren Beschreibung der Daten und Datenverantwortung nutzen Sie bitte den Verweis zu den Datensatzbeschreibungen der jeweiligen Geobasisdaten.
| Identifikator des übergeordneten Metadatensatzes |
19A339AE-FD6E-4551-9AD7-F9624C8A55FF |
|---|
Kontakt
Herausgeber
|
Landesbetrieb Geoinformation und Vermessung (LGV) Hamburg
Neuenfelder Straße 19
|
Fachinformationen
Informationen zum Datensatz
| Klassifikation des Dienstes |
Abonnementdienst |
|---|
| Art des Dienstes |
Sonstige Dienste |
|---|
Operation
| Name der Operation | Beschreibung der Operation | Aufruf der Operation |
|---|---|---|
| MQTT-Broker | Brokeradresse für MQTT | iot.hamburg.de |
| GetCapabilities Dokument | Kartenansicht öffnen |
|---|