Sehe ich das richtig das Du für die Bahnsteignummern den key ref verwendet hast?
Statt ref müsste local_ ref verwendet werden, siehe osm.wiki/DE:Tag:public%20transport=stop%20position?uselang=de

Hallo,
Danke für den Hinweis! Ich hatte das vor Ort mit EveryDoor auf die Schnelle eingetragen und dann vergessen, mich weiter darum zu kümmern. Du darfst das gerne weiterbearbeiten!

Eine stop_position gehört auf das Wasser, auf die Fährroute. --> Die stop_position müsste aus meiner Sicht auf das Wasser verschoben werden (siehe auch osm.wiki/DE:%C3%96ffentlicher_Verkehr#F%C3%A4hren ) .
Und irgendwann wird dann vielleicht auch einmal eine Fährroute gemappt werden

Als physische sichtbare Objekte gibt es bereits:

Linie: 1085867393
floating=yes
man_made=pier

Punkt: Anlegestelle Hanau-Schloss Philippsruhe (9949752864)
mooring=cruise
name=Anlegestelle Hanau-Schloss Philippsruhe

Das scheint mir beides korrekt.

> Das ist doch so etwas wie eine Bedarfshaltestelle der Ausflugsschiffe zwischen Frankfurt und Aschaffenburg?

IMHO ist es eine reguläre Haltestelle für die Primus-Line Fahrten
- Aschaffenburg über Seligenstadt und

- Seligenstadt
https://www.primus-linie.de/de/fahrten?c=&l=173

Hier ist ein Bild der Anlegestelle:
https://www.primus-linie.de/de/fahrten/anlegestellen/hanau-schloss-philippsruhe-173

> Was für ein Verkehrsmittel ist das eigentlich? Es ist kein bus und ferry passt irgendwie auch nicht.

Fähren gehören IMHO zum Öffentlichen Verkehr, siehe
osm.wiki/DE:%C3%96ffentlicher_Verkehr#F%C3%A4hren

Diese Fähre ist auch Personenverkehr.

Der RMV verkauft auch Tickets für die Primus-Linie und bindet anscheinend Fahrten damit auch auch ein:
https://www.rmv.de/c/de/suchen-und-finden/suche?tx_kesearch_pi1%5Bsword%5D=Primus

IMHO Ferry passt, und es ist eventuell sogar ÖPNV, weil der RMV dabei ist.

> Alles in allem würde ich dort lieber etwas wie amenity=ferry_terminal tourism=attraction attraction=boat_ride

Wenn ich das Wiki lese scheint amenity=ferry_terminal veraltet zu sein; es gibt da auch kein Gebäude (und es gibt schon die beiden physischen Objekte Pier und Mooring (Festmacher).

tourism=attraction und attraction=boat_ride wäre sinnvoll, aber wo mappen?

Eigentlich an die nicht gemappte Fährroute (die Fährroute müsste eine Relation werden).
An das Pier und an den Festmacher (mooring) gehören sie IMHO nicht.
Und auch nicht an die stop_position.

Zusätzlich einen platform node mappen? Die platform wäre dann dort, wo der zu verschiebende stop_position jetzt ist.

Oder einfach den vorhandenen stop_position node in eine platform ändern und die stop_position vergessen.

Fühle Dich frei zu verbessern wie Du magst.

Grüße
Kartibu

Bei mehrere bollards in diesem Änderungssatz ist jeweils der colour Wert red/white IMHO nicht zulässig.

Osmose erzeugt jeweils den Fehler
Bad colour name - Unknown or invalid colour in tag 'colour'
Class ID 30914

Denn das Trennzeichen für mehrere Werte, auch für Farben, ist das Semikolon und zwar bis - auf bestimmte Ausnahmen - OHNE Leerzeichen Siehe osm.wiki/Semi-colon_value_separator

Richtig wäre hier: red;white

Es gibt noch einige weitere gleiche Fehler in weiteren Änderungssätzen in der westlichen Umgebung.

Ich rege an, dass in Osmose zu checken und zu beheben.

Beim Antiquariat Bläschke node/3835420170 wirft Osmose jetzt den Error

Invalid Opening Hours
The `opening_hours` value is invalid and could not be parsed

Die Öffnungszeiten wurden inhaltlich nicht geändert.

Es wurde lediglich die Syntax verändert, so dass sie jetzt fehlerhaft ist, ohne an den Öffnungszeiten inhaltlich etwas zu ändern.

Was ist der Hintergrund?

Danke für die Info.
Ich habe jetzt an @Einer12 auch noch einmal eine OSM-Nachricht mit Hinweis auf diese Kommentare gesendet.

Die Änderung am Gebäude way/169464666 , und zwar die Änderung in ein Retail-Gebäude, ist IMHO nicht korrekt.
Es ist ein Mehrfamilienhaus; dort können sich auch im Erdgeschoss Läden befinden. Siehe Wiki.
Das Gebäude wird danach klassifiziert als was es gebaut worden ist und wie es von außen ausschaut, und nicht nachdem, was sich gegenwärtig darin befindet; siehe Wiki.
Dieses Gebäude ist kein Retail-Gebäude (Einzelhandel).
Es wurde als Mehrfamilienhaus gebaut und sieht auch so aus. Dass es nicht mehr als Mehrfamilienhaus verwendet wird, wird durch den Tag building:use=commercial markiert, wie er hier vorliegt. Siehe auch das Wiki zu building:use

Vielen Dank für die Rückmeldung. Die Punkte a) bis d) bieten eine gute Grundlage, mein Verständnis darzulegen.

