Hallo Jakob48,

bin mir nicht sicher, was Du hier korrigieren wolltest, da 'maxspeed' für 'highway=speed_camera' genutzt wird (siehe unten wiki & taginfo), habe ich die Änderung durch Änderung: changeset/120003740 zurückgesetzt.

Schöne Grüsse
LI

wiki: highway=speed_camera

taginfo: https://taginfo.openstreetmap.org/tags/highway=speed_camera#combinations

Hallo PT-53,

danke fürs Drüberschauen.

Dort ist laut Luftbildern keine durchgezogene Linie, habe die Abbiegebeschränkung dementsprechend herausgenommen, siehe changeset/119766911
Schöne Grüsse
L___I

Hi tux67,

ich habe hier im Detail einige Parameter von Knotenpunkt node/7880762682, siehe Chronik: https://pewu.github.io/osm-history/#/node/7880762682 angepasst.

Weiterhin habe ich (nur nebenbei) die Reihenfolge der Mitglieder der Relation etwas sortiert (ist zwar derzeit im wiki (noch) nicht so beschrieben, dass das notwendig ist, finde ich aber der Übersichtlichkeit halber ganz i.O.), siehe: relation/11587711/history

Schöne Grüsse
L___I

Sehe ich auch so, ab wann ist ein Objekt beweglich?
Danke für den Link zur Forumbesprechung!
Grundsätzlich halte nicht viel vom Erfassen dieser Einheiten und schon gar nicht, wenn sie als stationär eingetragen sind. Löschung wäre für mich auch i.O.
Allerdings, wenn das jemand unbedingt drin behalten möchte, würde mich das (mit gepassten Taggingschema) auch nicht stören...
Keine Ahnung, welche bestehenden Untermerkmale, um die Zeitweiligkeit auszudrücken in Betracht kommen würden (eventuell interval=* / intermitted=* 'conditional' usw...)
Habe bis jetzt nur eine Einheit initial erstellt, den Rest habe ich wenigsten schon mal (als Kompromiss zwischen falsch belassen & vollständig löschen)
vom definitiv unstimmigen 'speed_camera' zu 'mobile_speed_camera' (nach Vorgehen any-tag-you-like) angepasst.

Danke für die Suchabfrage: https://overpass-turbo.eu/s/1h2C da sind ja noch einige unstimmige dabei. Ggf. werde ich die mal Gelegenheit drüberschauen.
Es gibt aber scheinbar immer mal wieder ein allgemeines Interesse daran, wie sich beim aktuellen Fall zeigt und diese angepasste Abfrage https://overpass-turbo.eu/s/1h6q zeigt.

Bzgl. Beitrag #3 wäre ja mal interessant, wie die entsprechenden Örtlichkeiten in Italien erfasst werden - ausschliesslich das Vorhersageschild, oder auch etwas an der folgenden zutreffenden Stelle? (Eventuell mit hazard=speed_camera, siehe https://pewu.github.io/osm-history/#/node/25263776 ?)
Bzgl. Beitrag #6 [...] Nur an wenigen Stellen ist eine Örtlichkeit gezielt für das Blitzen baulich vorbereitet. [...] Stimmt, meist reicht wohl bereits schon etwas Platz aus,
welcher dann eventuell durch 'passing_lane': highway=passing_place oder 'emergency_bay': highway=emergency_bay entsteht und erfasst werden könnte.

Siehe auch andere Änderung mit Kommentar:
changeset/118683183

Hallo HirschKauz,
[...] mobile speed-cams are never tagged on OSM [...]
Das stimmt so nicht. Ich habe gerade mal durchgeschaut wenigsten 15 (vermutlich mehr) verschiedene Benutzer haben versucht sie zu erfassen.
Siehe dazu auch die leicht modifizierte Anfrage von:user_5359 https://overpass-turbo.eu/s/1h6q
Allerdings werden sie eben meist unter der Verwendung des unstimmigen Merkmals einer stationären Einheit eingetragen.
Ich vermute da besteht ein gewisses Interesse und außerdem vermute ich, das wird auch in Zukunft immer wieder aktuell bleiben.

