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 (Usage Guide) 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) sowie die OCIT-C-Dateien (Versorgungsdatei im Format xml) aller bereits veröffentlichter Knoten abgerufen werden: https://daten-hamburg.de/tlf_public/
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.
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
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/