Hallo Hobo_1 und danke für deine Beiträge zur OpenStreetMap.

Bitte beachte, dass wir den Namen von Objekten ausschließlich für den tatsächlichen Namen nutzen.¹ Anmerkungen, Beschreibungen und Hinweise werden stattdessen über separate Schlüssel hinterlegt. Für Haltestellen können die bedienenden Routen in route_ref= mit Semikolon („;“) getrennt aufgelistet werden.² Die detaillierte Erfassung von Buslinien erfolgt hingegen über entsprechende Relationen; was aber leider eine recht komplexe Angelegenheit ist.³

Aus diesem Grund habe ich diesen Änderungssatz revertiert.
Beste Grüße!

1) osm.wiki/DE:Namen#name_ist_nur_der_Name
2) osm.wiki/DE%3AKey%3Aroute_ref
3) osm.wiki/DE:Tag:route%3Dbus

> Nicht dokumentiert
Es gibt viele Dinge, die im Wiki nicht erwähnt werden; aber was ich finde ist „Feel free to invent new tags! If you want to mark something that is verifiable and mappable in OpenStreetMap but there is no existing tagging scheme for that - then you can invent and use new tags … You can use any tags you like, but please document them here on the OpenStreetMap wiki.“. (Betonung auf dem “please”; in meinen Augen äquivalent zum “SHOULD” aus RFC 2119).

> Überflüssig
Was eine „richtige“ Seite sein soll und insbesondere wie du einem Computer beibringen willst sie feststellen, ist mir ein Rätsel. Man kann mehr als genug Konstellationen finden, in denen sich diese – aus deiner Perspektive – Selbstverständlichkeit als gar nicht so selbstverständlich herausstellt.

Ich revertiere diesen Änderungssatz. Kläre bitte Sinn und Unsinn des Tags erst im Forum ab, bevor du eine ersatzlose Löschung durchführst.

Falsche ID, hier der korrekte Changeset: changeset/119807697

Hallo wsoroe, soweit ich sehe, hast du mit diesem Änderungssatz alle Instanzen von guard_rail:smooth_side gelöscht, ohne eine alternative Tagging-Möglichkeit einzuführen.

Gemäß der „Any tags you like“-Regel fand ich die Tags legitim. Entsprechend bin ich mit der Beschreibung "ungültiger Schlüssel" des Änderungssatzes und der De-Facto-Informationslöschung ziemlich unglücklich.

Beste Grüße

Hallo goodidea. An dieser Stelle mal ein kleiner Hinweis, falls du nicht schon bereits kontaktiert wurdest, dass Benutzer wsoroe mit Änderungssatz c1050445383 alle Instanzen von guard_rail:smooth_side gelöscht hat.
Beste Grüße

Hallo erneut, ich kann mich den Standpunkten von highflyer74 und silversurfer83 nur anschließen. Meiner Auffassung nach wollen contact:website und website (sowie die weiteren Key-Paare) jeweils das gleiche Aussagen und koexistieren nur aufgrund der Tatsache, dass es in der Community zwei Lager gibt: Mit Präfix und ohne Präfix; und wir deshalb mit dem status quo leben (müssen)¹ ².

Um keine Edit-Wars zu provozieren hat sich daher nach meiner Beobachtung etabliert, dass das erstmalig genutzte Schema zumindest bei geringfügigen Änderungen beibehalten wird. Die gleichzeitige Verwendungen von äquivalenten Keys beider Schemata ist zumindest für den Raum Saarbrücken absolut unüblich und führt nebenbei auch zu Osmose-Fehlern, die zumindest hier in der Region auch als solche anerkannt und beseitigt werden.

Abgesehen von diesem Problem wundert mich noch die ersatzlose Löschung von contact:facebook, könntest du diese bitte noch erläutern?

¹ osm.wiki/Contact:website_/_website_/_url
² osm.wiki/Discussions/tagging/contact:phone_or_phone

Hallo Patrick1977Bln, ich erkenne ehrlich gesagt nicht so recht, inwiefern deine Änderungen Verbesserungen bzw. Korrekturen sind. Soweit ich sehe hast du zweimal contact:facebook gelöscht und zusätzlich zum bereits existierenden contact:website eine gleiche oder unspezifischere URL in website hinterlegt. Könntest du mir bitte aufzeigen, was ich übersehe? Besten Dank