[...] fixed ones are tagged, but [...]
Korrekt, stationäre Einheiten werden mit highway=speed_camera (defacto) versehen.
Ich fand hier eine mobile Einheit unstimmig erfasst als stationäre Einheit vor.
Was ich hier zwischen
a) vollständiger Löschung und
b) falsche Erfassung beibehalten
als Kompromiss gemacht habe, ist es unter einem anderen Merkmal-Wert 'mobile_street_camera' zu erfassen.
Generell habe ich nichts gegen das vollständige Löschen, allerdings kann ich einige verstehen, die den Sachverhalt in OSM abgebildet haben möchten.
Unter Umständen geht es hier auch nicht direkt um die mobilen Einrichtung, sondern eher um die Plätze, Stichwort: "Radarschwerpunkt"
Grüsse

Siehe auch andere Änderung mit Kommentar:
changeset/118652015

Hello aharvey,

thanks for double checking the edit and for you message. Sorry for delayed reply. The tag was added without a comment about the reason in the past via change #81, see https://pewu.github.io/osm-history/#/relation/5750005

Thanks for asking a wider group of people. Happy to know their response.

Regards
LI

Hallo eserte,

nein, da lief bei meinem Änderungssatz soweit alles gut, siehe graphische Darstellung:
https://overpass-api.de/achavi/?changeset=94019560

Allerdings wurde ein Punkt (https://pewu.github.io/osm-history/#/node/8112964557) des von Dir erwähnten Weges in einem nachfolgenden Änderungssatz (https://overpass-api.de/achavi/?changeset=112202319) von Benutzer (@Lucy%20L) verschoben.

Du bist wahrscheinlich versehentlich bei meinem Änderungssatz herausgekommen, da es das Wegstück betrifft, dieses bekommt aber keine neue Versionsnummer, wenn nur einer der Punkte verschoben wird.

Der "Editierunfall" von "Lucy L" wurde nun bereits behoben, siehe:
https://overpass-api.de/achavi/?changeset=112558480
Schöne Grüsse
L___I

Alles klar.
Danke das Du mal drüber geschaut hast und für die Erläuterungen.

:-)

Hallo FreiTal,

danke für Deine Mitteilung.

Bin ehrlich gesagt mit Deinem Hinweis nicht glücklich, denn

a) ist das keine Fehlermeldung, sondern eine Warnmeldung
b) interessieren mich die wikidata-Merkmale nicht wirklich
c) interessierten mich die ÖPNV-Merkmale in Bezug auf diesen Änderungssatz nicht wirklich
d) habe ich hier bei diesem Änderungssatz an den ÖPNV-Daten nichts geändert

Die Meldungen sind wahrscheinlich von iD nur deswegen angezeigt worden, weil ich die Geometrie von verschiedenen Primary-way-Segmenten angepasst hatte, welche in einigen ÖPNV-Relationen eingebunden sind.

