Hallo wsoroe!

Welcher Wert war denn ungültig?

Wieso war er ungültig?

Und wieso reicht ein ungültiger Wert aus ein ganzes Element zu löschen, obwohl an einem Kommentar sehr eindeutig zu erkennen war, dass das Element sehr gezielt angelegt wurde?

Das geplante Endergebnis der Bemühungen (ist noch nicht fertig) kann man übrigens hier betrachten:

http://umap.openstreetmap.fr/de/map/leitpunkte_209665

Und da fehlen eben jetzt ein paar Werte.

Schö
Adjuva

Hallo Michael!

Was war denn an dem Tagging so schlimm, dass

1. das Multipolygon für den Bahnsteig gelöscht

2. die Tags public_transport=platform und name=Kaub an der Bahnsteigkante

gelöscht werden mussten?

Ich denke, dass sich langfristig alle Bahnsteige zu Multipolygonen mit Bahnteigkanten railway=platform_edge entwickeln werden und deswegen würde ich das hier gern beispielhaft mal grundsätzlich diskutieren.

Ich korrigiere recht viele Bahnsteigkanten (meist weil meine Route-Relationen-Prüf-Skripte Fehlermeldungen werfen) und setze dann immer die fünf Tags railway=platform_edge, name=Abc, ref=XY, train=yes, public_transport=platform.

zu 1. Im WIki hast Du einen Artikel Tag:railway=platform_edge angelegt und keines der dortigen Beispiele verzichtet auf ein Multipolygon. Und wenn in Zukunft jemand den Treppenaufgang mit einem inner-Way besser modellieren möchte ode jemand (wie in Mannheim Hbf) alle Säulen und Bahnsteigmöbel aus der Fläche herausnehmen will, dann wird er das Multipolygon wieder einführen.

Ich finde die aktuelle Modellierung unpraktisch, weil es jetzt viel schwieriger wird, von der Bahnsteigkarte zur Stop-Area-Relation (und dann weiter zum Betriebsstellen-Node) zu kommen. Um mit z.B. der Overpass-API vom Way Bahnsteigkante zum Bahnsteig-Multipolygon (das in der Stop-Area ist) zu kommen war vorher ein einfaches rel(bw) ausreichend. Jetzt muss man den Umweg über die gemeinsamen Nodes der Bahnsteigkante und des Bahnsteigs gehen.

2. Ich halte es für sinnvoll, in die PT2-Routen-Relationen nur noch die Ways der Bahnsteigkanten und nicht mehr die Relations der Bahnsteig-Multipolygone einzutragen. Und public_transpoprt=platform markiert eben aus meiner SIcht genau die Objekte, die man potentiell mit der Rolle 'platform' in eine Route-Relation (die Bahnsteigkante oder den ganzen Bahnsteig) oder in eine Stop-Area-Relation (der ganze Bahnsteig) einträgt. Deswegen ist das Löschen des public_transport-Tags kontraproduktiv.

In den Route-Relationen möchte man ganz gerne sehen, welche Objekte man da mit den Rollen 'stop' und 'platform' eingetragen hat, damit man die korrekte Reihenfolge der Halte kontrollieren kann. Deswegen mappt man entweder name=Abc, (local_)ref=XY oder description 'Abc, Gleis XY' (ich zumindestens habe JOSM-Styles, die name und ref in der Relationsliste und im Auswahl-Fenster anzeigen). Das name-Tag ist dabei eigentlich unschön, weil es bei Flächen vom OSM-Standard-Style gerendert wird. Wenn man nun die Bahnsteigkante in die Route-Relation aufnimmt, dann ist das nie gerendert und man kann guten Gewissens das Name-Tag benutzen. Es besteht außerdem auch keine Notwendigkeit local_ref statt ref zu benutzen (ref braucht man manchmal (siehe Mannheim Hbf) für Ids, die keine Gleisnummern sind). Und deswegen ist das Löschen des name-Tags ebenfalls kontraproduktiv.

Schö
Adjuva

Hallo NotfallWestfale!

Gibt es einen Grund, warum Du die beiden Bahnhofs-Knoten (1981218131 und 266600397) gelöscht hast?

