Hilfe benötigt wegen auffälligem Datenimport

hsimpson · 2017-09-11T17:25:43.000Z

Bin selber ein großer kölner Mapper

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

Nakaner · 2017-09-11T18:42:51.000Z

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).

hsimpson · 2017-09-11T22:48:23.000Z

@Michael, danke für das anschreiben!

@Axel: Ich wollte das grade nochmal konkretisieren, weil ich eben wenig Zeit hatte:

Ich hatte in letzter Zeit häufiger Diskussionen mit Mappern im Köln/Bonner Raum, weil wir eigentlich die VRS:ref gerne flegen würden, aber man nirgendwo an die Daten ran kam und diejenigen, die damals den Import durchgeführt haben, heute im Wesentlcihen nicht mehr aktiv sind.

Das ganze hat immer ein wenig ratlos geendet. Von daher denke ich, dass einem Wechsel auf die IFOTP-Daten aus der Sicht eigentlich nichts im Weg stehen dürfte.

Die Wiki-Seite zum VRS hätte ohnehin eine Überarbeitung nötig, da kann man einen solchen Import dann direkt vernünftig einbauen. Ich denke, bei dem Thema kann man sich auch gut an eurer Vorarbeit im VRR orientieren.

In dem Zug könnte man auch überlegen, die Stadtbahnlinien auf route=light_rail umzustellen, das ist auch eigentlich schon seit der Überarbeitung des Kölner Stadtbahnnetzes mein Anliegen, aber damals gab es noch vereinzelt S-Bahn-Linien mit dem Tag.

Wenn das ganze konkret wird, werde ich auch auf jeden Fall nochmal auf die VRR-Comunity zukommen, dass man sich über das Vorgehen abstimmen kann. Ein einheitliches Vorgehen für ganz NRW wäre da auf jeden Fall mein Anliegen, und ihr seid da schon deutlich weiter als wir

Dazu kommt die Tatsache, dass auch die KVB offensichtlich inzwischen Interesse an OSM bekommen hat und mommentan viele Kölner U-Bahnhöfe besichtigt und überarbeitet. Ich denke, mit denen lässt sich auch eine vernünftige Zusammenarbeit bewerkstelligen.

Viele Grüße,

hsimpson

Edit: Ein solche Vorgehen hätte auch den Vorteil, dass man es potentiell interessierten Unternehmen einfacher macht, sich mit der Community abzustimmen. Wenn die Richtlinien klar umrissen, das Vorgehen dokumentiert und die Ansprechpartner bekannt sind könnte man sicher den ein oder anderen Alleingang abwenden.

drolbr_mdv · 2017-09-12T06:25:18.000Z

Hallo zusammen,

danke für die konstruktive Rückmeldung. Ein paar kleine Nachträge würde ich gerne noch machen.

Das Nummernschema heißen IFOPT (nicht IFOTP). Denkt bitte an Leser, die das in eine Suchmaschine stecken wollen. Mehr Aufmerksamkeit würde ich dem auch eigentlich nicht widmen wollen. In den innerbetrieblichen Systemen spielen die IFOPT-Nummern eine relativ kleine Rolle. Denkt bitte an Konstellationen wie Köln Hbf/Breslauer Platz/Dom/Hbf (oder W Oberbarmen, F Ost, HH Hbf etc.), bei denen ein VU zwei Haltestellen (Dom, Breslauer Platz) im Umstieg zu einer Haltestelle eines anderen VU/EIU (K Hbf) hat. Daher kann die “Haltestellennummer” weder perfekt funktionieren, noch viele wesentliche Funktionen erfüllen.

Die wesentliche verbleibende Funktion ist, gewollte Umbenennungen von Varianten-Schreibweisen für Namen unterscheiden zu können. Das geht aber mit Koordinaten (Lat+Lon+manchmal Level), die wir in OSM ja haben, mindestens genauso gut. Es wird sehr selten vorkommen, dass eine Haltestelle umzieht und gleichzeitig umbenannt wird und trotzdem noch dieselbe Haltestelle ist. Umgekehrt kann eine Änderung der Gemeindegrenzen, was mehrmals pro Jahr irgendwo vorkommt, eine Änderung der IFOPT-Nummern nach sich ziehen. Der praktische Nutzen der IFOPT-Nummern aus OSM-Sicht ist also nahe null. Es gibt übrigens durchaus auf den Datendrehscheiben Reparatur-Mechanismen, bei denen die Koordinate die Ref-Nummer (IFOPT, Diva-Nummer oder andere) übersteuert; ich kenne aber die Details nicht.

