Tramwayforum
Allgemeines => Literatur, Kunst, Medien... => Thema gestartet von: tramway.at am 11. Dezember 2012, 14:24:55
-
Grandioses wurde ausgeheckt: Das wiener U-Bahn-Netz für Google Earth! Natürlich völlig unverwendbar, aber Hauptsache modern! Das obere Bild zeigt die errechnete Fahrtroute von U3 Stephansplatz zur U3 Johnstraße...
http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetMap&crs=EPSG%3A4326& (http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetMap&crs=EPSG%3A4326&)
-
Mah, was du schon wieder meckerst! De Leit soin froh sein, doss des nix kost!
-
Euch kann man aber auch gar nichts recht machen!
-
Grandioses wurde ausgeheckt: Das wiener U-Bahn-Netz für Google Earth! Natürlich völlig unverwendbar, aber Hauptsache modern! Das obere Bild zeigt die errechnete Fahrtroute von U3 Stephansplatz zur U3 Johnstraße...
Bist du sicher, dass du als Routingoption nicht Auto angekreuzt hast?
-
Bist du sicher, dass du als Routingoption nicht Auto angekreuzt hast?
Motorrad! ;) ;D
-
Grandioses wurde ausgeheckt: Das wiener U-Bahn-Netz für Google Earth! Natürlich völlig unverwendbar, aber Hauptsache modern! Das obere Bild zeigt die errechnete Fahrtroute von U3 Stephansplatz zur U3 Johnstraße...
Bist du sicher, dass du als Routingoption nicht Auto angekreuzt hast?
Ich hab garnix angekreuzt, sondern als dummdöseliger Ottonormaluser zwei U-Bahn-Haltestellen als Start und Ziel ausgewählt...
-
Grandioses wurde ausgeheckt: Das wiener U-Bahn-Netz für Google Earth! Natürlich völlig unverwendbar, aber Hauptsache modern! Das obere Bild zeigt die errechnete Fahrtroute von U3 Stephansplatz zur U3 Johnstraße...
Aber mit der U-Bahn fahre ich ja unter der Erde und sehe nicht, wie ich wohin fahre. Zeit für Google Below Surface! (http://de.wikipedia.org/w/index.php?title=Datei:Jordens_inre.svg&filetimestamp=20070210164631)
-
Grandioses wurde ausgeheckt: Das wiener U-Bahn-Netz für Google Earth! Natürlich völlig unverwendbar, aber Hauptsache modern! Das obere Bild zeigt die errechnete Fahrtroute von U3 Stephansplatz zur U3 Johnstraße...
Bist du sicher, dass du als Routingoption nicht Auto angekreuzt hast?
Ich hab garnix angekreuzt, sondern als dummdöseliger Ottonormaluser zwei U-Bahn-Haltestellen als Start und Ziel ausgewählt...
Das wirds sein...
Wer hat den U-Bahn-Layer erstellt? Die Stadt Wien? So wie ich deinen Link deute, wird der Layer, der nicht von Google stammt, einfach über Google Earth drübergelegt, aber nicht damit verbunden. ;)
Übrigens, einen U-Bahn-Layer auf Google Maps als "Open Data" zu bezeichnen, ist sehr verwegen. Google hat mit "Open Data" praktisch nichts zu tun, du kannst ja deren Daten auch nicht einfach so weiterverwenden. Du hast in der Regel Einschränkungen und Lizenzgebühren zu erwarten. Wenn die Stadt Wien Daten an Google gibt, ist das hauptsächlich für Google schön, entspricht aber nicht "Open Data", das ja bedeutet, dass man mit den Daten einfach weiterarbeiten kann. Open Data wäre beispielsweise Openstreetmap (http://www.openstreetmap.org), da kann man mit der gesamten Datenbank herumspielen, wie man will.
-
Übrigens, einen U-Bahn-Layer auf Google Maps als "Open Data" zu bezeichnen, ist sehr verwegen. Google hat mit "Open Data" praktisch nichts zu tun, du kannst ja deren Daten auch nicht einfach so weiterverwenden. […] Wenn die Stadt Wien Daten an Google gibt, ist das hauptsächlich für Google schön, entspricht aber nicht "Open Data", das ja bedeutet, dass man mit den Daten einfach weiterarbeiten kann. Open Data wäre beispielsweise Openstreetmap, da kann man mit der gesamten Datenbank herumspielen, wie man will.
Hauptsache einmal meckern: Das KML ist nur ein Teil des Open-Data-Angebots und natürlich ist es noch unbrauchbar, da es nur die Datengrundlage ist, die es im Übrigen auch in anderen Formaten gibt.
http://data.wien.gv.at/katalog/u-bahnnetz-bestand.html (http://data.wien.gv.at/katalog/u-bahnnetz-bestand.html)
::)
-
Das KML ist nur ein Teil des Open-Data-Angebots und natürlich ist es noch unbrauchbar, da es nur die Datengrundlage ist, die es im Übrigen auch in anderen Formaten gibt.
Vor allem der farbig markierte Teil erschließt sich mir nicht ganz: Man veröffentlicht unbrauchbare Sachen, weil es eh auch andere, brauchbarere Formate gibt? ???
-
Sorry, ungenau ausgedrückt: Unbrauchbar für den Enduser/Ottonormalverbraucher.
-
Unbrauchbar für den Enduser/Ottonormalverbraucher.
Aufbereitete (!) Daten sind auch nicht unbedingt der eigentliche Sinn hinter OpenData... ::)
-
Ah geh.
-
http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetMap&crs=EPSG%3A4326& (http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetMap&crs=EPSG%3A4326&)
Der Link funktioniert nicht!
-
http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetMap&crs=EPSG%3A4326& (http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetMap&crs=EPSG%3A4326&)
Der Link funktioniert nicht!
Da fehlen auch ein paar Parameter. Standardkonform sollte man die mittels http://http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetCapabilities (http://http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetCapabilities) abfragen können - *das* funktioniert tatsächlich nicht :-)
-
Sorry, aber 2 x http:// ist - sagen wir es so - bei der Verwendung in URLs sehr ungebräuchlich.
Hannes
-
Sorry, aber 2 x http:// ist - sagen wir es so - bei der Verwendung in URLs sehr ungebräuchlich.
Das ist ja auch nur ein Tippfehler. Mit dem korrekten URL http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetCapabilities (http://data.wien.gv.at/daten/geoserver/ows?version=1.3.0&service=WMS&request=GetCapabilities) bekommt man eine schöne Fehlermeldung vom Geoserver. Die Wiener haben das offensichtlich nie getestet*, sonst hätte ihnen das auffallen müssen.
*) "Za wos soi ma des testen, mir wissn do eh, doss funktioniert."
-
:up:
-
Wiener Linien machen Riesenschritt in Richtung "Open Data"
2. Jänner 2013, 12:02
Erstmals werden Infos Entwicklern zur Verfügung gestellt - Vorerst nur für zwei Tage
Seit Jahren sträuben sich die Wiener Linien ihre Fahrplandaten öffentlich, etwa für Google Maps oder App-Entwickler, zur Verfügung zu stellen. Neben rechtlichen und technischen Komplikationen führte das Unternehmen auch Sicherheitsdenken ins Feld. Eine Argumentationslinie, die seit Jahren für Unverständnis und Kritik sorgt, da andere Städte derartige Probleme nicht kennen.
Infos über Abfahrtszeiten oder über betriebliche Störungen für Entwickler
Doch nun machen die Wiener Linien einen großen Schritt hin zur öffentlichen Bereitstellung ihrer Daten. Im Rahmen des ersten "Create Camp der Wiener Linien", einer Tagung die am 12. und 13. Jänner über die Bühne geht, öffnet sich das Unternehmen und stellt für die Dauer des Camps Infos über Abfahrtszeiten oder über betriebliche Störungen Entwicklern und Opendata-Aktivisten zur Verfügung.
Das Camp soll den Dialog mit der Opendata-Community vertiefen, so Claudia Riegler von den Wiener Lienen zum WebStandard. Und es kann als "erster Schritt" zur Veröffentlichung der Fahrplandaten gesehen werden, so die Social-Media Zuständige. (sum, 02.01. 2012)
Quelle: http://derstandard.at/1356426554587/Wiener-Linien-machen-Riesenschritt-in-Richtung-Open-Data (http://derstandard.at/1356426554587/Wiener-Linien-machen-Riesenschritt-in-Richtung-Open-Data)
2 Tage - Ich hab meine Häkelnadel vergessen.... :fp:
Und die Postings sind auch recht nett...
-
Jetzt hackt's ihnen die Bude zsam 8)
-
Jetzt hackt's ihnen die Bude zsam 8)
Da besteht dann die Gefahr, dass RBL und Konsorten endlich mal funktionieren :-*
-
Jetzt hackt's ihnen die Bude zsam 8)
Da besteht dann die Gefahr, dass RBL und Konsorten endlich mal funktionieren :-*
Das wär auch mal was: Zwei Tage Administratorzugang auf dem RBL-Server. Dafür würde ich mich definitiv melden 8)
-
Wetten, dass die einen Parallelserver aufstellen, dessen "Echtzeitdaten" schon im Voraus penibel festgelegt wurden? 8)
-
Wetten, dass die einen Parallelserver aufstellen, dessen "Echtzeitdaten" schon im Voraus penibel festgelegt wurden? 8)
Was jetzt wahrscheinlich nicht einmal so deppert ist, um mit dem API arbeiten zu können, wenn nämlich das System während der Veranstaltung ausfällt, ist diese für den A... (jetzt einmal abgesehen davon, daß die Wiener Linien ihre Peinlichkeiten gerne unentdeckt lassen würden). Wenn also bei den Wiener Linien irgendjemand fähig ist Echtzeitdaten zu modellieren (am ehesten findet sich wahrscheinlich noch jemand, der die Plandaten in das Echtzeitdatenformat umwandeln kann – Vorteil: 100% Pünktlichkeit während der Veranstaltung >:D), werden sie das machen.
-
am ehesten findet sich wahrscheinlich noch jemand, der die Plandaten in das Echtzeitdatenformat umwandeln kann – Vorteil: 100% Pünktlichkeit während der Veranstaltung >:D
Pah, viel zu kompliziert. Die haben sicher den Verkehrsablauf eines unkomplizierten Tages mitgeloggt und lassen den Parallelserver den Inhalt dieser Logfiles per Cronjob Stück für Stück neu ausgeben. ;D
-
Die haben keine Cronjobs am Windows-Server. >:D
-
am ehesten findet sich wahrscheinlich noch jemand, der die Plandaten in das Echtzeitdatenformat umwandeln kann – Vorteil: 100% Pünktlichkeit während der Veranstaltung >:D
Pah, viel zu kompliziert. Die haben sicher den Verkehrsablauf eines unkomplizierten Tages mitgeloggt und lassen den Parallelserver den Inhalt dieser Logfiles per Cronjob Stück für Stück neu ausgeben. ;D
Einen unkomplizierten Tag?
Wann soll das gewesen sein 1899? ;D
Das mit dem gespiegelten System ist sicher nicht so schlecht, denn dann kann man bei Programmschleifenfehler das aktuelle System mit zuvielen gleichzeitigen Zugriffen nicht in die Knie zwingen. Das Hauptproblem, wieso qando zeitweise nur Plandaten liefert. Das ist glaube ich auch eine Grundvoraussetzung für ein OpenData. Alles andere Wäre meiner Meinung nach ein programmiertechnischer Selbstmord.
Und alle, die jetzt kommen, beim Programmieren kommt es nicht vor, dass man sich auf einmal in einer Endlosschleife befindet, die haben offensichtlich noch nie ernsthaft programmiert.
-
Und alle, die jetzt kommen, beim Programmieren kommt es nicht vor, dass man sich auf einmal in einer Endlosschleife befindet, die haben offensichtlich noch nie ernsthaft programmiert.
Bei ordentlichem Programmieren kommt es nicht vor, daß man in einer Endlosschleife landet. Wenn man sowas wie
10 PRINT "DEPP"
20 GOTO 10
programmiert, dann schon. >:D >:D >:D
-
Und alle, die jetzt kommen, beim Programmieren kommt es nicht vor, dass man sich auf einmal in einer Endlosschleife befindet, die haben offensichtlich noch nie ernsthaft programmiert.
Bei ordentlichem Programmieren kommt es nicht vor, daß man in einer Endlosschleife landet. Wenn man sowas wie
10 PRINT "DEPP"
20 GOTO 10
programmiert, dann schon. >:D >:D >:D
Hihihi.
Kenn mich mit Programmieren nicht aus, aber das gefällt mir. Stack overflow.
-
Das mit dem gespiegelten System ist sicher nicht so schlecht, denn dann kann man bei Programmschleifenfehler das aktuelle System mit zuvielen gleichzeitigen Zugriffen nicht in die Knie zwingen. Das Hauptproblem, wieso qando zeitweise nur Plandaten liefert.
Aber woher kommen schon jetzt (wo es ja gar keine öffentliche API gibt) diese Probleme? Wirft sich qando in eine Endlosschleife?
Das ist glaube ich auch eine Grundvoraussetzung für ein OpenData. Alles andere Wäre meiner Meinung nach ein programmiertechnischer Selbstmord.
Wenn man ein Service im Web anbietet, tut man gut daran, den Zugriff so zu beschränken, dass dauernde Zugriffe das Service nicht lahmlegen (z.B. mittels request throttling).
-
Bei ordentlichem Programmieren kommt es nicht vor, daß man in einer Endlosschleife landet.
Naja, so pauschal würd ich das nicht sagen. Es gibt doch immer wieder mal Code, wo man im Vorhinein nicht an sämtliche Möglichkeiten denkt. Programmieren ist im Grunde extrem komplex, auch wenn es immer wieder so dargestellt wird, als könne man mit einem Humboldt-Kurs den Programmierer 2 machen.
Jedenfalls habe ich im Umgang mit der WL-API (Qando) meine Kompetenz im Punkto Java Exception Handling enorm steigern können, das ist doch auch was! 8)
-
Naja, so pauschal würd ich das nicht sagen. Es gibt doch immer wieder mal Code, wo man im Vorhinein nicht an sämtliche Möglichkeiten denkt.
Immerhin KANN man an alle Möglichkeiten denken. ;D
-
Das mit dem gespiegelten System ist sicher nicht so schlecht, denn dann kann man bei Programmschleifenfehler das aktuelle System mit zuvielen gleichzeitigen Zugriffen nicht in die Knie zwingen. Das Hauptproblem, wieso qando zeitweise nur Plandaten liefert. Das ist glaube ich auch eine Grundvoraussetzung für ein OpenData. Alles andere Wäre meiner Meinung nach ein programmiertechnischer Selbstmord.
Und alle, die jetzt kommen, beim Programmieren kommt es nicht vor, dass man sich auf einmal in einer Endlosschleife befindet, die haben offensichtlich noch nie ernsthaft programmiert.
Klar kommt das vor, und eine ordentliche Schnittstelle muss natürlich damit rechnen, dass sich die Clients nicht korrekt, geschweige denn nett verhalten.
Aber dafür gibt es geeignete und erprobte Ansätze. Einerseits wird man natürlich einen Cache einbauen, der die Ergebnisse der Abfrage ein paar Sekunden lang vorhält - das reicht schon mal um die Last am Server deutlich zu reduzieren bzw. besser vorhersehbar zu machen (z.B. kann man bei den Haltestellen-Echtzeitinfos dann davon ausgehen, dass innerhalb von x Sekunden maximal jede Haltestelle einmal abgefragt wird; darauf kann man dann die Serverleistung auslegen). Und dann wird man natürlich irgendeinen Zugangsmechanismus einbauen, der allzu häufige Abfragen blockiert (z.B. dass die selbe Anfrage von der selben IP nur einmal alle x Sekunden beantwortet wird).
Wenn man nett ist versieht man die ausgelieferten Daten noch mit einer Gültigkeitsdauer (die überraschenderweise mit der Cache-Dauer korreliert - wer hätte das gedacht), damit sich korrekt arbeitende Clients daran orientieren können und nicht mehr Anfragen stellen als nötig. Eine prognostizierte Ankunftszeit ändert sich ja (hoffentlich) nicht alle paar Sekunden komplett. Das kann man sogar dynamisch machen, z.B. wenn einmal die nächste Ankunft erst in 10 Minuten berechnet wurde zahlt es sich nicht aus, dass alle 10 Skeunden neu durchzurechnen und man kann den Wert länger aus dem Cache ausliefern, wohingegen - wenn der Zug bereits knapp vor der Haltestelle ist - 10 Sekunden den Unterschied zwischen '1' und 'boarding' ausmachen könnten.
Alles keine Hexerei.