Ich halte das für eine ziemlich engstirnige Interpretation der allgemeinen Regel. Im Gegensatz zu Straßennamen oder Namen von Personenbahnhöfen (wo jeder die Abkürzungen kennt) geht es hier um Betriebsstellen, die nur bahnintern interessant sind und wo eben diese bahnspezifischen Abkürzungen benutzt werden. Vom Ausschreiben der Abkürzungen hat hier niemand was.

Du kannst aber gerne das 'name' zu 'official_name' ändern und nach Belieben ein erfundenes 'name' hinzufügen.

Vorher solltest Du allerdings noch 74 Bahnhofsknoten und 4 Haltestellenknoten mit 'Hbf' im Namen korrigieren.

Name und Kürzel stam,men aus der Ds100 (Direktion 'i').

Die Position erhält man, indem man in Luftbildern nach den großen beleuchteten El1 und El2 sucht und sich dann überlegt, welcher Eintrag der DS100 zu dieser Position passen könnte.

Hallo Frederik!

Die Bahnsteig-Multipolygone in Luisental und Bous (relation/1620893 und relation/1620862) waren aus meiner Sicht nicht überflüssig. Sie entsprachen einem im Wiki dokumentiertem Tagging-Schema (railway=platform_edge, den Benutzer Nakaner kennst Du vielleicht sogar).

Erst durch das Multipolygon gehören Bahnsteigfläche und Bahnsteigkante wirklich zusammen und man kann (z.B. per Overpass-API) auch von der Kante sofort den dazugehörenden Bahnsteig bestimmen. Und umgekehrt: Wenn man den Bahnsteig als Multipolygon-Objekt lädt wird automatisch auch die Kante mitgeladen.

Und die Bahnsteig-Relation aus der stop_area-Relation zu löschen und den neuen Way nicht hinzuzufügen ist auch nicht gerade nett.

Schö
Adjuva

Ab 2017-08-24 wird der Zug wieder fahren: Gleiche Wagen, gleicher Name, gleiches Kürzel, gleiche Zugnummern, gleicher Fahrplan, gleiches EVU - nur der Betreiber hat sich geändert: Leo Express und Flixbus statt Locomore GmbH. Ich habe mir erlaubt die Relationen wiederherzustellen und anzupassen.

Hallo!

Ich habe ich changeset/49013237 das nördliche Ende von way/495908333 (Gleiswechsen W165 - W166) um zwei Nodes nach Norden verschoben auf den bereits vorhanden Node für W166. Könntest Du anhand Deiner Unterlagen prüfen, ob das ok ist (insbesondere wegen des Sperrsignals).

Adjuva

Gibt es einen besonderen Grund, dass Du den Bahnhofs-Knoten des Haltepunkts Zerkall an der Rurtalbahn gelöscht hast?

Der Bahhofsname wird dadurch auf vielen Karte nicht mehr gerendert.

Hallo!

1.
Für weitete (spätere) Mitleser hättest Du kurz erwähnen können, dass es u.A. um Düsseldorf Hbf geht,