Von daher wäre für Deine Wünsche wohl eher die iD-Ticketseite für Softwareänderungsanregungen (https://github.com/openstreetmap/iD/issues/new) die geeignetere Adresse. Vielleicht lassen sich die Kriterien für die Meldungen optimieren.

Schöne Grüsse
LI

Ich habe mir tatsächlich nicht die gesamte Region (bzgl. welches Schema verwendet wird) angeschaut. Vermutlich auch deswegen, weil häufig eine Mischung aus beiden Schemen besteht.
Verzeihung falls es bei Dir Frust erzeugt hat, das war tatsächlich nicht meine Absicht. Falls Du mit dieser Variante nicht zurecht kommst, ändere es gerne wieder um. So wichtig ist es für mich nicht.

Generell habe ich schon Interesse an diesen Verbindungsstücken und trage daher einige Sachen (lanes, destinations, turn vs. turn:lanes, "mit _link vs. "ohne _link", etc ... ) gerne nach.
Dann ist die Angabe der Klassifizierung meist nur eine Eigenschaft unter vielen.
Ich denke das Schema könnte mal wieder im grösseren Rahmen besprochen werden mit dem Ziel bestenfalls einen Konsens zu finden. Viele Grüsse

>> Das lässt sich auch nicht praktikabel manuell nachträglich sortieren.
> ... , gehe aber davon aus, dass man die Mitglieder zumindest manuell sortieren kann.

Ja, man kann die Mitglieder manuell sortieren (und tatsächlich ausschiesslich manuell). Nein, man kann die Mitglieder bei einer langen Mitgliederliste (wie es bei PTv2-Routerelationen gewöhnlich der Fall ist) _nicht_ praktikabel (/komfortabel//in angemessenen Zeitraum) sortieren. Wenn Du das selbst kennenlernen möchtest, probiere gerne mal an dieser Beispielrelation (osm.org/edit?relation=3554349#map=13/50.7579/6.1125) beispielhaft die unteren 3 Wegsegmente nach oben an den Anfang der Liste zu sortieren(/verschieben) :-)

Hallo aachso,

danke - jetzt verstanden.

Die Sache mit den "Fahrrad ... entgegen Einbahnstraße ... linker Gehweg" (sidewalk:right:bicycle=yes) ist mir neu - hatte ich noch nie erfasst.

Ja, wie gesagt, derzeit ist es (way/976283241) recht allgemein eingetragen und sollte tatsächlich mal vor Ort angeschaut werden. Hier auf dem mapillary-Bild (https://www.mapillary.com/app/?pKey=299740271631034&focus=photo&lat=50.782233123353&lng=6.0888306760479&z=17) sieht der obere Teil des Wegstückes aus, als ob es ein reiner Fussweg ist.

Viele Grüsse
LI

Danke für Info'.
War ein Versehen, habe es geändert, siehe:
changeset/110523158

Hallo aixbrick,
danke fürs Drüberschauen. Kenne die Tabelle und auch das sie nicht so wirklich stimmig ist und daher diskutiert wird.
Meine Einteilung ist so: (wenn zwei Straßenstücken unterschiedlicher Klasse verbunden werden) sind die Links mit der niedrigeren Klasse vergeben, außer bei den Stellen bei denen die Links z.B. wegen Schildern (
osm.wiki/DE:Tag:traffic_sign%3DDE:330.1
osm.wiki/DE:Tag:traffic_sign%3DDE:331.1
osm.wiki/File:Kilometerstein-B172-s%C3%B6Krietzschwitz.jpg
) eindeutig zu der höheren Klasse gehören.
Schöne Grüsse
LI

Danke für Erledigungsinfo', na dann war es hoffentlich nicht so aufwendig.

Ich hoffe ich hatte keine Lücken reingebaut (darauf achte ich meist). Falls es um Sortierung einer PTv2 Route ging und diese zudem noch Schleifen enthält, gibt es wohl beim iD-Editor bekannte Anordnungsunstimmingkeiten der Mitgliederreihenfolge. Das lässt sich auch nicht praktikabel manuell nachträglich sortieren.

Ansonsten gibt es dazu hier paar Info's:
route=bus#Sorting_and_robustness_of_member_order_-_editor_support

Und im entsprechenden Github-Ticket:
https://github.com/openstreetmap/iD/issues/4876

Ach, jetzt habe ich es auch per mapillary entdeckt, und gleich noch paar Details (Zeichen und zulässige Abbiegerichtung) angefügt.
Danke nochmal!

doch=dort

Hallo atz,
danke für Info'.
Ich vermute Du meinst dieses Wegstück:
https://pewu.github.io/osm-history/#/way/964632264

Das kam mal rein durch user:eugen741 per Quelle 'bing', allerdings ist es doch nicht zu sehen, wie auch auf den neuen Bilder von Esri. Aber wenn ihr beide das Stück kennt dann wirds das schon geben :-)

Habe es soeben wiederhergestellt, siehe Änderung:
changeset/110518922

Schaue gern nochmal drüber.

Danke & schöne Grüsse
LI

Hallo aachso,

danke das Du mal drüber geschaut hast. Ich verstehe nicht ganz worauf Du hinaus willst. Ich habe die Wege recht allgemein (so weit mir bekannt anhand Luftbilder) eingetragen, falls Du es genauer weisst und es konkretisieren kannst/möchtest wäre ich froh.

Viele Grüsse
LI