Hallo SonnenStar, dem Impressum des Abenteuerparks⁽¹⁾ entnehme ich, dass dieser von Privat betrieben wird. Könntest du bitte erneut über deine Änderung drüberschauen? Besten Dank und beste Grüße

1: https://www.abenteuerpark-saar.de/impressum/

Hallo zeptonix und willkommen bei OpenStreetMap.

Du hast die Radroute als neuen Weg eingezeichnet. Leider ist das Einzeichnen von Radrouten recht komplex und erfordert, dass die bereits in der Karte verzeichneten Wege zu einer Relation gruppiert werden, statt sie neu einzuzeichnen. Da durch das erneute Einzeichnen nun teilweise zwei Radwege nebeneinander auf der Karte auftauchen, habe ich deine Änderungen revertiert.

Zudem sehe ich lizenzrechtliche Probleme bei Einzeichnen der Kompass Fahrradfüher-Saarland Tour1. Liegt eine ausreichend freizügige Lizenz vor, die eine Lizenzierung für die OpenStreetMap ermöglicht?

Beste Grüße

osm.wiki/DE:Bicycle/Fahrradrouten_kartieren

* "Verbose" should read "ambiguous".

Same text as above, now in English:

Hi SekeRob, you merged two nodes: one of a man_made=survey_point and one of a marker=plate. My understanding is that these should remain two nodes due to the "one feature, one OSM element" rule. Similary, IMO the two doors should be separate nodes, since the lower one is an emergency exit and the upper one a regular passageway. Semicolon-delimited enumerations are unordered so your modelling is currently verbose.

Hallo SekeRob, du hast die zwei Knoten für einen man_made=survey_point und einen marker=plate zu einem Knoten zusammengeführt. Meiner Auffassung nach müssten das aufgrund der "One feature, one OSM element"-Regel zwei Elemente bleiben. Analog auch die zwei Türen, wobei die untere ein Notausgang ist, die obere aber ein regulärer Durchweg.

Hallo Dirk Feld, weshalb hast du die L 251 von einer highway=tertiary zur highway=secondary hochgestuft? Das Wiki nennt speziell für das Saarland:
"Im Saarland gibt es Landesstraßen erster und zweiter Ordnung — die Landesstraßen zweiter Ordnung erkennt man an ihrer höheren Nummer (ab L 200). Sie entsprechen den Kreisstraßen und sollten deshalb auch als highway=tertiary gekennzeichnet werden." [1]

Beste Grüße

[1] osm.wiki/DE:Tag:highway%3Dsecondary

Die Änderungen sind unerwartet schlecht. Partiell revertiert.

TL;DR: siehe letzten Absatz

Hallo goodidea,

Mich wundert es auch, dass sich aus dem ursprünglichen Hinweis, dass ich bestehendes Tagging kaputt gemacht habe jetzt ein Bekehrungsversuch entwickelte. Mir scheint, als führst du mit mir eine Grundsatzdiskussion mit dem Ziel eine stärkere Differenzierung von Ampeln für Überwege und Ampeln zwecks Schutz eines Kreuzungsbereiches zu erreichen. Fakt ist aber, dass das für dich "Unbehagen verursachende" Tagging, welche eine solche Differenzierung nicht in dem von dir gewünschten Maße vorsieht, nicht nur nicht Ausnahme ist, sondern durchaus auch Verbreitung in Deutschland hat.

> Schon alleine daher würde ich die nur im absoluten Ausnahmefall [und nur?] bei „pelican crossings“, also reinen Fußgängerampeln an NICHT-Kreuzungen, also auf einer geraden Straßenstrecke, mit EINEM Knoten taggen.

Da ich die letzten Wochen u.a. die zwei Städte in DE besucht hatte, möchte ich vergleichend die Tagging-Situation dort betrachten. Die genannten Beispiele habe ich vor Ort besichtigt:
* Signalisierte Querungsstelle ohne Kreuzung mit reiner Bedarfsampel. Keine Trennung von Querungsstelle und zwei Ampeln je Fahrtrichtung.
=> Hamburg: node/362575684
** Signalisierter Fußgängerüberweg an einer Kreuzung. Lichtsignalanlage dient zum Schutz der Kreuzung, der Querungsstelle wird gewissermaßen als Nebenprodukt mitreguliert. Keine Trennung von Überweg und Ampel Richtung Kreuzung.
=> Hamburg: node/623926537, Frankfurt: node/804134301
** Ebenfalls signalisierte Querungsstelle an einer Kreuzung. Querungsstelle und Ampel Richtung Kreuzung separat kartiert. ("So wie du dir das wünschst")
=> Hamburg: node/5974195819 + node/617307767, Frankfurt: node/452926210 + node/803169872