Zu a): Kein physisch-existentes Feature – daher kein Hinderungsgrund/keine Voraussetzung für einen Merge (Zusammenlegung). Wert ist nach einem Merge ggf. anpassbar.
Zu b) & c): Physisch-existent und zutreffend – also relevante Merkmale.
Zu d): Nicht relevant für den Merge, da Namen keine physischen Features sind (sie sind bspw. durch Tags wie "bridge:name=*", "alt_name=*" etc. abbildbar).

Nach meinem Verständnis bedeutet "One feature, one OSM element":
Ein physisch-existentes Objekt (Feature) soll durch genau ein OSM-Element abgebildet werden. Hier ist es der Eiserne Steg.

Es lagen zwei Brückenobjekte vor (beide "way"), mit identischen Tags zu Struktur, Layer, Beleuchtung und Namen. Weitere Tags sowie vier Relationen kamen jeweils nur einmal vor. Es gab keine widersprüchlichen oder fehlerhaften Tags. Somit war der Merge auch geboten.

Meine Schritte:

- Tags beider Objekte checken: Welche Tags sind physisch-existent, welche nicht; Welche Tags sind doppelt; Verträglichkeit der Tags nach einem Merge usw.
- Merge durchgeführt
- JOSM-Prüfung: fehlerfrei
- Osmose: keine Warnung
- Test Rendering und Routing: wie erwartet, siehe vorheriger Kommentar

Zur Frage nach "man_made=bridge" + "highway=pedestrian": Beide Tags waren bereits vorhanden und die Kombi ist durch den Merge entstanden. Es liegt keine "Sonderregel" zugrunde. Ob ggf. "highway=footway" auch funktioniert habe ich nicht geprüft.

Zur Aussage, dass "bei jeder anderen Situation" Brücke und Weg getrennt werden müssten:
Das trifft nur auf b) und c) zu, nicht auf a) und d) weil a) + d) physisch nicht existent. Dann alternative Modellierung.

