Moin :)
ich habe an ein paar (wenigen) Stellen gesehen, dass du aus Signalen Weichen gemacht hast beim Nachtragen von Weichen. Für Niedersachsen bin ich da schon wieder durchgegangen und hab das korrigiert (inkl einiger meiner eigenen Fehler). Aber vielleicht könntest du da ein bisschen drauf achten. (an den Stellen waren vorher Tags zum Signal inkl. railway=signal vorhanden; und nach der Bearbeitung wurde dann railway=switch draus, die railway:signal:*-Tags blieben).
Schönen Abend noch und happy tagging
Björn

Moin, ich kenn mich mit KLGV-Mapping nicht wirklich aus, aber sind das nicht eigentlich eher Parzellen oder Häuser oder was auch immer mit einer Nummer und nicht Nummern als Hauptmerkmal? Sodass dann statt nur ref=* noch Tagging für die Parzelle/Haus/was-auch-immer da ist genannt würde. Bin da nur zufällig beim Bahnmapping drauf gestoßen... Aber ja, Postadresse scheint definitiv falscher zu sein :D
Happy mapping :)

Moin, sind diese Punkte Kleingartenhäuser? Könntest du vielleicht das noch mal passend ändern? Wäre super, wird dadurch sicher verständlicher :)
Danke und schönen Abend

Moin, ist das richtig, dass das so ein perfekter Kreis des GVH-Übergangsgebiets? Mir ist das auch schon mal passiert, dass ich auf einen falschen Button gekommen bin. Leider krieg ich auf die Schnelle nicht raus, wie das eigentlich gehört. Kannst du dir das noch mal anschauen?

Moin, danke für den Hinweis. Ich hab das grade nicht mehr genau vor Augen, habs aber mal gemäß bing geändert.

Moin, schön, dass hier schon einiges an Hydranten drin steht :) Die Information unter name (also Unterflurhydrant [500]) ist allerdings unter name falsch aufgehoben und ist v.a. halt kein Name, also gern im weiteren nicht weiter so taggen, wenns geht ;)
Viele Grüße

Moin,
Sollte behoben sein, danke für den Hinweis. Was für ein nerviges "Feature"... Ein paar "operator" waren auch noch in Helmstedt falsch.
Schönen Abend noch :)
Björn

Moin, ich habe eben noch malin die Daten reingeschaut und es sieht aus, als wären die Grenzen schon großzügig... Habe erstmal die östlichen Grenzen vorläufig verkürzt auf plausiblere Werte. Da wird sich aber wohl noch was mit Eintragen der Einfahrsignale ändern (die ja die Grenze des Bf ergeben und damit die Stelle, an der die landuse enden sollen, die in die Relation kommen...). Also Danke fürs Aufmerksammachen.
Happy Mapping ;)

Moin, danke für die Nachricht. Also in kurz (und ohne noch einmal in die Daten geschaut zu haben rein aus deiner Beschreibung argumentiert) sollte es so richtig sein.
Ich beziehe mich dabei auf die Doku der OpenRailwayMap und die dortige Nutzung von Betriebsstellenrelationen bzw. der landuse, die sich auf die gesamte Betriebsstelle (hier des Bf Hameln) bezieht. Dort wurde wegen der komischen Positionierung u.a. auch das Tag railway=station gewählt, das in Hameln im Dreieck der westlichen Bahnsteige steht. Damit sollten die Daten den kompletten Bereich abdecken, das Label an der richtigen Stelle (railway=station) liegen..
osm.wiki/DE:OpenRailwayMap/Tagging#Betriebsstellenrelation
Hat sich das damit geklärt? Sonst schau ich gerne noch mal in die Daten, ob mir da irgendwas komisches auffällt. Vielleicht lässt sich an den ÖPNV-Karten anregen (feature/bug report?), dass bevorzugt der Stationspunkt (empty role der Relation) und erst sonst der Schwerpunkt der landuses genutzt wird... Worauf beziehst du dich da grade?
Viele Grüße :)

Moin :) ich habe gesehen, dass du einiges an Hektometertafeln ergänzt hast. Der Tag "distance" ist dafür aber mittlerweile nicht mehr gedacht, das wäre jetzt railway:position bzw. railway:position:exact. Hoffe das hilft für die Zukunft.

Viele Grüße!

