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

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

Hallo gvSmartEnergy, bitte verwende das "name"-Feld bei Objekten nicht als Beschreibung. Konkret also: Bitte nicht name=Playground bei Spielplätzen, sondern einfach leerlassen, falls dir kein Name bekannt ist.
Beste Grüße

Hallo Geo Dät, bei node/8836944769 und node/4032700066 scheint irgendetwas kaputtgegangen zu sein. Könntest du das bitte überprüfen?
Besten Dank und beste Grüße

Thank you for your reply, Mario Quinta. I have no problem with the fact that you mapped the route. I'm more concerned about the route master (relation/11888292) also containing paths of a route. This leads to error messages in Osmose. [1]
I assume that all routes in the route master relation should rather be mapped in a new separate relation, which is then added as a member in the route master, while the route master contains only other route relations as members but not ways.
---
(traduction informatique)
Merci pour votre réponse, Mario Quinta. Je n'ai aucun problème avec le fait que vous ayez cartographié l'itinéraire. Je suis plus préoccupé par le fait que le route master (relation/11888292) contient également des chemins d'un route. Cela entraîne des messages d'erreur dans Osmose. [1]
Je suppose que tous les chemins de la route master devraient plutôt être cartographiés dans une nouvelle relation distincte, qui est ensuite ajoutée en tant que membre dans la route master, tandis que la base de données des chemins ne contient que d'autres relations d'chemins en tant que membres, mais pas de chemins.

[1] http://osmose.openstreetmap.fr/fr/map/#zoom=18&lat=49.234355&lon=6.98989&item=xxxx&level=1%2C2%2C3&issue_uuid=f25b6f22-b117-7352-6f02-30db8fccbeb0

Hello Mario Quinta, with this changeset you've edited the route master relation/11888292/ of "GR 5G". Typically, route masters don't contain way segments but rather routes so could you please have a look at it again?

Hallo felixi, mit diesem Änderungssatz hast du u.a. die Reihenfolge der Haltepunkte der Buslinie 186 (relation/12538935) geändert. Könntest du bitte noch einmal drüberschauen? Auch wenn es zugegebenermaßen unschön ist, dass nicht alle Haltepunkte mangels public_transport=platform bereits im PTv2-Schema sind, denke ich dennoch nicht, dass die Umsortierung zweckmäßig ist.

Wie ich sehe, verwendest du iD, vielleicht wurde daher diese Änderung automatisch davon durchgeführt. Bist du damit einverstanden, dass ich den vorherigen Zustand wiederherstelle und die Haltepunkte mit Rollen versehe?

Hallo schneiders-mail,
die von dir als Knoten eingezeichnete FFW node/7181573374 existierte bereits als Pfad way/348377418. Ich habe ersteren gelöscht. Falls du meinst, dass das ein Fehler von mir war, antworte bitte hier.
Beste Grüße!

Hallo radfahrer 43, du hattest den Park "Im Eisengraben" dreimal eingezeichnet. War das beabsichtigt, oder versehentlich? Ich lösche mal zwei der drei, falls ich es wiederherstellen soll, bitte antworte bitte hier.

Hallo goodidea!

