Lizenzfrage zu GTFS-Daten

Hallo,
als Newbie bei OpenStreetMap habe ich eine Frage:
Ich würde gerne die Bushaltestellen in meiner Umgebung komplettieren.
Dazu möchte ich die GTFS-Daten des Verkehrsverbundes Berlin-Brandenburg nutzen,
die im Rahmen der OpenData-Initiative (https://daten.berlin.de/) des Landes Berlin
zur Verfügung gestellt werden und unter der „Creative Commons Namensnennung 3.0 Deutschland“-
Lizenz stehen.
Darf ich diese Daten verwenden und in die OSM-Datenbank eintragen?
Wie sieht es im Speziellen mit Haltestellennummern aus, darf ich sie 1:1 übernehmen?
Ist etwas bzgl. der Tags zu beachten?

Vielen Dank für Eure Antworten!

Ich würde sagen “nein”:

Aber die Daten nutzen um “vor Ort” die Daten zu erfassen, ist m.E. möglich. Es geht ja auch um bereits vorhanden nicht doppelt einzutragen. Es gibt auch eine Gruppe ÖPNV Berlin: http://wiki.openstreetmap.org/wiki/Berlin/%C3%96PNV-Gruppe

Hallo,

Zur Lizenzfrage sei auf https://blog.openstreetmap.org/2017/03/18/benutzung-von-cc-by-4-0-daten-in-openstreetmap/?lang=de verwiesen.

Anmerkung von mir dazu: Die CC-BY-Lizenzen verlangen, dass die Quelle angegeben wird. Wir müssten also alle Nutzer von OpenStreetMap-Daten zwingen, auch “Verkehrsverbund Berlin-Brandenburg” neben das “© OpenStreetMap contributors” zu setzen. Das skaliert nicht, weil wir eben nicht nur eine sondern tausende Quelle haben. Unsere Datenquellen müssen daher damit einverstanden sein, dass sie nicht namentlich genannt werden. Bei zahlreichen sind wir den Kompromiss eingegangen, dass sie auf https://wiki.openstreetmap.org/wiki/Contributors erwähnt werden.

OSM-Daten sollten vor Ort überprüfbar sein. Es muss gute Gründe geben, warum eine Haltestellennummer in OSM erfasst werden soll. In Freiburg sind sie tatsächlich ausgeschildert, aber ob das in Berlin der Fall ist, weiß ich nicht. Je mehr Fremdschlüssel in OSM herumgammeln, desto unverständlicher sind die Daten für uns Mapper. Gerade Fremdschlüssel können schwierig bis gar nicht überprüfbar sein.

Bitte denk daran, dass es sich in meinen Augen um einen Import handelt, wenn du Fremdschlüssel systematisch übernimmst und für diesen die Import-Richtlinie gilt.

Übrigens, in Berlin gibt es schon einen GTFS-ID-Import, dessen Revert ich schon plane.

Viele Grüße

Michael

Hallo,
die Überprüfbarkeit der Daten wäre gegeben, da bei uns im Landkreis an jeder Haltestelle die Nummer und ein entspr. QR-Code angegeben sind!
Natürlich hat der VBB die Nummern vergeben, die den OSM-Nutzer so nicht interessieren, also Fremdschlüssel sind.
Interessant sind aber die Informationen, die hinter der Nummer stehen, nämlich die Fahrplandaten.
Warum soll der OSM-Nutzer nicht zu den Haltestellen-Eigenschaften (z.B. shelter, tactile paving, wheelchair) nicht auch diese Informationen leicht erhalten können?

Das ist bei uns auch so.

Und die vvo-id=33001114 ist über den QR-Code erreichbar. Wobei ich auch qr_code=http://www.vvo-online.de/de/fahrplan/aktuelle-abfahrten-ankuenfte/abfahrten?stopid=33001114 angebe, um durch “Einklick” auf die Haltestellenseite zu kommen.

Da aber das ganze ÖPNV noch viel zu unterschiedlich genutzt wird, mappe ich die Haltestellen und lasse die Routen (-relationen) ungeändert. Zu mal sich bei jeden Fahrplanwechsel auch Liniebezeichnungen und -führungen ändern.

Deine Praxis statt IDs merkwürdige URLs in die OSM-Datenbank einzutragen ist wirklich (wirklich, wirklich) dumm. Der Grund, warum wir solche Daten überhaupt sammeln ist, damit sie von Programmen ausgewertet werden können. Ein Programm soll mittels solch einer ID über eine Programmierschnittstelle etwas abfragen oder oder eine Aktion auslösen können. Mit deiner Praxis verhinderst du aber, dass Programme diese ID im Tag erkennen können. Du produzierst also letztlich Datenmüll, mit dem niemand etwas anfangen kann.

Der Grund, warum du das machst, ist, damit du auf der OSM-Website anklickbare URLs bekommst. Diese OSM-Website ist aber nur für Demonstrationszwecke und für Mapper gedacht. Sie ist nicht der Endzweck der OSM-Daten. Deine Praxis ist also eine Art Mapping for the renderer.

Das Problem auf der OSM-Website, dass man nur wenige Tag-Werte anklicken kann, liegt bei der Website, nicht bei den Daten. Die Argumentation der OSM-Website-Betreuer geht dahin, dass diese Website ja nur Demonstrationszwecken dient und die Website-Betreuer nicht die Daten pflegen wollen, wie die jeweiligen Werte in anklickbare URLs umgewandelt werden. Dieses Problem würde sich aber lösen lassen. (Mit Wikidata.)

Dann hast du wahrscheinlich auch den Revert von local_ref schon vorbereitet, dem Buchstabensystem von London buses.

Zum Thema:
Wenn die Nummer an jeder Haltestelle dransteht, darf sie auch in die Datenbank. Nur eben nicht von der oben angefragten Liste.

Statt dem Nummernsysten ist es meist sinnvoller die Haltestelle über den Namen zu suchen. Wenn dieser nicht eindeutig ist, kann er im ref_name präzisiert werden.

Gruß, Axel

Ich verwende nicht statt der ID - sondern zusätzlich - eine Verlinkung.

Ich finde eine website=* oder image=* mit url ist die einfache Art, Daten zu verwenden. Wenn ich an einer Haltestelle (oder POI) über die url aus den Daten weitergeleitet werde ist es ein Gewinn.

Ich stehe vor einem Denkmal geschützten Haus und erfahre über den den Wikipedia-Link mehr dazu.

Dagegen erreiche ich aus den Daten unter image=File:* oder wikipedia:de=* … nur etwas, wenn ich vorher zu der entsprechenden Seite wechsle und dort nach der die ID suche.

Finde ich nicht, da die vvo_id ja vorhanden ist. Ich sagte ja, dass man sie aus dem QR-Code ableiten kann.

Ich möchte mich nicht wiederholen. Zu ID (strukturierte Daten, maschinenlesbar) vs. URL (nur menschenlesbar) s.o.

Die konkreten Vorteile in diesem Fall (File:-Syntax bei image) sind:

  • Die Lizenz des Bilds ist abrufbar. (Wichtig!)

  • Verschiedene Größen des Bilds sind abrufbar.

  • In Zukunft, nach der anstehenden Wikidata-isierung von Wikimedia Commons: Viele weitere Daten über das Bild sind über eine Programmierschnittstelle abrufbar.

Dass der image-Tag besser hätte definiert werden sollen, stimmt. Es wäre besser, ausschließlich URLs (einer Grafik, nicht einer HTML-Datei) zu nutzen. Die Commons-File-Angabe sollte eigentlich einen anderen Key haben. Beispiel wie es besser ginge:

Leider hat man sich auf so etwas bis jetzt nicht geeinigt.