Moin, mir ist bei diesem und einigen anderen Änderungssätzen zu Hydranten in Braunschweig aufgefallen, dass du ein name-Tag ergänzt hast, das aber nur eine Beschreibung ist, dass das ein Hydrant ist... (z.B. name="Unterflurhydrant [080]", wobei die Information auch redundant in den anderen Tags auftaucht. Der name-Tag ist eigentlich dafür gedacht, einen echten "Namen" zu vergeben (vielleicht deutlicher bei z.B. Straßen oder Brücken zu sehen name=Amselstieg statt name=Straße. Könntest du das bitte in Zukunft beim mappen berücksichtigen? Dank schonmal und viele Grüße :)

PS: Wenn du Fragen hast, kannst du dich natürlich auch gerne melden

Hallo patzi!
Ich habe gesehen, dass du viele Bahnübergänge mit den Positionen ergänzt hast (aufgefallen halt hier auf der Strecke nach Schöppenstedt). Leider ist dabei das Tagging mit "addr:housename="BÜ 16,490"" (bspw)nicht ganz korrekt, weil es ja keine Adresse und auch kein Haus beschreibt. Könntest du versuchen, das entsprechend der OpenRailwayMap zu taggen? (dafür kannst du für die Positionen nutzen: railway:position=16.4 (für eine grobe Position/Kilometrierung) bzw. railway:position:exact=16.490 (für die metergenaue Position an der Strecke. Vielen Dank aber für die ganzen Eintragungen :)
Viele Grüße
Björn

Seit kurzem gibt es noch ein Ne1, das aber in Richtung Hafen zeigt. Somit liegt die Anschlussweiche inkl. allem was drin liegt, zumindest auf der freien Strecke. Trotzdem bleibe ich dabei, dass es wahrcsheinlich sowohl Streckengleis (liegtauf der freien Strecke) als auch Anschlussgleis (da mit Gr. d. Anschl.-Bahn gekennzeichnet).

Frage wäre dann das korrekte Tagging. Ich schlage usage=industrial und service=spur als Tagging vor. Was denkt ihr dazu?

Moin Roland, ich hätte da ein paar Anhaltspunkte:
- Schilder "Grenze der Anschlussbahn" hinter der Anschlussweiche, hinter dem "Nordbahnhof" sowie am BÜ Hmb. Straße.
- Gleissperren kenne ich eigentlich nur aus Nebengleisen > Anschlussweiche + am Mittelweg
- Betriebsstelle heißt "Awanst Nordkurve"
- Dagegen spricht ggf. vor dem BÜ Bienroder Weg die Tafel "Halt für Zug- und Rangierfahrten"

Andererseits gibt es ja auch wohl nur Bahnanlagen der freien Strecke und der Bahnhöfe, demzufolge wäre es ggf. sowohl Streckengleis als auch Anschlussgleis? (das aber ggf. etwas akademische Diskussion..)

Ist dann halt so, aber dann gern auch für andere Dinge / weitere Projekte :) Es wirdja genug bei der Bahn neu zurück-/gebaut. Komisches Herumrevertieren ist für den zusätzlichen Informationsgehalt wohl etwas übertrieben.
Schönen Abend!

Moin, danke für die Info! Magst du vielleicht vor dem Löschen noch eine weitere Version mit end_date=2020-08 erstellen, dann ist das ganze Lifecycle-Leben ein wenig besser dokumentiert (und vielleicht gibt es ja irgendwann die Möglichkeit, mehr in Richtung historischer Daten zu machen).
Viele Grüße!

danke für die Mitteilung. Ich habe jetzt den offensichtlichen Fehler an
der Stelle revertiert und hoffe, dass da nicht noch mehr Schmu mit drin ist.

Moin,
jetzt sollten von mir keine doppelten Punkte mehr drin sein. Schau gerne noch mal drüber, auf dass mir das nicht noch mal passiere..
Viele Grüße
Björn :)

Hallo,

oh, dann schau ich mir die ganzen Änderungssätze noch mal an oder ist das schon gefixt? Danke auf jeden Fall für die Mitteilung, ich weiß nur noch nicht
genau, woran das liegt, vielleicht ist das Aktualisieren der Daten in
JOSM ein Punkt, der nicht ganz so gut funktioniert...

Viele Grüße
Björn