Die Bereiche sind ebenfalls eine Hilfskonstruktion aus Vor-Geodaten-Zeiten. Sie dienen dazu, Orte mit äquivalenten Umteigewegen und -Zeiten zusammenzufassen. Wir wollen aber in OSM eigentlich ein Fußgänger- oder besser auch Blinden- und Rollstuhl-routbares Routingmodell. Ob die VU in zehn Jahren noch Bereiche haben, sei mal dahingestellt. Aber wir werden sicher in OSM in 10 Jahren eher bessere Routinggraphen haben. Wer Zeit übrig hat, anhand des Routinggraphen über Bereiche nachzudenken, hilft also OSM mehr, wenn er den Routinggraphen der jeweiligen Station auf Plausibilität prüft, weil dann die Bereiche die meist gut erkennbaren Gruppen sind.

Womit ich zum erwachten Interesse der KVB komme: das hängt mit dem Forschungsprojekt http://www.dimo-fuh.de zusammen. Sehr grob abgekürzt: Dort soll unter anderem die KVB in die Lage kommen, in ihren Verkehrsbauwerken Fußgängerrouting zu können. Und da ist das Vertrauen in OSM mittlerweile groß genug, dass man dann die Daten dafür in OSM modelliert und hochlädt. Wir als Firma Mentz sind dort beteiligt, aber ich weiß aus dem Stand nicht, in welchem Umfang.

Viele Grüße,

Roland

gsperb · 2017-09-14T07:31:11.000Z

Hi
Eine Haltestelle (exakt 1 IFOPT-Nr) muss erst mal überhaupt keinen Bezug zum dort stoppenden Verkehrsmittel haben. Es ist eine Einrichtung, meist am Strassenrand, mit unterschiedlicher “Ausstattung”.
Ob da dann nur ein Bus oder z.B. auch die Tram hält ist eine weitere Ausprägung die sich auch ändern kann. Theoretisch könnten auch Bus und U-Bahn an der gleichen Haltestelle stoppen (bei uns fährt die U-Bahn teilweise oberirdisch). Praktisch ist das unwahrscheinlich weil die bodennahen Stromschienen der U-Bahn sehr kritisch wären.
Dafür könnten, wieder theoretisch, bei uns Bahn und U-Bahn die gleichen Gleisanlagen nutzen. Die Spurweite und Radsätze sind geeignet. U-Bahnzüge wurden schon mit Dieselloks auf den Gleisen der DB von M nach N gezogen.
gerd

Nakaner · 2017-09-15T18:12:27.000Z

Hallo,

im Laufe des heutigen Abends werde ich folgende Änderungssätze revertieren:

alle Änderungssätze von Marsuna (User-ID 1923746) von Änderungssatz 50993299 bis 51159683 mit Ausnahme von 51020531, da sie Teil des Haltestellenimports sind
alle Änderungssätze von mappedit (User-ID 46855) von Änderungssatz 44516155 bis 49193602, da sie ein undiskutierter IFOPT-Import oder Testbearbeitungen auf der produktiven Datenbank sind

Bei Konflikten wird das Objekt nicht vom Revertskript editiert werden. Stattdessen müssen diese manuell gelöst werden.

Viele Grüße

Michael

hsimpson · 2017-09-15T18:23:22.000Z

Hi Michael,
ich hab eben gesehen, dass Gerd gestern schon zwei Haltestellen in Bruck gelöscht hat. Da der Änderungssatz sonst keine Änderungen enthält, würde ich den der Einfachheit halber direkt mit Revertieren: http://www.openstreetmap.org/changeset/52030779
Ansonsten vielen Dank für deine Hilfe!
Grüße

Nakaner · 2017-09-15T20:43:23.000Z

Hallo,

der Revert ist soeben gestartet. Änderungssatz 52030779 von gsperb habe ich mitrevertiert, um die Anzahl der Konflikte um zwei zu reduzieren.

Viele Grüße

Michael

Nakaner · 2017-09-15T22:11:47.000Z

Hallo,

der Revert war zu zaghaft. Beim Konfliktlösen fiel mir auf, dass es auch schon vor drei Monaten IFOPT-Nummerergänzungen durch Marsuna gegeben hat. Ich habe diese übersehen, weil ich mich von einem Block nicht-ÖPNV-Änderungssätze habe in die Irre führen lassen und die älteren Änderungssätze übersehen habe.

Deshalb starte ich jetzt einen zweiten Versuch, der bei Marsuna zwar ziemlich viel Kollateralschäden in ganz Deutschland anrichtet, mir aber eine halbe bis ganze Arbeitsstunde spart. Marsunas Beiträge scheinen kommerzieller Natur zu sein, da auch in vielen anderen Änderungssätzen von “Anschreiben der Stadt X” als Quelle die Rede ist. Der jeweilige Änderungssatz korrigiert dann einen Straßennamen oder macht andere kleinere Korrekturen. Mir ist bewusst, dass das hart ist, aber auch meine Zeit als Freiwilliger ist etwas wert.