Alternative Modellierung: Möglich wäre auch die Abbildung eines einzigen Brückenobjektes als Relation mit mehreren Kind-Elementen ( bridge=*#Bridges_with_several_roads/ways_or_additional_features ). In diesem Fall erscheint dies aber nicht notwendig, da die aktuelle Umsetzung funktioniert.

Zur Konsistenz:
Die Regel "One feature, one OSM element" ist offiziell dokumentiert und bildet daher den Maßstab für Konsistenz – unabhängig von verbreiteter Praxis. Mehrfacheinträge physisch-existenter Objekte erhöhen den Pflegeaufwand und führen zu Fehleranfälligkeit. Jedes Duplikat-Feature (wie z.B. hier das doppelte Brückenobjekt Eiserner Steg) enthält zwangsläufig physisch-existente Tags und widerspricht somit dem Wiki.

Fazit:
Zwei Brückenobjekte für den Eisernen Steg sind gemäß osm.wiki/One_feature,_one_OSM_element und bridge=* nicht regelkonform. Mein Merge war ein Schritt zur korrekteren Umsetzung. Optimierungspotenzial besteht ggf. weiterhin – doch aus meiner Sicht entspricht der aktuelle Stand dem OSM-Wiki besser als zuvor.

Vielen Dank für die Rückmeldung und die kritische Auseinandersetzung mit der Änderung.
Hier meine Wahrnehmungen und Gedanken dazu:
Ich bezweifle, dass durch die Zusammenführung des Eisernen Stegs als Brücke und als Weg eine unzulässige Vermischung stattfindet. Auch bezweifle ich, dass dies gegen die Regeln von OpenStreetMap verstößt.
Im OSM-Wiki wird im Artikel *One feature, one OSM element* das Prinzip erläutert: "One feature, one OSM element is a good practice principle. It means one on-the-ground real world feature should be mapped with only one OSM element"
Dort ist also von einem - einzigen - physischen Objekt die Rede. Dies wird auch durch die Definition im Artikel *Features* bestätigt: "In OpenStreetMap, a feature is a physical element in the landscape that can be mapped." osm.wiki/Features
Der Eiserne Steg ist ein einzelnes, physisch existierendes Bauwerk. Aus diesem Grund ist es IMHO nach korrekt und regelkonform, ihn auch als ein einziges OSM-Objekt zu erfassen.
a) Nimmt man gedanklich oder physisch den Weg vom Eisernen Steg weg, bleibt keine Brücke im funktionalen Sinne übrig, da ihre eigentliche Funktion – das Überqueren – entfällt.
b) Umgekehrt ist auch der Weg untrennbar mit der Brücke verbunden, denn eine Brücke ohne Überquerungsweg ist kein vollständiges Bauwerk im infrastrukturellen Sinn. Brücke und Weg bilden hier eine physische und funktionale Einheit.
Ob der Weg denselben Namen wie die Brücke trägt oder nicht, ist in diesem Zusammenhang unerheblich. Unterschiedliche Bezeichnungen innerhalb eines Objekts können und müssen durch geeignete Tags wie `alt_name`=*, `official_name`=* oder durch Rollen in Relationen abgebildet werden – nicht durch das Anlegen doppelter Objekte.
Aus dem oben genannten Verständnis heraus war es IMHO sachgerecht und sogar geboten, das Duplikat aufzulösen, um das Prinzip "one feature – one element" konsequent umzusetzen.
Könnte der Begriff "feature" möglicherweise im Sinne von Funktion oder Attribut verstanden worden sein, anstatt – wie in der OSM-Dokumentation definiert – als physisch existierendes Objekt?
Ich habe die Routing-Funktionalität in OSMAnd vor und nach meiner Änderung getestet:
- Fußgänger-Navigation: wird über den Eisernen Steg geführt – das entspricht der Erwartung.
- Mofa-Navigation: wird nicht über den Eisernen Steg geführt – das entspricht der Erwartung.
- Fahrrad-Navigation: wird über den Eisernen Steg geführt – ob dies der Erwartung entspricht, ist fraglich. Allerdings hat sich durch die Zusammenlegung in dieser Hinsicht nichts geändert.
Wenn von Routing-Problemen auf Flächen die Rede ist, betrifft dies in diesem Fall ausschließlich Fußgängerrouting. Dies ergibt sich aus folgenden Punkten:
- Alle vier dem Objekt zugeordneten Routen sind als *hiking* klassifiziert.
- Für Radfahrer besteht auf dem Eisernen Steg keine vollständige Durchfahrtsmöglichkeit ohne Absteigen, da am nördlichen Ende entweder eine Treppe oder ein Aufzug genutzt werden muss.
In diesem Zusammenhang wäre es hilfreich, konkrete Beispiele für Router zu kennen, die an dieser Stelle beim Fußgänger-Routing aufgrund der Flächenmodellierung versagen. Gibt es hierfür konkrete Beispiele?
Selbst wenn es Router geben sollte, die an dieser Stelle bei der Fußgänger-Navigation versagen, stellt sich die grundsätzliche Frage, ob es nicht zielführender wäre, die Entwickler dieser Router darüber zu informieren, dass ihre Software an dieser Stelle verbesserungswürdig ist – anstatt das OpenStreetMap-Mapping durch objektfremde Duplikationen an technische Einschränkungen anzupassen. Denn OSM sollte IMHO sich an den realen Gegebenheiten und kartografischen Prinzipien orientieren, nicht an Defiziten einzelner Auswertungssoftware.

