Hilfe benötigt wegen auffälligem Datenimport

Hallo zusammen,

mir ist vor kurzem ein Datenimport eines Users aufgefallen, der offensichtlich im Auftrag der VAG in Nürnberg und Umland vorgenommen wurde.

Aufgefallen ist mir zunächst, dass plötzlich einige Haltestellen auftauchten, die es so vor Ort gar nicht gab.

Das ganze betrifft folgende Changesets:
(1)http://www.openstreetmap.org/changeset/50994036
(2)http://www.openstreetmap.org/changeset/50995291
(3)http://www.openstreetmap.org/changeset/49691424

In dem Zuge ist mir ein weiteres Changeset aufgefallen, welches bereits von einem anderen User kommentiert worden war:
(4)http://www.openstreetmap.org/changeset/51033842

Dazu habe ich kurz vorher von einigen Nürnberger Mappern erfahren, dass es offensichtlich einige Aktivitäten in der Stadt gibt bezüglich einiger User, die offensichtlich im großen Stil das ÖPNV-Tagging in Nürnberg überarbeiten:
http://www.openstreetmap.org/note/996361
Dabei fiel auch immer wieder der Name Mentz, auch wenn ich dafür bisher keinen Beleg gesehen habe.

Nachdem ich den User Marsura über ein CS angeschrieben habe, stellte sich auch heraus, dass es sich wie vermutet um einen Datenimport handelte (diese Diskussion lief dann ausschließlich über das dritte CS), welcher offenbar von der VAG (Das Nürnberger Verkehrsunternehmen) beauftragt worden war. Dabei wurden offensichtlich Daten aus einer Stationsdatenbank händisch (das lässt sich aus den Intervallen der CS schließen) in die OSM-Datenbank eingepflegt, wobei ganz offensichtlich keinerlei Vor-Ort-Kontrolle erfolgt ist und auch einige Haltestellen Eingetragen wurden, die vor Ort gar nicht vorhanden sind, sondern nur im Falle einer (baustellenbedingten) Umleitung eingerichtet wird.

Besonderes Ziel der Aktion war wohl, die IFOPT-Nummern (wie ich das verstanden habe die internationalen Haltestellen-Nummern) einzupflegen und den Datensatz zu vervollständigen, um auf diesen Daten einen Fahrgastinformationssystem aufzubauen. Generell ahbe ich auch gar nichts gegen ein derartiges Vorgehen, z.B. wurdem bei einem Datenimport in Köln vor etlichen jahren schon die VRS:ref mit eingepflegt und für Bahnstationen sind ja auch die refs Standard.

Nachdem der User Marsuna bisher recht kooperativ auf die Fragen geantwortet hat (auch, wenn bisher noch nichts passiert ist im Sinne einer Problembehandlung), fände ich es sehr hilfreich, wenn sich jetzt ein paar erfahrernere Mapper der Sache annehmen würden, da ich nicht genau weiß, wie man in der Sache jetzt weiter vorgehen soll, zumal ich keinerlei erfahrungen mit Datenimporten habe.

Einen komplett-Revert finde ich persönlich derzeit sehr Fehl am Platz, da ein großteil der Daten wohl brauchbar ist. Meiner Ansicht nach fehlt bisher eine Dokumentation des Imports, sowie ein Mechanismus zur Fehlerreduzierung. Aber da bin ich tatsächlich überfragt.

Viele Grüße,

hsimpson

Hallo,

Die Import-Richtlinie schreibt aus gutem Grund vor, dass Importe vorher diskutiert und dokumentiert werden müssen. Darüber hinaus fragen erfahrene Import-Prüfer [1], ob es eine aktive Community in der Gegend gibt und ob diese eingebunden ist und mitarbeitet. Der Import scheint, wenn ich deinen Schilderungen Glauben schenken mag, leider ein Beispiel zu sein, warum wir die Import-Richtlinie benötigen.

