Nutzerinnen und Nutzer von stadt-koeln.de und der Kölner Service-App kennen diesen Dienst schon länger. Unter dem Verkehrskalender stellen wir Ihnen verschiedene Möglichkeiten zur Verfügung, einen Überblick über die Verkehrslage, die Baustellen und in der nächsten Version auch die Parkhausbelegung in Köln zu erhalten.
Diesen Datenbestand stellen wir nunmehr unter den geltenden aktuellen Nutzungsbedingungen auf unseren Downloadseiten als JSON zur Verfügung.
Eine Detailbeschreibung des Datensatzes finden Sie dort.
Wie immer gilt: Mitmachen und Feedback sind ausdrücklich erünscht 
Update (20.02.2013)
In der aktuellen Version haben wir die Anregungen soweit möglich berücksichtigt und bieten darüber hinaus, nunmehr auch unter dem folgenden Link die Möglichkeit die aktuelle Parkhausbelegung abzufragen. Die Ergebnisse des nunmehr komprimierten json können unter der Adresse http://www.stadt-koeln.de/externe-dienste/open-data/parkingsh.php?out=show angezeigt werden.
Anläßlich der Anregungen hier noch einige weitere Änderungen:
Die Schnittstellen können jetzt zusätzlich mit den Parametern id, sr und gr aufgerufen werden. Bei dem Parameter id kann einer der IDENTIFIER mitgegeben werden, die auch in der Gesamtausgabe erscheinen. Damit erhält man dann nur die Daten eines Objektes (Parkhaus oder Strecke)
Beispiele (jeweils mit out=show, damit man sofort sieht, was passiert):
http://www.stadt-koeln.de/externe-dienste/open-data/parkingsh.php?out=show&id=D_P001
Liefert nur die Daten des Parkhauses LANXESS arena 1
http://www.stadt-koeln.de/externe-dienste/open-data/trafficsh.php?out=show&id=ST022
Liefert nur die Daten der Strecke Industriestraße – A1 – AS Köln-Niehl bis Niehler Hafen
Über den Parameter sr (spatial reference) können nun die Koordinaten auf WGS_1984_UTM_Zone_32N umgestellt werden. Beispiele (jeweils mit out=show, damit man sofort sieht, was passiert):
http://www.stadt-koeln.de/externe-dienste/open-data/parkingsh.php?out=show&sr=wgs84
http://www.stadt-koeln.de/externe-dienste/open-data/trafficsh.php?out=show&sr=wgs84
Andere Angaben als wgs84 werden ignoriert.
Mit dem Parameter gr(geometry return)=false kann die Ausgabe der Geodaten unterdrückt werden, was insbesondere bei den Strecken natürlich eine erhebliche Reduzierung der Datenmenge bedeutet.
Beispiel (jeweils mit out=show, damit man sofort sieht, was passiert):
http://www.stadt-koeln.de/externe-dienste/open-data/trafficsh.php?out=show&gr=false
Natürlich können die Parameter id und sr und gr kombiniert werden (wobei die Angabe von sr=wgs84 und gr=false wenig Sinn macht .
Für weitere Anregungen sind wir dankbar und versuchen diese umzusetzen.
Erst mal vielen Dank für die Veröffentlichung dieser interessanten API. Ich wusste nicht, wie detailliert die Verkehrsauslastung tatsächlich erfasst wird. Es wäre interessant, mehr über das System dahinter zu erfahren, beispielsweise die Sensoren.
Ich habe natürlich zahlreiche Anmerkungen.
- Der Download-Button ist etwas irreführend. Es handelt sich ja schließlich um einen API-Zugriff und die Daten veralten recht schnell.
- Könnten wir die Daten auch als JSONP bekommen? Dann könnte man sie direkt von der Webservice-URL in eine Webanwendung einbetten. So muss man die Daten erst durch einen Proxy herunter laden, was die Angelegenheit recht aufwändig macht.
- Die Datei könnte durch Verzicht auf Zeilenumbrüche deutlich verkleinert werden. Noch kleiner wird sie, wenn man die Koordinaten mit nur 7 Nachkommastellen angibt. Das ist immer noch genau genug. Ich komme damit auf 156 KB (im Vergleich zu 580 KB).
- Der Wert AUSLASTUNG=32 (Texthinweis) ist leider etwas ungünstig, weil so bei Vorhandensein eines Texthinweis die tatsächliche Verkehrsbelastung nicht mehr wiedergegeben wird. Könnte man das von einander trennen?
- Es fällt auf, dass einige Straßen überhaupt keine Daten liefern. Der Militärring beispielsweise.
Und noch eine Frage:
- Wie häufig werden die Daten aktualisiert?
wir bemühen uns die Fragen so schnell als möglich zu klären und stellen dann die Antwort hier ein! Danke für den Hinweis
Gruß
Ihre Red.
Oh nein, die Umbrüche in meinem Kommentar sind leider verloren gegangen. Das ist sehr schade, weil der damit sehr unleserlich wird.
Einen noch: Bisher finde ich nur die Auslastung von Straßen in den Daten, aber nichts zu Parkplätzen. Die Beschreibung müsste also noch angepasst werden.
Hallo, ich finde keine öffentliche Vorschlags-Sektion auf der Seite, daher packe ich diese Anfrage/Anregung einfach – off topic – hier rein:
———-
Ich wünsche mir einen Datensatz zu der Platzierung von Glaskontainern.
Bei jedem Umzug innerhalb von Köln sammelten sich bei mir erstmal das Altglas, bis ich – irgendwo versteckt – einen Glaskontainer in meiner Nähe gefunden hatte.
—–
Ich fände es klasse, wenn offenedaten-koeln die GeoLocation aller Glaskontainer veröffentlichen würde. Das Gleiche gilt – in einer Ausbaustufe – dann auch für Altkleiderkontainer und ähnliche Sammelbehälter.
—–
Nebenbei: DHL hat das Problem für seine Packstationen schön gelöst, mach muss nur in Google Maps danach suchen, da sie dort wohl als “Geschäfte” angelegt sind. http://goo.gl/maps/720aa
—–
Viele Grüße
Schon mal nach den glascontainern bei openstreetmap geschaut? Bei mir in der Umgebung sind sie vollständig erfasst. Mit der overpass API lassen sie sich auch Abfragen.
Grüße jotpe
Ich schließe mich den Vorschlägen von Marian Steinbach an. Die Auslieferung als JSONP ist beste Voraussetzung für eine leichte Einbindung der Daten in eigene Applikationen, und mit der Code-Minimierung durch Weglassen von Leerzeichen, Umbrüchen und Dezimalstellen kann man tatsächlich an die 200 KB erreichen.
Weitere Wünsche/Vorschläge:
- Wählbares Bezugssystem (oder wenigstens das verbreitete WGS84 noch hinzufügen, würde die Kombination mit anderen Datenquellen erleichtern)
- Angabe des Alters/Stands der Daten im Feed
- Angabe des Aktualisierungszeitraums in der Dokumentation (als Anhaltspunkt für lokales Caching wichtig)
- Update-Datensätze statt Komplettrequest: wenn jeder Streckenabschnitt über eine ID oder dgl identifizierbar ist, kann man die niemals sich ändernden Streckenkoordinaten weglassen (oder aus einer statischen Quell-URL vorladen) und nur noch paarweise ID –> Status aus dem Livesystem nachladen ; das wären dann nur noch wenige KB.
Man sollte noch einen Schalter haben um die Geodachten wegzulassen.
Soweit ich sehe verändern sich die Strassen ja seltener
, so dass man selbst diese Werte cachen könnte.
Evtl ja die Geodaten komplett auslagern? Ich weiss nicht was praktischer dann ist.