2.
Die OpenRailwayMap sieht vor, dass Betriebsstellen immer als Node gemappt werden (siehe osm.wiki/OpenRailwayMap/Tagging#Stations_.2F_Stops ff.).

Und wenn die Betriebsstellen Persohnenverkehr hat wird zusätzlich ein public_transport=station gesetzt. Der Node wird auch mit leerer Rolle in die Betriebsstellen-Relation aufgenommen (siehe osm.wiki/OpenRailwayMap/Tagging#Operating_Site_.28Relation.29), die in diesem Fall quasi identisch zur Stop-Area-Relation ist.

Eine Fläche kann man mit landuse=railway taggen und dann mit der Rolle 'landuse' in die Betriebsstellen-Relation aufnehmen.

3.
Bei der OpenRailwayMap gab es Diskussionen, dass eine Fläche public_transport=station meist kaum was anderes als eine kovexe Hülle um Bahnsteige und Bahnhofsgebäude ist, die man auch leicht selbst berechnen kann. Bei Düsseldorf Hbf ist das auch so.

4.
Der Betriebsstellen-Node in der Stop-Area-Relation ermöglicht leichten Zugriff auf Daten, die nicht direkt an der Stop-Position oder Platform einer Route-Relation eingetragen sind (z.B. uic_ref, railway:ref, railway:station_category). Ich habe Anwendungen, die das benötigen und deswegen prüfe ich diese Strukturen automatisch.

5.
Das Tag public_transport=station auf dem Betriebsstellen-Node ist mir eigentlich ziemlich egal (JOSM zeigt ein hässlicheres Icon, wenn es fehlt) - mir ist es wichtig, dass der Node in der Betriebsstellen-Node bleibt.

6.
Was ist schlimm daran, wenn es Node und Fläche gleichzeitig gibt? Solange der Node in der Fläche liegt.

Hallo CarstenG!

Vor diesem Edit hatten alle RE/RB/S in NRW das network-Tag 'NRW Regionalverkehr'.

Wenn Du Dein eigenes network-Tag haben möchtest, dann füg es bitte mit Semikolon hinten an und erhalte die vorhandenen Werte!

Hallo!

Gibt es einen besonderen Grund, warum Du die stop_area-Relation 6354559 des Hauptbahnhofs gelöscht hast?

Hallo WMWDe!

Was war denn Idee dahinter, diesen Umriss des Unterwerks Uelzen in zwei Wege aufzuteilen? Hätte man dann nicht aus dem Unterwerk eine Relation machen müssen?

Hallo plettman!

Ein Hydrant (node/2501761978) sitzt auf der Begrenzung (dem Zaun) des Bahn-Unterwerks. Ich glaube nicht, dass der da hingehört. Du hattest ich zuletzt verschoben.

Könntest Du ihn bitte aus dem Zaun lösen und an die richtige Stelle rücken.

Schö
Adjuva

Diese Wege gibt es nicht. Dein Südlicher Weg verbindet eine Brücke direkt mit dem darunter liegendem Weg - das ist sinnlos. Der Radweg (eigentlich ist es ein Wirtschaftsweg) unter der Brücke wird östlich auf Höhe der Brückenstraße mit der Frankfurter Straße verbunden. Ich werde die Wege demnächst löschen.

Hallo esperanto!

Wenn Dir das network 'DB InterCityExpress' im route_master von ICE10 oder ICE11 nicht gefällt, dann darfst Du gerne Dein 'DB' durch ein Semikolon getrennt dazu schreiben. Aber respektiere bitte die vorhandenen network-Tags anderer Mapper.

Schö
Adjuva

Hallo Net-net!

Danke für die Korrektur!

Hallo Net-net!

Du hast (fast vollständig) die Nummern der Bahnsteige ausgetauscht? Auf welcher Grundlage? Ein source-Tag fehlt leider.

In diesem Dokument http://www.eba.bund.de/SharedDocs/Publikationen/DE/PF/Beschluesse/Bayern/51_Umbau_Bahnhof_Hammerau.pdf?__blob=publicationFile&v=2 steht, dass Gleis 501 der Hausbahnsteig ist und Gleis 502 einen neuen Außenbahnsteig bekommen soll. In diesem Video https://youtu.be/-Sci_eEvfy8?t=212 sieht man die Signale Richtung Freilassing und es bestätigt, dass der Hausbahnsteig an Gleis 501 liegt. Ebenso bestätigt Stredax die Signalbezeichnungen. Fotos und Videos der Bahnsteignummern habe ich leider nicht gefunden.

Nun ist es bei der Deutschen Bahn eben sehr unwahrscheinlich, dass der Bahnsteig an Gleis 501 '2' heißt und an Gleis 502 der Bahnsteig 1 ist.

Schö
Adjuva

Meine Änderungen sind vollkommen ok - ich habe nur Lücken in Relationen gefüllt. Allerdings ist mir dabei aufgefallen, dass ich ständig die gleichen Lücken fülle (schau mal in die Relationen 1788865, 5149131, 3310117 oder 2178679 - die sind absolut identisch zu Deiner Relation). Schuld scheint der changeset/37939761 zu sein. Acht dort zerstöre Relationen habe ich schon am Mittwoch korrigiert (changeset/38513957) - die andern fünf habe ich mir für heute vorgenommen.

Ich kann nicht erkennen, wo ich gegen die Policy verstoßen haben soll. Konkrete Beispiele bitte.

Ich habe keine der vier unter 'Scope' genannten Techniken angewandt. Ich habe jede Änderung individuell betrachtet.

Der deutlich überwiegende Teil des Changeset sind neu erfasste Objekte oder Verbesserungen des Vorhandenen. Ihn kommentarlos rückgängig zu machen halte ich deswegen für vollkommen unverhältnismäßig.