Wäre gut, aber selbst mit: lässt sich implementieren: Public API Download (nur um den Link mal zu dokumentieren).
Hmm, für Österreich weiß ich das nicht. Für DE unter DE:Permissions, für den MVV (“ab 2019”) hatte ich den Inhalt der Mail dann auf einer extra Seite abgelegt.
Mir persönlich ist der Ort egal, solange ich darauf verweisen kann.
Der eigentliche Zugriff erfolgt mit Hilfe eines TOKEN, der nach Angabe von Username und Password vom KeyCloak-Server mitgeteilt wird. Wenn der TOKEN eine lange Lebensdauer (mehrere Monate oder länger) hat muss ich Username und Password nicht wissen, nicht speichern. Den TOKEN würde ich dennoch nicht öffentlich einsehbar speichern.
Ja, danke, passt.
Habt ihr bereits eine “offizielle” @openstreetmap.at E-Mail-Adresse, die ihr verwenden könnt? Ich gehe mal davon aus, dass ihr die Registrierung übernehmt, sofern notwendig. Ich brauche dann nur den Token.
@ScubbX Haben wir eine solche allgemeine E-Mail für eine Registrierung über das Local Chapter?
Ansonsten können wir auch noch abwarten ob es die Möglichkeit gibt ohne Zugang darauf zuzugreifen.
Als pdf ins Wiki hochladen und hier Contributors - OpenStreetMap Wiki verlinken gleich wie z.B. beim OGD Portal Steiermark, basemap.at und dem BEV Addressregister
Danke! Hab es hochgeladen: File:Erlaubnis zur Einbindung von CC BY-Daten in OpenStreetMap.pdf - OpenStreetMap Wiki
@ToniE Folgende Antwort kam:
die Bereitstellung unserer Daten ist aus lizenzrechtlichen Gründen an die Registrierung auf der Plattform gebunden. Als registrierter Nutzer haben Sie dann auch die Möglichkeit, aktualisierte Daten eines Fahrplanjahres mittels Script o.ä. über den jeweils gleichbleibenden Link zu beziehen. (siehe auch “Public API Download” - https://mobilitaetsverbuende.atlassian.net/wiki/spaces/DBP/pages/185827383/Public+API+Download)
Sofern Sie die Daten Ihren Usern direkt und unverarbeitet zur Verfügung stellen wollen, können Sie jederzeit auf den möglichen Bezug über unsere Plattform verweisen. Alternativ können Sie selbst die Daten über einen eigenen “Permalink” und unter gleichen Lizenz- und Nutzungsbedingungen verbreiten. Einer wie von Ihnen beschriebene Veröffentlichung Ihrer Zugangsdaten über GitHub oder über einen anderen Weg können wir aus datenschutzrechtlichen Gründen jedenfalls nicht zustimmen.
Mit APIs kenne ich mich nur sehr wenig aus. Was brauchst du / wie kann ich dich hierbei bestmöglich unterstützen?
@mcliquid eine solche Antwort habe ich (verständlicherweise) erwartet.
Stellt aber kein Problem dar.
Ihr müsstet Euch als AT-Community bei den Mobilitätsverbünden registieren. Wenn das geschehen ist, kann man evtl. dort auch einen Token generieren, der den Zugang via API erlaubt - nur den nutze ich dann. Das Password brauche ich nicht.
Wenn man den Token nicht auf deren Webseite erzeugen kann, kann ich Euch eine Möglichkeit nennen wie das geht.
@ToniE Nach der Umstellung auf 100er-Busnummern in Vorarlberg gibt es jetzt grenznah eine schweizer und eine österreichische 303-Linie (PTNA - AT-8-VVV)
Wie kann man die beiden Linien korrekt voneinander trennen, sodass sie im Tool nicht vermischt werden?
Ich hab’s mir mal angeschaut, es war anfangs auch für mich ein wenig verwirrend.
Von daher wird der 303er aus der Schweiz auch akzeptiert (‘network’ passt)
Man kann ‘network’ interpretieren als:
Tendenz liegt wohl bei den meisten Mappern auf den zweiten Fall. Aber: PTNA macht hier keine Vorgaben.
Im konkreten Fall (und wenn man an ‘network’ nichts ändert) müssen in der CSV-Liste zunächst einmal zwei Einträge für die beiden 303er gemacht werden, damit PTNA weiß, dass es zwei Linien mit der selben Nummer gibt. Um die beiden 303er zu unterscheiden analysiert PTNA dann das ‘operator’ tag der Relation und die ‘Betreiber’-Angabe in den CSV-Daten.
303;bus;;Götzis Bahnhof;Zentrum;Ortsbus am Kumma
303;bus;;Diepoldsau|Hohenems;Heerbrugg;BOS/rtb
wären dann zwei Einträge, die passen sollten. Wo (welche Zeile der CSV-Daten) die beiden Einträge jeweils stehen ist egal.
BTW: Beim DE-SN-VMS gibts viele ‘A’, ‘B’, … Linien in verschiedenen Gemeinden (‘Kleiner Stadtverkehr’), die z.T. auch noch den selben ‘operator’ haben - auch dass beherrscht PTNA, indem ‘from’ und ‘to’ auch noch analysiert werden.
Bis jetzt leider noch nicht, ich hoffe nächste Woche auf eine Rückmeldung.
händisch ausgewertet: schon mal ein “Vorgeschmack” AT-Eisenbahn und die Details dazu
Wir arbeiten noch an einer gescheiten Automatisierung
So, die anderen GTFS-Quellen sind nun auch (händisch) ausgewertet.
Schauen wir mal, wie wir mit der Automatisierung vorankommen.
Der Download der ZIP-Files ist derzeit manuell via deren Webseite, mit ‘login’.
BTW: Hat die Linz-AG ein eigenes Tarifsystrem oder ist das im OÖVV integriert?
Warum wird für Linz AG ein eigener GTFS-Datensatz angeboten?
Die Antwort ist höchst seltsam: Zum einen verstehe ich nicht, welche lizenzrechtlichen Gründe für eine Registrierungspflicht sprechen. Die CC-BY-Lizenz, von der die MVO-Lizenz abgeleitet ist, erfordert jedenfalls keine solche Registrierungspflicht, weil sie auf dem Urheberrecht aufbaut. Zum anderen darf jede Person diese Daten weitergeben, wodurch die Registrierungspflicht ohnehin ausgehebelt werden kann, und das schlagen sie sogar als eine mögliche Lösung vor (und das würde ich auch als einfachste Lösung vorschlagen). Also was bringt es, da eine Registrierung für den Download direkt von den MVO zu verlangen?
Außerdem sind “Datenschutzgründe” eine seltsame Begründung dafür, eine Weitergabe unserer eigenen Zugangsdaten zu untersagen, denn Datenschutz gilt ja nicht für die Person, der die Daten gehören. Es würde halt das Registrierungssystem ad absurdum führen, aber das tut die erlaubte Lösung, die Daten bei uns zu mirroren, doch auch.
Auch interessant ist:
https://mobilitaetsverbuende.atlassian.net/wiki/spaces/DBP/pages/85524481/Nutzungsbedingungen
und zwar dieser Absatz:
Die bereitgestellten Daten der Mobilitätsverbünde Österreich OG dürfen nicht für Anwendungen oder Veröffentlichungen verwendet werden, die kriminelle, illegale, rassistische, diskriminierende, verleumderische, pornographische, sexistische oder homophobe Aktivitäten unterstützen oder zu solchen Aktivitäten anstiften.
der in der eigentlichen Lizenz nicht vorkommt. Das ist eine Field-of-use-Einschränkung und daher eindeutig unfrei (und damit auch nicht mit der ODbL kompatibel).
Ein klassisches “jein”: Das Tarifsystem ist prinzipiell im OÖVV integriert, aber die Kernzone Linz ist ein Sonderfall, es gibt halt Sondertarife für Fahrten (bzw. Zeitkarten) innerhalb von Linz, und bei Fahrten von/nach/durch Linz macht es einen Unterschied, ob man nur direkt zum Hauptbahnhof (oder einer Haltestelle auf der Strecke dorthin) fährt oder ob man weiter fährt: In ersterem Fall ist die Kernzone Linz nur als normale Zone zu bezahlen, in letzterem Fall ist zusätzlich ein Kernzonenaufschlag fällig.
Ein weiterer Sonderfall ist die Straßenbahnlinie 4, die von der Linz AG betrieben wird, aber trotzdem die Kernzone Linz verläßt: Und zwar gehört die Strecke auf den Gemeindegebieten von Leonding und Pasching (und damit die gesamte Strecke der kürzeren Linie 3) noch zur Kernzone, Traun ist aber eine eigene Zone. Die Kernzonengrenze ist die Trauner Kreuzung (Endstation Linie 3) an der Grenze zwischen Traun und Wagram (Pasching). (Die Haltestelle befindet sich bereits auf Trauner Stadtgebiet.) Die Zone Traun beginnt 2 Stationen früher bei der Plus City. (Es gibt also eine kleine Überlappungszone.) Damit gelten auf der Linie 4 dieselben Regeln wie für jede andere Verbundlinie: Von Traun (außer Trauner Kreuzung) aus kann man mit einem Ticket nur für Traun bis zur Plus City fahren, mit einem Ticket für Traun und Linz ohne Kernzonenaufschlag bis zum Hauptbahnhof, und nur mit einem Ticket für Traun und Linz mit Kernzonenaufschlag weiter. Ähnliches gilt Richtung Traun.
since we would use their information only as reference in a QA tool, I don’t see the problem. (once ptna mentions the source for the cross check)
We already have a written consent from MVÖ after all, so all three posts miss the point of the topic. I’ll leave them here anyway, but I would move them to their own topic in case of further contributions.