Hast du dafür eine Quelle?

Wäre nicht foot=use_sidepath und bicycle=use_sidepath angemessener?

Mir sind bisher keine Glascontainer begegnet, an denen man nicht alle Farben einwerfen konnte, deshalb weiß ich nicht, wie sinnvoll es ist, dies hier zu taggen.

Darüber denke ich auch gerade nach. Im Gegensatz zum Parkplatz Steindamm/Schiffbrücke sind hier die Einzelparkplätze ja nicht verstreut, sondern alle innerhalb des klar definierten Bereichs. Vielleicht ist es echt am schlausten, die Relation zu löschen. Muss da nochmal in mich gehen.

Ok, d.h. der Way kommt ganz weg? Mir fällt jetzt erst auf, dass site=parking gar keine Fläche für den Parkplatz vorsieht. Wird der dann übrhaupt gerendert?

Hab ich in die site relation übertragen. Oder ist das falsch?

Ich habe den highway=service am Taxistand gelöscht. Hier befindet sich ja keine Straße. Dass man da rüberfahren kann stimmt zwar, aber das trifft auf die Parkplätze davor ja genauso zu (wenn sie frei sind).

Ich habe den highway=service am Taxistand gelöscht. Hier befindet sich ja keine Straße. Dass man da rüberfahren kann stimmt zwar, aber das trifft auf die Parkplätze davor ja genauso zu (wenn sie frei sind).

Übersehen, sorry

Es ist sehr irritierend, wenn eine langwierige Arbeit kommentarlos rückgängig gemacht wird. Das gibt einem das "schöne" Gefühl, gegen Windmühlen zu kämpfen. Laut Wiki ist die Verwendung von bicycle=designated und bicycle=use_sidepath korrekt bei Radwegen mit Benutzungspflicht. Diese liegen hier vor. Es handelt sich dabei nicht nur um eine relevante Information, sondern auch um eine, die für ein korrektes Fahrrad-Routing notwendig sind. Genauso die Fußwege im Schrevenpark: Das Radfahren ist hier durch Schilder an den Eingängen verboten. Warum löscht du diese all diese wichtigen Informationen?

Danke für den Hinweis, der mich aber ehrlich gesagt etwas verwirrt. Ein street_cabinet kann kein building sein, du hast aber trotzdem einen building-Tag gesetzt?

Wir haben ja theoretisch unbegrenzt Platz. Grundsätzlich sehe deshalb auch kein Problem darin, historische Daten mit lifecycle-Prefixes zu konservieren (z.B. shop:1970-1999=bakery | shop:1999-2018=kiosk | name:1970-1999=Ben's Bäckerei | name:1999-2018 Uwe's Kiosk). Aber das ist natürlich auch Geschmackssache und zudem ein Tagging-Schema, das immer noch unter "Proposed" gelistet ist.

Wäre es nicht besser, die alten Angaben mit "old name" etc. drin zu lassen? Ich finde die Möglichkeit, historische Daten zu hinterlegen, einen großen Vorteil von OSM gegenüber Google und Co.

Danke

Es wäre nett, wenn du einen Kommentar hinterlassen würdest, statt Änderungen von mir einfach nur zu reverten.

Zu deinen Änderungen im Einzelnen:

1. Die einzelnen Fahrspuren für Ein- und Ausfahrt aus dem Parkplatz Rundsilo entsprechen der Realität, eine bauliche Trennung ist vorhanden. Durch deine Änderung sie ist es z.B. nicht möglich, die Straßenlaterne zu mappen, die sich zwischen ihnen befindet.

2. parking_aisle ist laut Wiki für die Nebenfahrwege auf Parkplätzen gedacht. Die Zu- und Abfahrten sollen nur mit highway=service getaggt werde.

Ich denke, man müsste die Straße an jeder Einmündung teilen (also auch beim Brennofenweg) und dann jeweils prüfen, ob da Schilder stehen oder nicht. Ob eine Teilung an der Jugendherberge nötig ist, weiß ich nicht, Ansagen kommen (wenn überhaupt) ja vermutlich nur beim Einbiegen in die Straße.

Es sind aber beide Segmente, aus denen die Straße besteht, so getaggt. Und ich halte es für eher unwahrscheinlich, dass der Weg Nr. 596795015 in Vorwärts-Richtung ein Schild zur Jugendherberge aufweist.

Ich bin etwas vom Destination-Tag verwirrt. Die Sehestedter Straße kann doch nicht in beide Richtungen zur Jugendherberge führen?

Sieht gut aus, danke

OK, würdest du da evtl. übernehmen? Ich glaube, das übersteigert etwas meine Bearbeitungs-Kenntnisse, weil man das bestehende Areal aufteilen müsste (das Hafengebiet beginnt ja erst am Ende der Langebrückstraße)