This is a read only archive of pad.okfn.org. See the shutdown announcement for details.

ogdgrazmeetup06 6. Open Goverment Data Meetup Graz
Wann: 19. November, 18:00
Wo: Mediacenter im Rathaus


Datenwünsche:
An Stadt Graz:
An Land Steiermark - Hr. Moerth laesst sich entschuldigen, persoenlich Anschreiben.

Verbundlinie:

Präsentationen aus der Community zur Datenverwendung:

Aktuelles vom Land:
Diese Daten des Landes werden bis Ende November zusätzlich für OGD verfügbar sein: 
 
·         Städtisches und Ländliches Straßennetz (inkl. Straßennetz von Graz) 
·         Burgen und Schlösser 
·         Museen 
·         Hauskrankenpflege Standorte 
·         Feinstaubsanierungsgebiete 
·         Abfallwirtschaftliche Daten 
·         Forstliche Statistik 
·         Gemeindekontaktdaten 
Seit dem letzten Treffen neu verfügbar von der Landesstatistik sind: 
·         Gestorbene und Geborene
·         Beliebteste Vornamen

 Weitere Themen (Vorschlag):

Protokoll:
 - Getraenke wurden vom Buergermeister gespendet.
 - Location/Mediacenter von MagDir Haidvogl beigestellt
 
Verkehrsdaten des Verbundes kommen, nur wie ist noch die Frage.
Stadtrat Eustaccio hat noch nicht auf Anfrage reagiert.
Verbund sehr postiv eingestellt, es würde helfen wenn das Land als Eigentümerin eine Willenskundgebung&Unterstuetzung bietet
Holding Graz ist sehr positiv dem gegenueber eingestellt, zahlen soll der Verbund - Ende Q1 2014 sollen die Daten live gehen
ueber Funk werden alle 30s alle Fahrzeuge gepollt.
Ortung laeuft physikalisch ueber infrarotbarken und Odometriedaten, kein GPS

Schnittstellen: Preislich sind beide Varianten ca. gleich, beide Ende Q1 versprochen.
Beide muesste mit eineigem Aufwand an die internen Verbund-Schnittstellen angepasst werden.
Update: in einer Besprechung mit Hrn. Brandl wurde für die TRIAS-Schnitstelle entschieden. Es kommt ein (virtueller) Server, der in ca. das Selbe liefert wie die Features auf verbundlinie.at. 

Es gibt >100 Busunternehmen in der Steiermark, noch nicht alle haben Echtzeitdaten. Es wird noch lange dauern, bis alle steiermarkweit live-Daten haben

Frage: Welches Protokoll verwendet OEBB (Zugradar) http://zugradar.oebb.at/bin/help.exe/dn?tpl=livefahrplan 

Anmerkung, dass der Impact der OGD-Initiative noch nicht erwünschtes Potential schöpft, was Ausweitung/Fortsetzung aber förderlich wäre

data.gv.at hat ein Angebot an den Städtebund gegeben, dass sie so günstig ihre Daten veröffentlichen können (zB Engerwitzdorf nutzt das)

Welche Anwendungen nutzen bereits Daten der Stadt? Bitte an ogd@stadt.graz.at melden

Feedback zu Phase III

Ende Nov kommen neue auf data.steiermark.gv.at

Aerzte kommen ja von der Aerztekammer - dort sind sie allerdings auch nicht aktuell.

Idee: Ausfallsicherung fuer Defis/Feuerloescher seitens der Stadt, und auch bessere Regelung betreff der Offebnlegung der daten via DEFI-App anzuregen

Baumkataster: 
Baumpatenschaften gibts jetzt keine neuen mehr - derzeit sind 199 nur eindeutig zuordnenbar. Jedoch ist im Baumkataster jedoch kein Hinweis, ob dort eine Tafel ist.
Viele Baumpatenschaften sind gar keinem eigenen Baum zuordnenbar. 


Naechstes Treffen, Dienstag 11.2. 
naechstes mal besser bewerben!

Anwesend:
Philip Pacanda, Gemeinderat. (@Fisima_)
Daniela Grabe, Gemeinrätin
Peter Mayr, Aufsichtsrat ITG
Barbara Meyer
Barbara Rauscher, OGD Graz
Stefan Tiran (OpenStreetMap)
Johann Müller, Graz Linien
Michael Maier (OpenStreetMap)
Martin Raifer (OpenStreetMap)
Michael Gebetsroither
Walter Buzina
Wolfgang Reinisch
Peter Zurk

Heinz Wittenbrink - entschuldigt
Keith Andrews entschuldigt