# Falsche Seiten
Besten Dank fürs Korrigieren der Bushaltestellen. Die auf der falschen Seite platzierten Haltestellen sind weitestgehend mein Verschulden und hingen damit zusammen, dass früher eine große Anzahl an Haltepunkten an den Straßen-Way geklebt wurde und daher nicht ohne Aufsuchen der Örtlichkeit ersichtlich war, welcher Haltepunkt mit welcher Seite korrespondiert; oder, dass es schlicht nur einen Knoten für beide Richtungen gab. Nachdem die Unterstände/Haltestellenschilder zunehmend als Platform getaggt wurden und im Prozess davon die Knoten von der Straße gelöst wurden, kam es leider vor, dass ich damals falsch geraten hatte und dadurch die Seiten vertauscht waren. Seit neuerem hat auch PTNA (https://ptna.openstreetmap.de/results/DE/SL/DE-SL-saarVV-Analysis.html) eine Erkennung von sowas; scheinbar schlägt diese aber nur in den seltensten Fällen an.

# Hintergrund check_date bei PT
Das check_date hatte ich, wie du korrekt festgestellt hast, auf die Fahrplanversion bezogen und hatte ich ganz anfangs meines Aktivwerdens im Public-Transport-Bereich ausschließlich im Wiki (osm.wiki/SaarVV) erfasst. Mit Aufkommen von PTNA wollte ich dann auch Metadaten für QA nach OSM bringen, sodass zukünftig die Wiki-Seite nicht mehr benötigt wird. Entsprechend brachte ich "note:timetable" an Linien an. Als letztes war der Gedanke Standardtags zu verwenden, weshalb die Umwandlung nach "check_date" erfolgte. Ziel der ganzen Tags sollte sein, dass bei Fahrplanwechsel einfach geprüft werden kann, ob Änderungen am Routenverlauf bereits übernommen wurden. Insofern ergäbe sich also ungefähr ein jährlicher Zyklus. Nun ist QA besonders im Bereich PT eher undankbar und aufwendig, weshalb solch ein Zyklus nur ein ambitionierter Wunsch geblieben ist.

# Verwendung check_date
Einen Eintrag über eine solche Verwendung von check_date konnte ich im Wiki nicht finden. Zumindest bei einer globalen Overpass-Anfrage fand ich 1500+ Relationen mit route=bus und check_date=*, wie dort der Einsatz aussieht, kann ich aber nicht beurteilen.

# Meinung
Dass der Tag weitestgehend unverändert bleibt, finde ich eigentlich nicht problematisch. Wie von dir erwähnt, könnte es sein, dass Beitragende nur Teilstücke der Route überprüft haben oder auch einfach nur (die sehr oft benötigten) Fehlerkorrekturen durchgeführt haben. Ob aber die Route in ihrer Gesamtheit noch aktuell ist, wurde in dem Fall nicht festgestellt. Ehrlich gesagt würde ich auch ein maschinenlesbares Tag statt eines Freitextfeldes bevorzugen, damit eine automatische Auswertung der letzten "Generalüberholung von Linien" möglich ist. Falls notwendig, würde ich also einen Wechsel des Keys für am ehesten für sinnvoll halten.

Beste Grüße

Ja richtig, genau der. Ich bin aber auch an einigen Kreuzungen mit anderen "Reitwegen" vorbeigekommen und hatte kein Mal entsprechende Schilder gesehen. Ich würde dem Eintragenden, soweit ich sehe Horbas 2009, mal unterstellen, dass die Wahl auf den Tag nur aufgrund der weniger ausgeprägten Befestigung der Wege und teilweise beträchtlicheren Steigung getroffen wurde, aber weniger einer rechtlichen Regelung entspringt.

Würde man in diesem Fall highway=path wählen?

Hallo Dorfbewohner, herzlichst willkommen bei OpenStreetMap und danke für deine Bearbeitung!

Da du darum gebeten hast, dass jemand deine Änderungen gegensichtet: Sieht alles supi aus.

Du hast eine Segment des "Boulevard der Industriekultur" als auch für Radfahrer gesperrt markiert. Weißt du zufällig, ob der Radwanderweg "Velo visavis Rundweg" verlegt wurde? Momentan ist dieser noch über das gesperrte Segment eingezeichnet.

Wie von dir angemerkt stimme ich bei den meisten Wegen zu, dass diese augenscheinlich keine Reitwege sind (insb. kein Schild und Pferdemist findet man im Stadtwald ohne hin auf allen Wegen), sondern eher grobe Pfade.

Schönen guten Abend goodidea!

Ich schließe mich deinem Vorschlag an und finde eine Verknüpfung zu Wikidata mittels "brand:wikidata", also nicht "operator:wikidata", ebenfalls am sinnvollsten. operator="cambio CarSharing Betriebsgesellschaft mbH" ist dann noch eine schöne Zusatzinformation. "operator:wikidata" ist alleine dahingehend schon problematisch, dass das Wikidata-Datenobjekt zwar sowohl auf Cambio in Deutschland als auch Belgien Bezug nimmt, der überwiegende Teil der Daten aber strikt deutsch ist (Rechtsform, usw.). Eigentlich müsste das auch dort korrigiert werden, aber ehrlich gesagt ist das aufgrund der verknüpften Wikipedia-Artikel eine eher undankbare Aufgabe, da man nicht ohne weiteres aus dem Datenobjekt eine Marke machen kann.

Eine Vereinheitlichung, wie von dir vorgeschlagen, finde ich auch sinnvoll. Nur beim "short_name" bin ich mir nicht ganz sicher; an den Station würde sich das ja auf den Stationsnamen beziehen und nicht auf den Namen des Betreibers.

Anmerkung 1: Dem NSI würde ich persönliche keine große "Normierungskraft" zuschreiben. Die Änderung von brand zu operator scheint wohl hier ihren Ursprung zu haben https://github.com/osmlab/name-suggestion-index/issues/2928 und hier umgesetzt worden zu sein https://github.com/osmlab/name-suggestion-index/commit/becf6a18e54e0021a79d10484f9c6042b821b8db .

Beste Grüße