Transparenzportal

Aussenansicht des Staatsarchivs Hamburg

Transparenzportal Hamburg

7 Suchergebnisse für "*"

Datensatz 28.02.2024

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

Formate: gml, xsd, wfs, wms, json, sta, mqtt, oaf, html

  • Transport und VerkehrTransport & Verkehr
  •  
Mehr
Datensatz 19.02.2024

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/

Formate: json, sta, mqtt, pdf, html

  • Transport und VerkehrTransport & Verkehr
  •  
Mehr
Datensatz 24.01.2024

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

Formate: gml, wfs, wms, html, json, mqtt, sta, oaf

  • Transport und VerkehrTransport & Verkehr
  •  
Mehr
Datensatz 15.11.2023

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

Formate: mqtt, sta, json, html

  • Bildung und WissenschaftBildung & Wissenschaft
  •  
Mehr

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

Formate: html, sta, mqtt, json

  • Transport und VerkehrTransport & Verkehr
  •  
Mehr

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

Formate: pdf, html, mqtt, sta, json, oaf

  • Transport und VerkehrTransport & Verkehr
  •  
Mehr

------Datensatz veraltet------- ----Derzeit werden die Daten für den Knoten 2150 nicht aktualisiert---- Der Datensatz umfasst LSA-Prozessdaten für vier Knoten in Hamburg und enthält in Echtzeit aktuelle Signalausprägungen. Zusätzlich werden Daten zu Detektoren wie Fahrrad, Fußgänger, Kfz- Anforderungen sowie Busmeldungen übertragen. Hinweise zur Latenz: 4 Minuten Auflistung der Knoten: - 413: An Der Verbindungsbahn / Bundesstraße - 279: Edmund-Siemers-Allee / Grindelallee - 271: Theodor-Heuß-Platz / Edmund-Siemers-Allee - 2150: Edmund-Siemers-Allee / CCH 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, Signalstaus 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"} } Mögliche values für “layerName”: * primay_signal (Primärsignal), * secondary_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 (Signalprogrammstatus), * cycle_second (Wellensekunde) 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_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: iot.hamburg.de Topic: v1.0/Datastreams({id})/Observations

Formate: json, sta, mqtt, html

  • Transport und VerkehrTransport & Verkehr
  •  
Mehr