Nächstes Treffen an der FH Joanneum
Dienstag, 11.2.2014, 18:00, FH JOANNEUM, 
Gebäude Alte Poststraße 152, Parterre , Besprechungszimmer des Studiengangs Journalismus und PR 


Links zu den vergangenen Treffen:
5. Meetup 27.8.2013 , TU Graz http://pad.okfn.org/p/ogdgrazmeetup05
4. Meetup 21.5.2013, Spektral http://pad.okfn.org/p/ogdgrazmeetup04
3. Meetup 19.02.2013 http://okfnpad.org/ogdgrazmeetup03
2. Meetup 13.11.2012 http://okfnpad.org/ogdgrazmeetup02
1. Meetup 24.7.2012 http://okfnpad.org/OpenWeekGraz-Day2-OpenData (unten)

 



-------- Original-Nachricht -------- 
       
Betreff: 
        
EFA XML vs TRIAS
            
Datum: 
        
Fri, 15 Nov 2013 16:04:28 +0100
            
Von: 
        
Patrick Wolowicz <patrick@subzero.eu>
            
An: 
        
Stefan Kasberger <mail@stefankasberger.at>
            
Kopie (CC): 
        
Robert Harm <robert.harm@open3.at>
    
 
Hi Stefan,
 
Hier wie erwünscht ein paar Anmerkungen zu euren Optionen von Robert und mir. Wir fügen eine euch nicht angebotene Option ein, die vermutlich nicht machbar ist, aber dennoch erwähnt werden sollte: das Lizenzmodel für euren bereits vorhanden Server auf Open Data ändern.
 
Erstmal möchte ich aber ein paar Punkte ihrer "Varianten" kommentieren:
 
- Die von MDV verwendete XML-Interface ist ein internes Format und unterliegt regelmäßigen Anpassungen im Rahmen der Weiterentwicklung und liegt nur mit internen Dokumentationen vor.
In Wien und Linz haben wir auch nur als Dokumentation etwas was intern zu sein scheint, wir Appentwickler schaffen das dennoch ;). Es gibt bereits einige Apps die inoffiziell eure vorhandene Schnittstelle nutzen, problemlos.
- Für OGD soll eine statische Schnittstelle zur Verfügung gestellt werden; dadurch wird sichergestellt, dass de in der Schnittstelle beschriebenen Aufrufe und Ergebnisse sowohl in ihrer Struktur als auch im Datenverständis der einzelnen Felder über zukünftige EFA-Relases unverändert zur Verfügung gestellt werden, so dass auch eine XML-Schemaverifikation möglich wird.
Auch die bereits vorhandene Schnittstelle muss halbwegs "statisch" sein, oder zumindest rückwärtskompatibel. Tausende Grazer haben das BusBahnBin App auf ihrem Handy, der Verkehrsverbund kann also nicht einfach die Schnittstelle ändern, dann würde das BusBahnBim App auf den Handys nicht mehr gehen. Klar können sie auch das BusBahnBim App aktualisieren, aber da nicht jeder Kunde immer brav sofort jedes App updated müssen Schnittstellenupdates so oder so rückwärtskompatibel sein.
- Die statische EFA-XM-Schnittstelle ist eine je Anwender/MDV-Kunden individuell angepasste Schnittstelle.
Theoretisch. In der Praxis sind die unterschiede so minimal dass es für uns Entwickler überhaupt kein Problem ist hierauf einzugehen, so wie es für einen Wiener kein Problem ist sich in Graz mit einem Grazer zu unterhalten, der Dialekt ist ein klein wenig anders, die Sprache ist aber die selbe.
- Die statische Schnittstelle verbleibt vollständig im Eigentum von MDV, es ist je EFA-Server auf den zugegriffen wird eine Lizenz erforderlich.
- Zum robusten Betrieb dieser Schnittstelle empfiehlt MDV den einsatz einer eigenen Serverinfrastruktur, die die eigentliche Fahrplanauskunft vor DoS-Attacken schützt.
Die Linz AG schafft es Open Data vom selben Server zu betreiben den sie für ihre eigene Apps verwenden. Da diese Server bereits tausende Anfragen von den eigenen Apps beantworten müssen, müssen sie bereits gegen DoS Attacken geschützt sein. Beim letzten Stammtisch bei dem ich dabei war hat das Herr des Verkehrsverbunds indirekt bestätigt. Darauf hin wurde das Argument mit den "wir müssen Daten der anderen Verkehrsbetriebe rausfiltern" gebracht, was stimmen mag.
 
Und nun zu den eigentlichen Varianten:
 
Grundsätzlich sind beide Optionen sehr wahrscheinlich technisch OK.
 