Mein Punkt ist, dass das was du durch die Blume als irrational bezeichnest (da nicht deinem gewünschten Schema entsprechend), Verbreitung hat und auch keine Erfindung von mir ist.
-

> Ich kann auch nicht nachvollziehen, warum für dich highway=crossing keinen Sinn macht.

Du bestätigst doch meine Aussage. Ich sagte nicht, dass es highway=crossing nicht braucht. Ich sage bloß, dass es keine weiteren Informationen gegenüber crossing=* bietet. Meine Kernaussage ist, dass durch crossing=* bereits ausgesagt wird, dass eine Querungsstelle vorliegt und highway=crossing die gleiche Aussage tätigt. Die Sinnhaftigkeit durch (hier ohne hin nur eingeschränkt anwendbares) Konzept von Ober- und Untertags habe ich nicht abgesprochen.
-

> Unpassend ist eigentlich die Kombination highway=traffic_signals + crossing=traffic_signals…

In dem Fall kann ich nur sagen: Entsprechende Alternative aus dem Wiki löschen oder ggf. Proposal starten.
-

> Und ich frage mich: wie klar soll das Wiki da noch sein?…

Dann am besten schnell aus dem JOSM-Preset löschen lassen, wenn es ja ach so offensichtlich falsch sein soll.
-

> Denn der Link mit Anker springt zu keiner Stelle…

"Text Fragment Link", nicht URL-encodet zwecks Menschenlesbarkeit
-

> Die Screenshots stammen wohl augenscheinlich aus JOSM, mit dem Stil „JOSM Standard (MapCSS)“.… Oder übersehe ich da etwas?

Passt so. Die Herabstufung erfolgte erst 2018 osm.wiki/Special:Diff/1588572. Entsprechend wäre es nicht groß verwunderlich, wenn dass alternative Tagging für das Bild genutzt wurde.
-

> Ich verstehe nicht ganz, wieso du dich auf DIESES zweitletzte Beispiel und sowieso auf diese Tabelle mit ALLEN Mapping-Varianten beziehst.
> …dieser Hinweis fehlt aber.

Weil es als valide Möglichkeit aufgelistet wird. Deine Interpretation des Aufbaus der Tabelle ist zwar nett, aber nirgens auf der Seite niedergeschrieben. Schreib es in den Wiki-Artikel und warte ab, ob jemand widerspricht oder starte alternativ eine Diskussion im Wiki. Bis das nicht erfolgt ist, bleibt deine Interpretation der Tabelle vorerst nur persönliche Lesart.
-

> …Fußgängerüberwege IDEALERWEISE gemappt werden sollten…
> Ich will damit nur sagen, dass die von mir präferierte Methode eigentlich überall nur Vorteile hat. … Ich denke, das sollte jetzt deutlich geworden sein.

Mein erster Beitrag fing nicht grundlos an mit: "in meinen Augen sind wir, soweit ich dich richtig verstanden habe, eigentlich d'accord darüber, wie solche Kreuzungen ideal mit größtmöglichem Detailgrad getaggt werden."
-

> Nun noch zur Kreuzung in Schafbrücke:

Wenn ich ganz ehrlich bin, ist deine Ausführung hier für mich unerheblich. Ich verstehe deinen Standpunkt und verstand ihn auch schon zuvor. Meine Darstellung sollte nur meinen Gedankengang transparent machen, da wir im Kern ohne hin übereinstimmen und das Schema meiner Änderung deiner Kritik zu trotz im Wiki dokumentiert ist. Ob man nun bevorzugt, dass explizite Kreuzung und Ampel vermischt werden, oder Ampel und Querung ist in meinen Augen nicht diskussionswürdige Geschmackssache.
-