Beim Sichten der Konflikte (knapp 200 Konflikte, dauerte gut eine Stunde) fiel mir noch diese Unstimmigkeit bei den IFOPT-Nummern auf: https://www.openstreetmap.org/node/355741271/history

Viele Grüße

Michael

EDIT: https://www.openstreetmap.org/changeset/34529101 Ja, Anschreiben vom Amt können unerlaubte Quellen beinhalten. Ich vermute, dass es u.U. sogar sinnvoll wäre, alle Änderungen dieses Benutzerkontos zu revertieren. Aber das mache ich nicht heute und nicht morgen und nicht ohne eine vorherige Diskussion.

Nakaner · 2017-09-15T23:28:01.000Z

Hallo,

hsimpson:

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.

Als ich das am Sonntag, als du es gepostet hattest, gelesen habe, habe ich gedacht, jetzt spinnst du. Es klang ein zu verschwörungstheoretisch. Ich habe heute noch ein bisschen durch Marsunas History gestöbert, bis mir jetzt, eine Woche später einfiel, dass ich schon einmal mit diesem Benutzer zu tun hatte. https://www.openstreetmap.org/changeset/32446351 In der Antwort (per PN) stand, dass es sich um einen Mitarbieter von Map And Route handelt.

Viele Grüße

Michael

hsimpson · 2017-09-16T12:47:53.000Z

Da hat mich meine Nase doch nicht im Stich gelassen
Grüße

hsimpson · 2017-09-16T13:08:30.000Z

Nakaner:

EDIT: https://www.openstreetmap.org/changeset/34529101 Ja, Anschreiben vom Amt können unerlaubte Quellen beinhalten. Ich vermute, dass es u.U. sogar sinnvoll wäre, alle Änderungen dieses Benutzerkontos zu revertieren. Aber das mache ich nicht heute und nicht morgen und nicht ohne eine vorherige Diskussion.

Eieieieiei, zwei Jahre keine (öffentliche) Antwort auf einen CS Kommentar und stattdessen einfach weiter machen wie gehabt?

Da fällt einem auch nichts mehr zu ein…

Ich verstehe auch nicht ganz, was sich so Unternehmen dabei denken… Man kann doch nicht einfach Daten in ein Community-Projekt einpflegen und dann davon ausgehen, dass keinerlei Fragen zur Lizenz dieser Daten gestellt werden… Da müssten doch auch bei der Rechtsabteilung irgendwann die Glocken läuten, vor allem, wenn kritische Nachfragen kommen!

Auch, dass seit der Ansage, dass man das intern klären will (vor allem intern=VAG und nicht intern=MAR), keinerlei Rückmeldung gekommen ist, finde ich auch sehr schwach… Und dass man offensichtlich nicht bereit ist, öffentlich zuzugeben, dass man zur Firma MAR gehört und stattdessen einzelne Mapper nach der privaten Mail-Adresse fragt, um einer öffentlichen Auseinandersetzung aus dem Weg zu gehen.

Also da ist einiges wirklich nicht ganz koscher bei denen…

Kopfschüttelnde Grüße

versat · 2017-09-27T18:25:55.000Z

Ich habe in den letzten Wochen / Monaten nach und nach an etlichen Haltestellen Details hinzugefügt und z.B. die Positionen korrigiert so wie sie wirklich sind.
Das scheint jetzt alles komplett weg zu sein ?.
Kann man das nicht so selektiv rückgängig machen, dass die ganzen nützlichen / korrekten Änderungen von Anderen erhalten bleiben?
Das ist wirklich ärgerlich wenn ich da von Vorne anfangen kann und irgendwie geht mir da auch die Lust am mappen etwas flöten.
Grüße
versat

milet · 2019-07-30T13:30:00.000Z

Hallo,

ich hole dieses Thema nochmal hoch, weil ich vermute, dass aktuelle Änderungen in Erlangen/Nürnberg/Bamberg durch Benutzer “KNOMA” (“Mitarbeiter Verkehrsverbund Großraum Nürnberg”) einen ähnlichen Hintergrund haben:
https://www.openstreetmap.org/user/KNOMA/history

Für mich sieht es aus, als ob da das Wissen über access und lanes fehlt.
Es soll wohl irgendeine Art von Bus-Routing erreicht werden.

Für Erlangen kann ich nach Stichprobe sagen, dass eigentlich alle Änderungen falsch sind (z.B.: reine Busspur mit blauem Schild wird zu “vehicle=yes” geändert usw.).

@pyram Ich glaube, du kennst dich in Nürnberg besser aus. Vielleicht kannst du auch mal einen Blick drauf werfen.

Aktuell würde ich sagen, müsste ziemlich viel zurückgesetzt werden.

pyram · 2019-07-30T17:27:41.000Z

@milet

In Nürnberg war nicht viel betroffen.
Ich habe mal etwas kommentiert: https://www.openstreetmap.org/changeset/72141017
und: https://www.openstreetmap.org/changeset/72266933