EFA XML
+ In einem Grossteil Österreichs bereits in Verwendung. Siehe http://www.offene-oeffis.at/status/, rechte Graphik. Alle gelben Bereiche sind EFA XML (wir nennen es MDV weils von der Firma MentzDV kommt).
+ Den Server habt ihr schon. Sie wollen ihn duplizieren wegen DOS attacks etc. Der aktuelle Server muss aber bereits gegen DOS Attacken abgesichert sein... Der Server hat aber anscheinend auch Daten anderer Verkehrsbetriebe und diese müssten sie rausfiltern da sie diese nicht eigenmächtig als Open Data geben können, deswegen wohl wirklich der Wunsch nach einem zweiten Server (+ 'free' money, yeay!).
+ Alle Apps in Linz und die meisten in Wien sind bereits jetzt mit diesem Standard kompatibel.
 
TRIAS
+ Laut Herrn Pischinger (Linz AG) wird das in Deutschland der künftige Standard.
+ Laut Herrn Pischinger (Linz AG) wird die Schnittstelle langfristig mehr können.
- Es gibt im Netz kaum etwas offizielles zu diesem Standard.
- Der Standard ist angeblich noch nicht fertig, könnte also eure Open Data Pläne verzögern
- Da der Standard noch nicht verfügbar ist, gibt es keine kompatiblen Apps, würde also das erscheinen neuer Apps ein wenig verzögern weil wir Appentwickler erstmal unsere Backends anpassen müssten.
 
Vorhandener Server zum Open Data Server machen
+ Geringste Kosten
+ Schnellste Umsetzung (zumindest theoretisch, die Daten der nicht-Steirischen Verkehrsverbunde müssten rausgefiltert werden)
+ Server wäre selten Offline da dann auch Anzeigetafeln und offizielle Apps nicht funktionieren
- Verkehrsbetriebe werden mit "wir müssten Fremddaten rausfiltern" argumentieren
- Verkehrsbetriebe werden mit "Serverüberlastung" argumentieren
- Verkehrsbetriebe fühlen sich "wohler" mit zusätzlichem Server und geben so oft ihren Open Data Widerstand leichter auf.
 
Ich weiss ich hab jetzt mehr Pluspunkte für die EFA XML geschrieben, es liegt aber daran dass diese Schnittstelle bekannt ist und die andere nicht.
 
Was ich an eurer Stelle machen würde um bei der Entscheidung zu helfen:
- Fragen wie lange es zwischen OK fürs Projekt und dem Release dauern würde. Ich denke das mit der EFA XML Schnittstelle geht deutlich schneller als die TRIAS Schnittstelle
- Nach den Kosten fragen, ich denke auch hier wird die EFA XML Schnittstelle besser abschneiden
- Fragen was die TRIAS Schnittstelle genau besser kann als die EFA XML Schnittstelle, also wirklich konkret (z.B. genauere Prognosen? Schnellere Antwortzeiten?, etc)
- Vielleicht bin ich hier ein wenig übervorsichtig, aber achtet darauf dass der Open Data Server auch die Echtzeitdaten eingespielt kriegt und sie nicht vorhaben nur einen Server, egal bei welcher Variante, mit Plandaten aufzustellen.
 
Anhand dessen würde ich dann abwägen.
 