> Die Antwort auf die Frage scheint für mich nur zu sein, dass du eine Präferenz hast, Verkehrsampel und Überweg zusammenzulegen zu EINEM Knoten, also diese Objektvermengung, wie ich es nennen würde. Oder den kleinen Mehraufwand scheust.
> Es ist für mich nicht der letzte Schritt in der vielleicht schrittweisen Optimierung von Kreuzungen mit Übergängen, sondern ein Zwischenschritt, den man leicht überspringen könnte mit nur sehr wenig Mehraufwand (und großem Gewinn).

Ich zitiere mich: "Stattdessen habe ich im ersten Schritt [nach meinem Empfinden] eine Verfeinerung der Modellierung vorgenommen ("Ampel je Richtung"). Dein Korrektur-Änderungssatz hat daran angeschlossen und die Modellierung noch weiter verfeinert ("Ampel und separater Überweg je Richtung")."
-

> Ich fände es ja toll, wenn ich dich für meine präferierte Methode irgendwie gewinnen könnte

Wie wäre es, wenn du beim nächsten Mal nicht in der Attitüde "du hast meine Arbeit kaputt gemacht" auf mich zukommst und mir sachlich und nicht paternalistisch vorschlägst, doch lieber auf das von dir bevorzugte Schema umzusatteln? Dann hätten wir wahrscheinlich schnell bemerkt, dass wir beide das gleiche Schema als ideal empfinden und die einzige Diskrepanz in der Meinung zu einer "vereinfachten" Erfassung bestand.
-

> Oder du müsstest mir einmal sagen, dass das absolut OK ist, es so zu ändern…

Keine Einwände.
-

Abschließend: Wie schon dargestellt, sind wir in meinen Augen d'accord darüber, was ideales Tagging ist. Streitpunkt war lediglich die Sinnhaftigkeit eines davon abweichenden im Wiki dokumentierten Schemas. Gerne werde ich fortan auf das "vereinfachte" Schema verzichten.

Gruß

Hallo goodidea,

in meinen Augen sind wir, soweit ich dich richtig verstanden habe, eigentlich d'accord darüber, wie solche Kreuzungen ideal mit größtmöglichem Detailgrad getaggt werden.

Klarstellen möchte ich noch, dass ich unter highway=traffic_signals eine "Auto-Ampel" verstehe, während mit crossing=* Fußgängerüberwege/-ampeln kartiert werden. highway=crossing hat in meinen Augen in Verbindung mit crossing=* semantisch keinen Mehrwert und existiert nur, damit man einen highway-Tag=* hat.
Entsprechend stimme ich dir nicht zu bei:
> dass highway=traffic_signals + crossing=traffic_signals sehr überwiegend nur für REINE Fußgängerampeln benutzt werden sollte
M.E. widerspricht das "highway=traffic_signals#:~:text=Vehicle traffic signals before intersection, pedestrian crossings not separately mapped"
Ferner wird auch dargestellt, dass bei Auto-Ampeln ausschließlich für Überwege (statt Kreuzungen) eigentlich highway=crossing zu nutzen sei. Bisher gehörte ich eher mangels Wissen der "some mappers use: highway=traffic_signals"-Fraktion an.

Bei der von dir genannten Kreuzung in Schafbrücke kann ich ehrlich gesagt nicht nachvollziehen, inwiefern du meine Änderungen dort monierst. Aus Achavi https://overpass-api.de/achavi/?changeset=110531670 (zeigt merkwürdigerweise nicht alles an) entnehme ich, dass ich beim Kreuzungsknoten (node/157362127), bei welchem sich die Straßen kreuzen, die Ampel entfernt habe und an die vier Straßenüberwege (u.a. node/1392275443) "verschoben" habe. In diesem Prozess wurde aus den bisher reinen Straßenüberwegen highway=crossing Kombinationen aus Ampel + Überweg: highway=traffic_signals + crossing=*. Eine Löschung oder "Tag-Leerung" von Objekten durch Zusammenführen zweier Knoten hat nicht stattgefunden. Ausschließlich fanden Umwidmungen von Knoten statt. Auch ein Achavi-Diff von Ende August zu Anfang September zeigt keine Löschungen im Bereich der Kreuzung.