pyram · 2019-07-31T17:24:18.000Z

KNOMA hat sich per PN gemeldet und sein Anliegen geschildert.
Erfreulicherweise scheint es so, dass der VGN von seinem bisherigen Datenlieferanten auf OSM-Daten umsteigen soll/will. Ich werde ihn hier ins Forum einladen, damit wir das weitere Vorgehen abstimmen können.

pyram · 2019-08-07T18:00:02.000Z

KNOMA teilt per PN mit, dass der VGN sich nach der Sommerpause hier im Forum mit der Community austauschen wird und bis dahin keine weiteren unerwünschten Änderungen vornehmen wird. Der VGN wolle durchaus konstruktiv mit uns zusammenarbeiten und sie waren sich der Folgen hier nicht so bewusst (weil Anfänger).

Inwieweit wir das folgende Angebot nutzen können, kann ich derzeit nicht beurteilen:
Zitat: “Unter https://www.vgn.de/web-entwickler/open-data/ stellt der VGN GTFS-Daten zur Verfügung. Die GTFS-Daten sind nur unter den definierten Nutzungsbedingungen verfügbar. Ein anderer Nutzungsrahmen unter anderen Bedingungen ist nicht möglich. Sollten zu den GTFS-Daten Fragen offen sein, beantworten wir diese gerne unter dialog@vgn.de”
Möglicherweise kann man das aber zur Qualitätskontrolle (also nicht zur unmittelbaren Datenübername), wie bei https://forum.openstreetmap.org/viewtopic.php?pid=756941#p756941 nutzen?

geri-oc · 2019-08-07T18:11:16.000Z

pyram:

Der VGN wolle durchaus konstruktiv mit uns zusammenarbeiten …

Da sollten auch die Daten nicht das Problem sein - man kann sie für OSM sicher freigeben.
Gab es nicht einmal eine WIKI-Seite mit solchen freigaben - https://wiki.openstreetmap.org/wiki/DE:Permissions

geri-oc · 2019-10-10T18:24:41.000Z

Aus https://forum.openstreetmap.org/viewtopic.php?pid=765324#p765324 verlagert:

geri-oc:

…
Sehr schöne Modellierungsvorschläge zusammengefasst (von einem Auswerter?):
https://wiki.openstreetmap.org/wiki/MENTZ_GmbH/Modellierungsvorschl%C3%A4ge_%C3%96PNV

pyram:

OT:

geri-oc:

… (von einem Auswerter?):

Nein, von einer Firma, die bei uns in der Stadt massenhaft ohne Vor-Ort-Kenntnisse ummodelliert hat
Die pushen damit nur Ihre Vorstellung.
Ergebnis ist ein “perfekter” Bahnhof, der nur noch bedingt für Routing verwendbar ist - und ein faktisches Erliegen des ÖPNV-Mappings durch lokale Mapper: https://www.openstreetmap.org/note/1459369
Der entsprechende Mapper (offenbar aus Wien) hat mir zugesichert, dass er vor Ort (Nürnberg) gewesen sei. Das Gegenteil zu beweisen war/wäre ein Leichtes gewesen nach Vergleich vor Ort und “StreetView” (Er hatte meine liebevollen Aktualisierungen am Bahnhof und im restlichen Stadtgebiet auf einen alten Stand zurückgebaut)!

Nur als Kurzantwort:
http://85.214.126.95/OpenStationMap/OStM-overpass.html#18/49.44643/11.08196
Sie haben viel indoor beigetragen - ich kann aber keine direkten Fehler zu ÖPNV im WIKI erkennen - Beispiel https://www.openstreetmap.org/way/252661458/history#map=19/49.44496/11.08325.
oder was sind Fehler die du bemerkt hast?

pyram · 2019-10-11T18:00:10.000Z

geri-oc:

oder was sind Fehler die du bemerkt hast?

Am Bahnhof hat man das nach meiner Beschwerde nachgebessert.

Die Fehler lagen auch nicht beim funktionalen ÖPNV und auch nicht im Wiki, sondern im “restlichen Umfeld”.
“Fehler” beim ÖPNV sind aber in meinen Augen die Stummelwege auf dem Gehsteig zu den “platorm”, die praktisch nur Teil des Gehsteigs sind (Mappen für den Router + Optik)
Beispiel:
https://www.openstreetmap.org/way/438542818
bzw.
https://www.mapillary.com/app/?lat=49.43833813562799&lng=11.051411608846337&z=17&focus=photo&pKey=aaWq6MebhuNywk3xKGIm-w&x=0.4886729395181148&y=0.5950061096646759&zoom=0

Das Thema ist hier aber auch OT, weil es eigentlich um “KNOMA” geht, der offenbar immer noch “Sommerpause” hat