Da sie euch unbedingt einen neuen Server geben möchten, achtet darauf dass ihr das Service Level Agreement Problem (http://en.wikipedia.org/wiki/Service-level_agreement) löst. Während die Linz AG den selben Server für ihre eigenen Services und auch für Open Data verwendet (es ist also durchaus möglich, entgegen aussagen eurer Verkehrsbetriebe) sind es in Wien auch getrennte Server. Das hat einen Nachteil: Wenn in Wien der Server der für das offizielle Wiener Linien App Qando verantwortlich ist auch nur hustet, sind die Techniker gleich zur Stelle und sorgen das er in kürze wieder online ist. Der Open Data Server wird hingegen repariert wenn der eine zuständige Techniker dafür Zeit findet. Das lief bei uns die ersten zwei Monate zwar gut, in den letzten 2 Wochen war der Open Data Server der Wiener Linien 3 mal für über 24 Stunden offline, während der Qando Server immer online war. Das sorgt dann natürlich für eine gewisse Unzufriedenheit mit den Open Data Apps bei den Usern.
 
Hoffe das hilft euch weiter.
 
LG,
Patrick
 
 
 
Liebe Daniela,
 
habe extra beim Hersteller nachgefragt, ist kein Problem!
 
lgm.

Manfred Brandl
Steirische Verkehrsverbund GmbH


>>> "Daniela Grabe" <danielagrabe@gmx.at> schrieb am 13.11.2013 um 13:25:
Lieber Manfred,
 
nur zur Sicherheit: Darf eh so an die Community weitergegeben werden, oder?
 

 
Von: Manfred Brandl [mailto:Manfred.Brandl@verbundlinie.at]
Gesendet: Dienstag, 12. November 2013 13:34
An: Meyer, Barbara
Betreff: Vergleich Schnittstellen-Varianten "EFA-XML" und "TRIAS"
 
Liebe Frau Meyer,
 
wie gestern besprochen liegen uns zwei Angebote der Firma Mentz Datenverarbeitung (MDV)
für die Einführung einer "Open Government Data Schnittstelle für EFA10" vor.
 
Variante "EFA-XML":
Die von MDV verwendete XML-Interface ist ein internes Format und unterliegt regelmäßigen Anpassungen
im Rahmen der Weiterentwicklung und liegt nur mit internen Dokumentationen vor.
Für OGD soll eine statische Schnittstelle zur Verfügung gestellt werden; dadurch wird sichergestellt,
dass de in der Schnittstelle beschriebenen Aufrufe und Ergebnisse sowohl in ihrer Struktur als auch im Datenverständis
der einzelnen Felder über zukünftige EFA-Relases unverändert zur Verfügung gestellt werden,
so dass auch eine XML-Schemaverifikation möglich wird.
Die statische EFA-XM-Schnittstelle ist eine je Anwender/MDV-Kunden individuell angepasste Schnittstelle.
Die statische Schnittstelle verbleibt vollständig im Eigentum von MDV, es ist je EFA-Server auf den zugegriffen wird
eine Lizenz erforderlich..
Die Schnittstelle selbst und deren Dokumentation werden in englischer Sprache zur Verfügung gestellt
und richten sich an Entwickler. Zur Interpretation der Dokumentation wird die Kenntnis von XML,
HTML und des HTTP-Protokolls vorausgesetzt.
 
Gegenstand des Angebots sind die folgenden Anfragetypen an den EFA-Server:
TRIP_REQUEST2 für Reiseauskünfte (Verbindungsauskünfte)
DM_REQUEST für Abfahrtstafeln
ADDINFO_REQUEST für Störungsmeldungen
 
Zur Nutzung der Schnittstelle bietet MDV eine eintägige XML-Schnittstellen-Schulung
für max. 5 Mitarbeiter der Holding Graz Linien an; diese wird vor Ort oder im Wiener Büro von MDV abgehalten.
Die Dokumentation wird im Anschluss an die Schulung zur Verfügung gestellt.
Eventuelle Rückfragen durch Nutzer der Schnittstelle können gesammel und an MDV übersendet werden.
Diese werden in drei Antwortrunden abgehalten. Die Zeitpunkte dazu sind mit dem Projektleiter zu vereinbaren.
 
Variante "TRIAS":
 
Für den öffentlichen Zugang (OGD) soll die offene Nutzung der IP-KOM-ÖV-Schnittstele (TRIAS) realisiert werden.
Zum robusten Betrieb dieser Schnittstelle empfiehlt MDV den einsatz einer eigenen Serverinfrastruktur,
die die eigentliche Fahrplanauskunft vor DoS-Attacken schützt.
Es werden Lizenzen für einen zusätzlichen EFA10-Server und die Installation der TRIAS-Schnittstelle angeboten.
Die Schnittstelle wird über eine Middleware realisiert, diese wird auf einem von der StVG bereitgestellten Rechner installiert.
Die Middleware leitet die Anfragen an ein EFA10-System weiter, welche ebenfalls auf einem von der StVG bereitgestellten
Rechner installiert wird.
 
Es sind folgende IP-KOM-Spezifikationen verfügbar (ID und Feature Name)
Übersicht
12: LocationInformationRequest
17: StopEventRequest
20: TripRequest
LocationInformationRequest
1201: Geoposition
1203: LocationName
1204: Restriction Type
StopEventRequest
1701: StopPointRef
1703: Geoposition
1711: DepArrTime
1713: PtModeFilter
1718: StopEventType
TripRequest
2001: StopPointRef
2003: GeoPosition
2006: AddressRef
2008: Via
2011: NumberOfResults
2014: InterchangeLimit
2021: IncludeIntermediateStops
2022: IncludeFares
2029: NoStairs
2030: NoEscalator
2031: NoElevator
2035: Walkspeed
 
Wie gestern besprochen muss ich mich für den kommenden OGD-Stammtisch wegen einer Besprechung in Wien leider entschuldigen.
 
Mit den besten Grüßen
Manfred Brandl
 
Manfred Brandl
Steirische Verkehrsverbund GmbH


zu Baumpatenschaften: seit einiger Zeit gar nicht mehr; 199 Bäume zuordenbar; es gibt ein Leinenbuch