Durch Vor-Ort-Recherchen [2] und Ortskenntnis haben gsperb und du herausgefunden, dass die Datenqualität fragwürdig ist. Oder, um es anders auszudrücken: Sie genügt nicht unseren Qualitätsansprüchen. Ich nehme an, dass ihr nicht ganz Nürnberg, Fürth und Erlangen abgefahren seid und daher nicht alle Haltestellen überprüft wurden. Es ist davon auszugehen, dass der Import noch weitere Fehler in OSM gebracht hat.

Bei gravierenden Verstößen gegen die Richtlinie ist es üblich, den Import zu revertieren. Wer nämlich importiert, ohne zu diskutieren, schafft Fakten und genau das ist nicht erwünscht. Nach dem Revert kann man gerne diskutieren, wenn man daran interessiert ist.

Da du ja um Hilfe gebeten hast, würde ich Mitte nächster Woche den Import vollständig revertieren.

Vor einem Revert ist es jedoch sinnvoll, zu recherchieren, ob es ein einzelnes Benutzerkonto war oder ob mehrere Benutzerkonten an dem Import beteiligt waren, um mit einem Revert alles zu erledigen. Ich habe mir stichprobenartige eine beliebige Bushaltestelle in Nürnberg ausgesucht und festgestellt, dass der Benutzer mappedit, an dieser vor vier Monaten eine IOFPT-Nummer ergänzt hat. Wenn man mal schnell durch seine Änderungssätze stöbert, stößt man auf fragwürdige Änderungssätze wie diesen Teständerungssatz auf der Live-API (nicht der Dev-API, wo sie hingehören). Mein Bauchgefühl meint, dass da Geld im Spiel war.

Die Firma Mentz scheint nicht dahinter zu stecken, weder hinter Marsuna noch hinter mappedit, da keiner der beiden von Mentz als Mitarbeiter aufgelistet wird.

Viele Grüße

Michael

[1] Auf der Mailingliste Imports, wo Importe diskutiert werden müssen, gibt es ein paar Leute, die fast jeden Import konstruktiv-kritisch kommentieren.
[2] Du erinnerst mich an einen Import von Rolltreppen in DB-Bahnhöfen, den ich letztes Jahr revertiert habe, nachdem ich in Karlsruhe Hbf die Typenschilder aller vier Rolltreppen kontrolliert und eine Fehlerquote von 100% ermittelt hatte (an anderen Stellen gab es auch fragwürdiges Mapping).

Hi Michael,

danke für die Rückmeldung!

Der user mappedit hat auch z.B. solche Objekte in seiner Historie…