Hello,
Thank you for your feedback. I just selected the color in the editor "Street Complete expert edition" version 60.3 ( osm.wiki/SCEE ). I trusted this editor. I have not checked your indication that this color is invalid now. It could be that it is an issue with the "Street Complete expert edition" editor. You are free to delete the color again or change it to a hex value or report the issue to the Street Complete expert edition project. I am only a user of this editor.

Hi, ich weiß nicht ob diese Relation als Gesamtes überhaupt in OSM existieren sollte oder nicht; und ich habe mich darum auch nicht gekümmert.
Ich habe lediglich festgestellt dass der Wert des wikipedia tag mit en: beginnt.
Es sollte aber immer diejenige Sprache verwendet werden die das subject betrifft. Das Subject ist hier Johann Wolfgang von Goethe.
Er ist deutsch.
Siehe den Guideline "Only provide, in normal circumstances, a link to a single Wikipedia article, which should be to the article in the primary (local) language for the subject." auf der Wiki-Seite
wikipedia=*

:signed ist ein Key suffix. Siehe
*:signed=*

The suffix *:signed=* is added to a key to indicate whether the property can be verified by reading a posted sign.

Auf deutsch:
Das Suffix *:signed=* wird an einen Schlüssel angehängt, um anzugeben, ob die Eigenschaft durch Ablesen eines Schildes überprüft werden kann.

Mindestens am südlichen Ende gibt es das Schild "Radfahrer absteigen"
https://de.wikipedia.org/wiki/Datei:Zusatzzeichen_1012-32.svg

Hi,
Thanks for your thoughts on this!
I have changed or added some tags to achieve a better understanding.
This is a dedicated work of Kinetic art in which movement is an integral aesthetic component. Movement cannot be separated in kinetic art. If movement is missing, then the work of art is destroyed. This is the case here: Due to the lack of water, the rotors do not rotate. It is a modern art fountain ruin.

Describing the object as a broken work of art does not seem appropriate to me. For example, disused:art_work or abandoned:art_work do not fit in my opinion. Tagging with historic such as historic=yes, historic:art_work, historic:amenity or historic:fountain would also be unsuitable.

Officially, the object is referred to as a fountain, including in Wikipedia.

The term "fountain" does not refer exclusively to the function of carrying water, but also to the structural design and the historical or cultural significance and the artistic intention.
A classification as a broken work of art would therefore be misleading and also completely unusual in OSM.
The classification as a broken kinetic art fountain comes closest to describing the object.
That is why the term "fountain" is still the best solution.

Regards,
Kartibu