* Entfernen von highway=traffic_signals bei Kreuzung: Die Modellierung der Ampel auf dem Knoten, an dem sich die Straßen tatsächlich kreuzen, ist eine Vereinfachung. Hierbei ist die modellierte Position der Ampel völlig unabhängig von der tatsächlichen örtlichen Position.
=> Aufgrund des Folgeschritts fand kein Verlust der Information "an dieser Kreuzung gibt es eine Ampel" statt. Somit bin ich der Meinung, dass diese Änderung unproblematisch war.
* Verschieben (ung Duplizieren) der Ampel: Durch das Verschieben der Ampel auf die zur Kreuzung führenden Straßen wird die Modellierung der tatsächlichen örtlichen Situation angenähert und der Informationsgehalt entsprechend erhöht. Die Anzahl der Ampeln entspricht nun der Anzahl der mit Signalen versehenen zuführenden Straßen und die Position der modellierten Ampeln liegt näher an der der tatsächlichen. Ferner ist eine Erfassung weiterer Details nun auch granulär für jede zuführende Straße möglich.
=> Aufgrund des erhöhten Informationsgehaltes bin ich der Meinung, dass diese Änderung unproblematisch war. Zwar ist es in vielen Städten in DE nicht unüblich, dass nur eine Ampel auf dem Kreuzungsknoten angebracht wird; die Erfassung an jeder zuführenden Straße ist aber ebenfalls ausreichend etabliert.
* Zusammenführenden mit dem Überweg: Da ich i.A. nicht in einem solchen Detailgrad wie du kartiere, vereinfache ich meistens die Positionen von neueinzutragenden(!) Ampeln und führe sie mit den zugehörigen Überwegen zusammen. In diesem Prozess wird highway=crossing zu highway=traffic_signals.
=> Ich bin der Meinung, dass dies aufgrund des etablierten Taggings durch crossing=* unproblematisch ist. Durch die Ersetzung von highway=crossing mit highway=traffic_signals geht kein Informationsverlust von durch Tags kartierten Informationen einher. Die Existenz eines Überweg kann weiterhin durch crossing=* inferiert werden und sonstige Tags des Überwegs bleiben unberührt. Da zudem kein zuvor existierender Ampel-Knoten gelöscht wurde, ist auch keine Information in Form von der Position des Knoten verloren gegangen, da sie schlicht noch nicht zuvor kartiert wurde. In diesem konkreten Fall dient zudem die Signalisierung zum Schutz der Kreuzung und nicht "nur" zur sicheren Querung für Fußgänger, weshalb die Verwendung von highway=traffic_signals statt highway=crossing angezeigt ist.

In Anbetracht meines monierten Änderungssatzes (110531670) und deiner Korrektur dieses (c111428082, https://overpass-api.de/achavi/?changeset=111428082), bin ich der Auffassung, dass durch mich kein Informationsverlust stattgefunden hat. Stattdessen habe ich im ersten Schritt eine Verfeinerung der Modellierung vorgenommen ("Ampel je Richtung"). Dein Korrektur-Änderungssatz hat daran angeschlossen und die Modellierung noch weiter verfeinert ("Ampel und separater Überweg je Richtung").

traffic_signals:direction vergesse ich tatsächlich häufig. Sry.

Beste Grüße

Erneut, temporäre Veranstaltungen haben nichts in OpenStreetMap zu suchen. Bitte sehe von solchen "Beiträgen" ab.

Es gilt auch weiterhin, dass temporäre Veranstaltungen nicht zum Projektumfang von OpenStreetMap gehören. Ich habe deine letzten drei Änderungen revertiert.

Hallo "diebasis SL".

Temporäre Veranstaltungen sind für eine Karte ungeeignet und fallen daher nicht in den Projektumfang von OpenStreetMap. Ferner grenzen einige deiner Änderungen (insbesondere das Umbenennen von Straßen zur Bewerbung einer politischen Veranstaltung) an Vandalismus. Auch das Kartieren einer Kreuzung auf der Wand eines Hauses ist nicht wünschenswert; hier gehe ich mal davon aus, dass dies ein Versehen war.

Aus diesen Gründen habe ich deine/eure drei letzten Änderungssätze revertiert und bitte freundlichst um mehr Sorgfalt bei etwaigen zukünftigen Änderungen.
Beste Grüße

Hallo Dirk Feld, es ist unüblich die Straßennnummer im name-Tag zu erwähnen. Deswegen habe ich diese Änderung von dir revertiert. Beste Grüße