In der von mir verlinkten Fehlermeldung (http://www.openstreetmap.org/note/996361) ist auch von einem User names “Weltstaat” die Rede, der auch fragwürdige Änderungen in der Region durchgeführt hat (ein Überblick seiner Änderungen der letzten 6 Monate offenbart allerdings bisher keinerlei derartige Changesets, da kann aber der User gserb warscheinlich mehr zu sagen, da er in der Region deutlich aktiver ist als ich).

Ich werde mich aufgrund bevorstehender Klausuren leider erst Mitte nächster Woche wieder tiefer damit beschäftigen können.

Viele Grüße,

hsimpson

Zum eigentlichen Thema:

Die gemachten Änderungen in Nürnberg sind in der Form, wie sie gemacht wurden, etwas ärgerlich.

  1. Marsuna nutzt externe Daten und hat offenbar keine Ortskenntnis. Siehe http://www.openstreetmap.org/note/1119302
  2. Hilfreich wäre eine Erklärung von ihm/ihr über die Datenherkunft und deren Qualität. Leider kam bisher auf keine Anfrage eine Reaktion.
  3. Es werden Daten ergänzt, die wir einfach nicht überprüfen können (ref:IFOPT)

Andererseits
könnte diese Quelle als Hinweis auf fehlende Haltestellen dienen (siehe oben unter 1. - da fehlt möglicherweise tatsächlich eine)
Wenn Marsuna die Güte gehabt hätte, diese vermeintlich fehlenden Haltestellen einfach als Fehlerhinweis einzutragen (wie es zum Beispiel hier gemacht wurde: http://www.openstreetmap.org/note/1065654 ), hätte sich schon jemand gefunden, das zu überprüfen.

Soweit an bestehenden Haltestellen nur die IOFPT-Nummer ergänzt wurde, wie durch mappedit gemacht, dann ist das nicht so schlimm wie die Doppelung von Haltestellen durch Marsuna. Allerdings sollte so eine Datenquelle schon besser dokumentiert werden, als mit “source=Anschreiben der VAG”.

Zum Randthema:

Der andere genannte Mapper “Weltstaat” hat mir gegenüber durch PN behauptet, dass er sehr wohl vor Ort gewesen sei. Unabhängig davon, ob ich das glaube hat er zumindest nach meiner Kritik ein paar unpassende Taggingeigenheiten nachgebessert. Grauenhaft finde ich das “Fußwege und Treppen”-Ergebnis am Hauptbahnhof trotzdem :frowning:

Der Bereich ÖPNV ist jedenfalls durch die jahrelangen Tagging-Diskussionen und der Komplexität so stark in Mitleidenschaft gezogen worden, dass sich (hier) nur noch wenige darum kümmern (wollen).

Die von gsperb angesprochene (Un-)Sitte, alle Bushaltestellen als Fläche/Linie zu erfassen kommt aber nicht nur von Weltstaat. Das wurde auch früher schon von dem ein oder anderen Mapper hier so oder ähnlich gehandhabt (siehe zum Beipiel http://www.openstreetmap.org/way/129992735/history )
Mir wäre ein Punkt auch lieber, wenn es einfach nur eine Haltestelle an/auf einem Gehsteig ist. Die Diskussion mit dem entsprechenden Kollegen habe ich aber bereits vor einigen Jahren aufgegeben - und damit mein Engagement in Richtung ÖPNV deutlich reduziert. Ich beobachte derartige Änderungen daher nicht mehr gezielt.

Hi
Derzeit läuft ein bundesweites Projekt die öffentlichen Nahverkehre zu vernetzen. Dazu ist es notwendig alle Haltestellen, also auch Bahn und Flughäfen gleichartig in einer Datenbank zu erfassen. Ziel ist es durchgehende Verbindungen aufzeigen zu können/zu vernetzen.
Es ist dies ein Projekt der DB.
Beauftragt mit der Datenerfassung nach Meldungen der diversen Verkehrsbetriebe ist in Bayern die Fa Mentz.
Die Verkehrsbetriebe melden -unter Anderem- Daten der Haltestellen mit Koordinaten, eindeutiger Nummer nach IFOPT-Standard, Bezeichnungen, Angaben zu Wartehäuschen, tactile_paving, etc.
Aufgefallen sind mir als erstes diverse “highway=platform” in der Umgebung von DB-Haltestellen und, damit verbunden, gekillte “highway=bus_stop”. Erkannt hab’ ich das weil auf einmal die “blauen Haltestellen” verschwunden waren. Kurz vorher hatte ich praktisch den gesamten Busverkehr für Fürth und Erlangen überarbeitet.

Derzeit verwendet nicht nur die VAG Nürnberg, sondern der VGN ein mir unbekanntes Kartensystem zur Visualisierung ihrer Linien und Haltestellen. Die darstellung darin ist fehlerhaft (es gibt z.B. Haltestellen bei denen Busse an einer Ecke nach rechts abbiegen müssten um zu einer 20 m entfernten HST zu gelangen und danach wenden um ihrer Linie zu folgen. Lösung: Die Bushaltestelle liegt vor der Kreuzung und nicht rechts “hinter” ihr und der Bus biegt nicht rechts sondern links ab.
Wenn diese (vermeintliche) Haltestelle tatsächlich so erfasst ist und automatisch importiert werden würde, dann entstünde eine HST “aus dem Nichts”. An dieser Stelle besteht allerdings kein Kartenfehler (für die Ortskundigen: Nbg, “Langer Steig”, Ecke Kilian/Rollner, stadtauswärts.
Ein derartiger Mangel -zumindest in der derzeitigen Darstellung- ist kein Einzelfall. Alle mir auffälligen Dinge habe ich der VAG Nürnberg gemailt aber keine Antwort erhalten. Die INFRA Fürth (Verkehrsbetriebe) bedankte sich und korrigierte. Einzelne Mitglieder des VGN reagieren also unterschiedlich.

Zum Thema “Auftrag von der VAG” habe ich Marsuna geschrieben
Zitat:
Zuständigkeit
So Du von der VAG beauftragt bist irgendetwas zu tun, hast Du mit denen
ein Vertragsverhältnis. Es muss festgelegt sein wer, was, wo und wie
tut. Wenn Dich die VAG beauftragt etwas in OSM einzugeben so hat sie
auch zu klären in welcher Form das geschehen darf und welche Regeln von
OSM zu beachten sind.
Wenn niemand der VAG bei OSM registriert ist woher weiss er dann welche
Details zu beachten sind?
Sollte die VAG beraten worden sein ihre Daten in OSM darzustellen und
sie haben den Auftrag dementsprechend vergeben, so hat eben der Berater
diesen Job zu übernehmen.
Zitatende

Ganz allgemein denke ich, dass z.B. IFOPT-Daten niemandem schaden, wenngleich ich den Nutzen für OSM noch nicht erkennen kann. Nachdem ich nur eine Datenbank kenne in der sie abgelegt sind und darauf kein öffentlicher Zugriff besteht können wir die Richtigkeit nicht prüfen.

Auch zum Copyright habe ich gegenüber Marsuna meine Meinung geäussert
Zitat:
Natürlich hat niemand etwas dagegen wenn Haltestellen um irgendwelche
Attribute angereichert werden.
Auch die Frage „woher hat er die Daten, darf er die verwenden“ lässt
sich einfach klären. „Ich hab‘ die Daten als File vom Copyrightinhaber
…, und ich darf sie (auch automatisiert) verwenden“ wäre in meinen Augen
ausreichend. Klagen könnte ohnehin nur der Copyrightinhaber.
Eine Vereinbarung wie für die Hintergrundbilder von BING ist in meinen
Augen nicht notwendig weil ja niemand ausser „Dir“ auf die betreffenden
Files zugreifen kann. Sie sind somit nicht öffentlich. Dass die Daten
dann in OSM auftauchen ist, -wieder in meinen Augen- auch kein Problem.
Der Copyrightinhaber macht sie, die Daten (nicht das File!) öffentlich.
Zitatende

Hingewiesen habe ich auch darauf, dass ich nicht für OSM spreche und auch nicht weiss welche Bedingungen für einen Datenimport bestehen.
Wie Pyram und hsimpson bereits schrieben sind -in diesem Zusammenhang- auch mir marsuna, weltstaat und mappedit bekannt.
Einträge der IFOPTnummer könnten ganz einfach deshalb ein Charakteristikum für ein zentral gesteuertes Handeln sein, weil der Zugriff darauf nicht ohne Weiteres möglich ist.
gerd

Wäre das vielleicht auch einfach mal ein Fall für eine Sperre, damit man die genannten Mapper einfach mal dazu “zwingt” sich entsprechend zu “äußern”?

Eine Sperre halte ich nur für angemessen, wenn Marsuna und mappedit fortfahren (und uns ignorieren) oder durch ihre Aktivitäten in OSM einen laufenden Revert behindern.

:frowning:

Neue Vermutung meinerseits:

Nach information des Users Marsuna sind die Daten für folgendes Projekt gedacht: http://infoportal.vag.de/InfoPortal/

Dort steht im Copyright folgende Firma.

Die initialien dieser Firma (Map And Route) finden sich auch als erste drei Buchstaben im Username MARsuna. Ich denke, der Fall dürfte hier klar sein, dass es sich hierbei um einen Kommerziellen User handelt.

Nebenbei, wir stehen auf der Wesite der VAG nur als ©OSM drin, ohne Hyperlink. Ist das so zulässig nach unserer Datenschutzrichtlinie?

Grüße

Die VAG sucht schon seit laengerem jemanden, der fuer sie die Buslinien pflegt - siehe u.a. https://forum.openstreetmap.org/viewtopic.php?id=55266 aus dem letzten Jahr. Ich hatte mit denen zu dem Thema auch schon gemailt. Irgendwann in grauer Vorzeit hatten sie wohl mal ne Praktikantin die das konnte und bei Bedarf gemacht hat, aber die ist schon laenger nicht mehr da. Vermutlich haben sie fuer die Arbeit jetzt jemand anderen gefunden/beauftragt - der das leider alles andere als gelungen umgesetzt hat.

(Edit: falscher Link)

Aus Sicht der Firma Mentz: Wir waren es in der Tat nicht.

Zu den Details: Die Berliner Kollegen wissen von nichts, hätten ihre bekannten und benannten Acctouns benutzt. Und ich glaube, da hat auch jeder ausreichend Erfahrung, dass die oben geschilderten Editierungen den Charakter eines Imports hat. Mit der VAG gibt es zwar geschäftliche Beziehungen. Aber soweit ich weiß, ist da nichts zum Thema OSM beauftragt.

Zur der “ÖPNV-Datenbank”: es gibt DEFAS, das bayernweit Daten sammelt. Der Eindruck einer Auskunft aus einem Guss ist zwar natürlich angestrebt, aber tatsächlich werden da im Hintergrund mehrere Systeme zusammengeschaltet. Das kann auch gar nicht anders gehen, weil sich zurecht kein Verkehrsunternehmen vorschreiben lassen möchte, in welchem System es seine betrieblichen Daten vorhält. Den gleichen Eindruck strebt auch die deutschlandweite Auskunft DELFI und mit einem eigenen System die DB an, dann für alles in Deutschland und die Bahn in großen Teilen Europas.

Die IFOPT-Nummer soll da den Datenaustausch vereinfachen. Sie besteht aus dem Länderkürzel, der Gemeindekennziffer, der Nummer der Haltestelle, dem Bereich und dem Steig. Länderkürzel und Gemeindekennziffer sind durchaus aus anderen Daten in OSM nachvollziehbar, der Steig steht normalerweise am Haltestellenmast oder Wartehäuschen dran. Es bleiben die Haltestellen-Nummer und die Nummer des Bereichs, sofern zutreffend. Da sind die Gewohnheiten regional verschieden (beim VRR findet man die Angaben an der Haltestelle), und ich weiß nicht, ob die Angaben in Nürnberg immer, manchmal oder nie ausgeschrieben sind.

Alles das betrifft aber keine expliziten Geodaten. Die VU haben jenseits des Fahrplans noch Koordinaten pro Steig (also pro Haltestellenmast). Der Abgleich mit den Geodaten des VU findet also darüber statt, dass man die Koordinaten des VU zum Steig im Straßen- bzw. Schiennetz von OSM aufschnappen lässt, um dann Fußgänger-Routing betreiben zu können oder Fahrwege darzustellen. Es wird also normalerweise das Wegenetz aus OSM genutzt, aber nicht die Haltestellen-Positionen und gar nicht die Routen-Relationen.

Zur Daten-Modellierung: das Problem ist eine große Menge widersprüchlicher Informationen im Wiki. Je nach mentaler Herkunft der Mapper fühlen sich die Leute dann von unterschiedlichen Wiki-Seiten bestätigt. Wollte man dies lösen, so müsste man ein Wiki-Proposal (ja, im Wiki) machen, dessen Ziel es ist, widersprüchliche Informationen zu beseitigen. Mengenmäßig hat sich für einfache Bushaltestellen die Node neben dem Weg durchgesetzt, bei Busbahnhöfen dagegen die Bussteige. Ich persönlich würde immer dann zu Bussteigen wechseln, wenn die Fußwege-Führung komplizierter ist, als dass der Bus am (ggf. erhöhten) Bordstein hält.

Wenn wir als Firma Mentz mappen, ist das meistens in solchen Situationen, da bei uns das Ziel meistens korrektes Fußwege-Routing ist. Wie gesagt, hier in Nürnberg sind wir es nach bestem Wissen und Gewissen nicht gewesen.

Hallo Firma Mentz, danke für die Antwort!

Das Problem mit den Verschiedenen Mappingarten im PT-Mapping sehe ich auch. Hiermit haben auch schon andere Probleme bekommen: https://forum.openstreetmap.org/viewtopic.php?pid=660360#p660360 (da hat jemand sowohl nen Way, als auch ne Node für jede Haltestelle eingetragen).

Wenn das Thema mal vernünftig angegangen werden soll, würde ich das sehr unterstützen!

Übrigens, bei den Bushaltestellen gab es hier im Forum vor einiger Zeit mal eine längere Diskussion, bei der am Ende als Konsens herausgekommen ist, dass nur dann eigene Platform-Ways angelegt werden, wenn sich die Haltestelle nciht im Verlauf eines Bürgersteigs befindet, also z.B. in einem Busbahnhof. In der Folge haben wir auch an vielen Fällen das Tagging verändert.

Die VAG scheint hier aber auch generell einen anderen Ansatz zu fahren als ihr, da sie die Daten zusätzlich graphisch für ihren Online-Auftritt auswerten will (sowas in die Richtung macht ihr ja m.W. z.B. auch für das Rendering der Düsseldorfer Netzpläne). Dafür braucht sie u.A. den korrekten Linienweg, um die Livekoordinaten der Fahrzeuge an selbigen zu koppeln. Da ist es am einfachsten, wenn man alle Daten aus derselben Quelle zieht. Allerdings kann ich mir es auch hier nicht erklären, warum man seit Jahren ungenutzte Bedarfspunkte für Haltestellen mit im Ensystem haben will, welches der Kunde dann zu sehen bekommt…

Eins noch zu den IFOPT-Nummern: Generell finde ich es gut, wenn man das Nummernschema vereinheitlicht! Allerdings würde ich mich freuen, wenn es dazu eine Wiki-Seite geben würde, die das ganze anschaulich erklärt, insbesondere, wie man sich diese Nummern herleiten kann. In Köln gibt es z.B. aus einem alten Datenimport an vielen Stellen noch VRS-Referenznummern, die keiner mehr nachvollziehen oder korrigieren kann. Auch eine Kontaktaufnahme mit der KVB diesbezüglich ist m.W. leider gescheitert. Das führt nun dazu, dass haufenweise unnützer refs runfliegen, von denen keiner weiß, wozu die überhaupt gut sind oder ob man die nicht lieber entfernen sollte.

Viele Grüße

Hi
OK, die Aussage ist eindeutig, die Fa. Mentz ist offenbar unbeteiligt, Es tut mir leid wenn/weil ich in diese Richtung dachte.

Im Netz gibt es viel Gelaber und hochgeistige Ergüsse über IFOPT aber eine eindeutige “Zeichenerklärung” (Datensatzbeschreibung) habe ich nicht gefunden.
Da passt die obige Aussage von drolbr_mdv ganz gut und erklärt auch weshalb wir IFOPT nur ansatzweise nachvollziehen können
ZITAT ANFANG
Die IFOPT-Nummer soll da den Datenaustausch vereinfachen. Sie besteht aus dem Länderkürzel, der Gemeindekennziffer, der Nummer der Haltestelle, dem Bereich und dem Steig. Länderkürzel und Gemeindekennziffer sind durchaus aus anderen Daten in OSM nachvollziehbar, der Steig steht normalerweise am Haltestellenmast oder Wartehäuschen dran. Es bleiben die Haltestellen-Nummer und die Nummer des Bereichs, sofern zutreffend. Da sind die Gewohnheiten regional verschieden (beim VRR findet man die Angaben an der Haltestelle), und ich weiß nicht, ob die Angaben in Nürnberg immer, manchmal oder nie ausgeschrieben sind.

Alles das betrifft aber keine expliziten Geodaten. Die VU haben jenseits des Fahrplans noch Koordinaten pro Steig (also pro Haltestellenmast).
ZITAT ENDE

Die allgemeinen Teile der Nummer sind nachvollziehbar aber die HST- + Bereichs-Nr werden vom VU vergeben und da kann man höchstens den HST Mast betrachten (auf/an dem -zumindest in FÜ- nichts steht). Also kann/muss man dem wissenden Eintragenden glauben oder auf diese Daten verzichten. Illusion ist es wohl, alle VU dazu bringen zu wollen, ihre Daten irgendwo öffentlich zu machen.

Ein Bisschen etwas zu DEFAS ist hier zu lesen
http://plan-mobil.de/wordpress/wp-content/uploads/Anlage_5_1_VGN_Vorgaben_Fahrplandaten_DEFAS.pdf
gerd

Jetzt stellt sich mir aber folgende Frage:

Wenn die IFOTP-Nummern einheitlich sind, um aus diesen eine globale Fahrplandatenlösung zu generieren, gibt es dann nicht auch irgendwo eine Datenbank mit allen IFOTP-Nummern? Ansonsten macht das ja für mich recht wenig Sinn…

Und gibt es eine Organisation, die die Vergabe koordiniert, oder hat sich da nur wen ein Schema ausgedacht, was von jedem nach belieben verdreht werden kann?

Das wären Ansatzpunkte, mit denen man das Problem global (und damit eben nicht lokal) lösen könnte, indem man einen Ansprechpartner sucht, der auf alle IFOTP-Daten zugreifen kann und evtl bereit wäre, diese öffentlich (vom mir aus auch im Rahmen einer Sonderlizenz für OSM) zugänglich zu machen. Das wäre ja nur folgerichtig, wenn man bedenkt, dass diese Daten im Moment eh massenweise in die OSM-Datenbank eingepflegt werden.

Nebenebei führt eine solche Nutzbarmachung der Daten auch dazu, dass sich mehr Mapper an der Qualitätskontrolle beteiligen können, was ja auch für Firmen wie Mentz nicht uninteressant sein kann. Der Grund für die Nutzung von OSM durch die Verkehrsunternehmen und Firmen wie Mentz ist ja grade, dass durch die Zusammenarbeit vieler die Datenqualität in vielen Bereichen deutlich über der der kommerziellen Konkurrenz liegt.

Grüße

Die IFOPT Nummer ist für NRW in http://wiki.openstreetmap.org/wiki/VRR_Tagging#Stop_Area (letzte Zeile key , vor Rollenangaben)
zum wiki verlingt und als Liste und Abfrageprogramm (für NRW) angegeben.

Ab Haltestellennummer werden die Angaben vom operator (meist Stadtwerke Verkehrsbetrieb) festgelegt und beim network (meist Verkehrsverbund , bei uns VRR) gesammelt, gelistet und veröffentlicht.

Das Schema ist wie im wiki beschrieben eine Europäische Norm.

Gruß
Axel

Wenn man vor Ort schaut muss man aber aufpassen, die normale Steigreferenz ist nicht direkt die Angabe die ans Ende der IFOPT kommt (beispielsweise bei Hagen Stadtmitte: Steig 2b hat …:2b, Steig 2a hat …:2b, Steig 3b hat …:3b, jedoch hat Steig 3a …:3, ohne ein a am Ende), wenigstens ist im VRR vielerorts die “korrekte” Steigreferenz oben rechts am Aushangfahrplan vermerkt.

Die Bereichsreferenz ist jedoch nicht vor Ort ersichtlich , da muss man wieder raten wenn man keinen Zugriff auf die echten Daten hat (bei sowas wie Hagen Stadtmitte kann man korrekt erraten, dass 2a und 2b im Bereich 2 sind usw.; ansonsten ist es meistens bei nur einem vorhandenen Bereich der Bereich 0, wenn es DB-Zeugs gibt dann hat es oft etwas was mit 90 beginnt, aber auch diese Angaben unterscheiden sich in jeder Stadt/bei jedem Betrieb, wenn man keine weiteren Informationen hat ist es also sehr schwer die IFOPTs korrekt zu erraten und dann ist es besser diese gar nicht einzutragen).

Außerdem gut zu erwähnen: Auch andere Dinge, z.B. Unterführungen, Parkplätze, Zugänge, Pausenplätze können vereinzelt IFOPT-Referenzen haben. Diese findet man aber wahrscheinlich gar nicht vor Ort, nur in Haltestellenkatastern oderso.

Ich denke nicht, dass die Vergabe im Großen und Ganzen gesehen koordiniert wird. Der Anfang ist ja einfach, Land und Gemeinde sind klar zu sehen (theoretisch. es gibt auch Ausnahmen, z.B. liegt Kalthausen geografisch in Hagen aber es lautet beim VER/VRR weil es nur von der VER-571 angefahren wird “Breckerfeld Kalthausen” und hat de:5954 in der IFOPT) und der Rest wird, so meine Vermutung als Außenstehender, lokal im Verkehrsverbund o. ä. festgelegt (beispielsweise sind VRR-weit die stopid-Intervalle festgelegt, die Hagener Straßenbahn hat alle mit 2xxx, der VER hat alle mit 8xxx undso) und so werden Konflikte vermieden.

Danke für die Antworten, vor allem Axel für den Verweis aufs Wiki. Die Liste vom VRS werde ich bei Gelegenheit mal anfragen und unter den Kölner Mappern verteilen. Die VRS:ref dürfte dann veraltet sein (abgesehen davon, dass die Syntax nicht Regelkonform ist).

Frage an Michael: Wäre das dann als Import zu werten und wenn ja, wie muss ich das dann angehen? Oder kann man das als Teilimport des VRR betrachten?

Noch eine Frage: Baut ihr die IFOTP nicht bei stop_area_groups ein? Das würde sich doch anbieten, da das ja im Endeffekt genau die Haltestellennummer wiederspiegelt. Und bezieht sich die Bereichtsnummer immer auf das dort verkehrende Verkehrsmittel oder kann das auch Haltestellenregionen kennzeichen (Z.B. in Haltestelle XPlatz Nord und Süd oder Bahnhof und Bahnhofsvorplatz)? Und gibt’s die nur für den städtischen ÖPNV oder auch für die Eisenbahn?

Grüße

Anmerkung an die Moderatoren: Die Diskussion entfernt sich inzwischen deutlich vom ursprünglichen Thema. Wäre es möglich, den Teil zu IFOTP (so ab #13) in einen neuen Thread auszugliedern? Danke schonmal :slight_smile:

stop_area_groups sind eigentlich nicht mehr gewünsch, jedoch manchmal notwendig. Deshalb werden sie möglichst spartanisch ausgestattet.

Die Kölner Mapper sind eigentlich schon groß und können da selber rein schauen. Eine massenhafte Übernahme ist problematisch, man muss schon etwas Ortskenntnis haben, um die Bereichszuordnung der Verkehrsbetriebe zu verstehen. Zur Übernahme sind auch nur die Refenznummern interessant, die geometrische Lage im EFA-System ist deutlich schlechter als unsere Angaben. Die Steige liegen nur tendenziell bezogen auf den EFA-Mittelpunkt in der richtigen Richtung.

Gruß Axel

Bin selber ein großer kölner Mapper :wink:

Spaß beiseite, ich bin halt nunmal im kölner ÖPNV recht aktiv und hab vor allem nen groben Überblick über die anderen ÖPNV-Mapper im VRS. Mit denen werde ich mich dann absprechen, wie man das angeht.

In dem Zuge sollte dann eh die VRS-Wiki Seite überarbeitet werden und das ist eh auch schon ein größeres Thema, weil da zum Thema Tagging noch sehr wenig drin steht.

Grüße

Hallo,

der Benutzer mappedit hat heute auf meinen Änderungssatzkommentar reagiert.

Viele Grüße

Michael

PS Ein Ausgliedern von Beiträgen in einen separaten Thread ist in diesem Forum praktisch nicht möglich (geht theoretisch, hat aber Nebenwirkungen).