Bitte beachte, dass "(in Bau)" kein Namensbestandteil ist und daher weggelassen werden sollte.

Deine Antwort basiert also nicht auf Ortskenntnis oder Ortsbefahrung, sondern auf einer reinen Anwendung eines Regelwerks, das nicht immer 1:1 angewendet wird?

Welche deiner Quellen sagt das?

Das tun die amtlichen Daten meistens auch, trotzdem ist die Nutzung amtlicher Daten in OSM in Sachsen nicht erlaubt. Dasselbe gilt für die Daten der DB.

Siehst du das anders oder warum sollten Daten der DB Netz Infrastrukturdatenbank eine legale Quelle darstellen?

Die Daten der DB enthalten auch Fehler, wie man mir selbst neulich bei einem Gespräch in Frankfurt mitgeteilt hat.

Warum hast du in diesem Änderungssatz changeset/33645558 revertiert? Wie ich im Changeset-Kommentar schrieb, ist "DB Netz Infrastrukturdatenbank" eine unzulässige Quelle.

Könntest du die Tracks, falls noch nicht geschehen, bitte nochladen? osm.org/trace/create

Dann kann nämlich jeder den Offset nachvollziehen. Bevor ich im großen Stil mit einem Luftbild Sachen verschiebe, lade ich mir erstmal die Tracks der Gegend herunter (in dem Fall wäre es ganz Parchim gewesen). Leider sieht es im Bahnhofsumfeld recht dünn aus. (Da Tracks einen nicht geringen Fehler haben, schenke ich ihnen erst Glauben, wenn ein ganzes Bündel von ihnen auf einer Straße vorhanden ist und ich den Fehler durch Mittelung reduzieren kann).

I think that values of maxspeed, maxweight, maxwidth etc. should have the unit they have in reality. If maxweight is signed in US tons on US roads, it should be tagged as US tons.

Every data users who wants to show the maxweight value in US tons (the original unit used on the signs) has to convert and round your metric tons value back to US tons just because one developer did not want to write code to convert US tons into metric tons.

Unit/Coordinate transformations are often lossy. That's why the original unit should be preferred. It is not difficult to convert units. You just have to hold a list of units and their conversion factor.

When do you propose to convert all UK maxspeed=* to kph?

Hallo luchs12,

du hast in diesem Änderungssatz zahlreiche Objekte um mehrere Meter verschoben und gibst als Quelle "Luftbilder" an. Um welche Luftbilder handelt es sich denn, die du verwendet hast?

Viele Grüße

Michael

Da das Signal, wie du geschrieben hast, keine Eintagsfliege ist, hättest du es ruhig richtig taggen können. ;-) Die JOSM-Vorlagen kennen das Lf 1.

Du kennst hoffentlich den Unterschied zwischen Lf 1 ("Langsamfahrscheibe") und Lf 1/2 ("Langsamfahrbeginnscheibe")?! Hab ich dich mit meinem anderen Kommentar verwirrt? Wenn ja, dann bitte ich um Entschuldigung. Das Lf 1/2 (DV 301) steht in Bahnhöfen und dort nicht an durchgehenden Hauptgleisen. (siehe Ril 301.0501) http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf

Wenn du Videomapping gemacht hast, darfst du gerne das alles korrigieren. Ich habe bloß mit meinem Samsung Galaxy S5 (kann GLONASS und ist empfangsstark) mit OSMTracker gemappt. Wie du vielleicht selbst aus eigener Erfahrung weißt, ist ein 628er kein Ort guten GPS-Empfangs.

Ich vertraue daher dir und deinem Video.

Upps, das "herzlich willkommen" hätte ich erst schreiben sollen, nachdem ich einen Blick auf deine User-Seite geworfen habe.

Hallo openjeki,

herzlich willkommen bei OSM.

Leider musste ich diesen Changeset teilweise rückgängig machen. Schau dir am besten das grafische Diff an und lies danach das, was ich dir im Folgenden dazu erkläre. http://overpass-api.de/achavi/?changeset=34669307

Du hast in diesem Änderungssatz Gebäude verschoben, deren Lage schon recht gut war. In Baden-Württemberg dürfen wir Maps4BW vom LGL benutzen. Maps4BW enthält die Gebäudeumringe des Liegenschaftskataster und ist daher deutlich lagegenauer als Bing und Mapbox. Maps4BW ist ein WMS-Dienst, iD kann kein WMS, wenn du in BW Gebäude mappen willst, musst du JOSM benutzen.

Bitte beachte außerdem, dass Luftbilder nie exakt senkrecht aufgenommen werden und man daher Gebäude meist von der Seite sieht. In solchen Fällen zeichnet man das Dach ab, verschiebt das Polygon aber anschließend auf die Position am Boden. osm.wiki/DE:Roof_modelling

Außerdem hast du in diesem Änderungssatz ein Stützpunkt eines Bahngleis um ca. 0,4 km verschoben und mit einem anderen Gleis verbunden. Bitte sei beim Editieren vorsichtig. OSM ist kein Spielplatz.

Noch ein Hinweis zum Schluss: Luftbilder sind nie ganz aktuell. Bitte lösch/ändere nicht einfach Dinge, die zum Luftbild nicht passen. Meist hat sich der Mapper etwas dabei gedacht und entweder ein note=* am Objekt hinterlassen ("Alle Tags" in iD aufklappen).

Viele Grüße

Michael

Ja, dauerhafte Langsamfahrstellen sind relevant.

Ist diese Langsamfahrstelle über mehrere Jahre hinweg mit Lf 1, Lf 2 und Lf 3 signalisiert (gewesen)? Ich bin bisher davon ausgegangen, dass die Mehrheit (oder alle) Lf 1–Lf 3 temporärer Natur sind. Wenn die La nicht behoben wird, werden sie halt nach einiger Zeit durch Lf 6/L 7 ersetzt. So zumindest mein bisheriger Kenntnisstand. Deshalb habe ich mich bisher auch nicht um diese Signale gekümmert und keine Icons dafür gezeichnet.

Du hast dich bei diesem Signal vermutlich verklickt. node/1600332293/history

Das Lf 1/2 gibt es nur in Ostdeutschland, du meintest vermutlich das Lf 1. Ich persönlich mappe keine Lf 1, Lf 2 und Lf 3, wenn ich nicht eine zeitnahe Aktualisierung sicherstellen kann. Diese Signale sind vergleichbar mit mehr oder minder kurzzeitigen Straßenbaustellen. Deshalb habe ich es auch nicht umgetaggt.

Das Lf 1/2 (DV 301) mappe ich übrigens, weil ich beobachtet habe, dass solche Schilder Ewigkeiten stehen und also deutlich dauerhafter als Lf 1 bis 3 sind.

Bist du dir sicher, dass vom Nordportal des Koppelsbergtunnel (südl. Gaildorf West) aus Richtung Schwäbisch Hall-Hessental 120 km/h erlaubt sind? Meine Notizen meinen, dass da ein Lf 7 100 km/h stünde, du hast 120 getaggt. node/2787097861/history

Falls du deine Notizen von damals noch hast, wäre es nett, wenn du nochmals nachschauen könntest.

Du hast in diesem Änderungssatz ein Multipolygon erzeugt, das unnötig und invalide ist. Jedes Mitglied eines Multipolygons MUSS eine Rolle haben. Äußere Ringe (die Mitglieder mit der Rolle outer) dürfen sich nicht berühren oder schneiden.

Bitte beachte die Warnungen des JOSM-Validators, die vor dem Hochladen erscheinen. Sie sind ernst gemeint (außer bei ÖPNV-Sachen, da ist noch vieles im Argen, die darf man ignorieren). Du kannst die Validationsregeln, falls sie bei dir ausgeschaltet sind über F12 -> blauer Haken einschalteen.

http://tools.geofabrik.de/osmi/?view=multipolygon&lon=9.87639&lat=49.83149&zoom=18&opacity=0.45&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines

Du hast in diesem Änderungssatz ein Multipolygon erzeugt, das erstens völlig unnötig und sinnfrei ist und zweitens invalide es. Die äußeren Ringe des Multipolygons berühren sich. Das ist ein grober Geometriefehler.

Mir ist in der Vergangenheit aufgefallen, dass solche Fehler fast immer von Nutzern des Online-Editors iD gemacht werden. Um dem Problem auf die Schliche zu kommen, möchte ich dich bitten, zu schildern, was du genau gemacht hast (falls du das noch weißt). Ich meine damit eine Schilderung der Bedienhandlungen (z.B. 1. auf A geklickt, 2. Tag b=c ergänzt usw.)

Im Voraus vielen Dank.

Bitte verwende für Multipolygon-Edits bitte künftig JOSM. iD macht Multipolygone gerne kaputt und warnt dich nicht, wenn du kaputte Daten hochlädst. JOSM hat einen eingebauten Validator und ist für das Editieren von Relationen deutlich besser geeignet.

Du hast in diesem Änderungssatz ein Multipolygon erzeugt, das erstens völlig unnötig und sinnfrei ist und zweitens invalide es. Die äußeren Ringe des Multipolygons berühren sich. Das ist ein grober Geometriefehler.

Mir ist in der Vergangenheit aufgefallen, dass solche Fehler fast immer von Nutzern des Online-Editors iD gemacht werden. Um dem Problem auf die Schliche zu kommen, möchte ich dich bitten, zu schildern, was du genau gemacht hast (falls du das noch weißt). Ich meine damit eine Schilderung der Bedienhandlungen (z.B. 1. auf A geklickt, 2. Tag b=c ergänzt usw.)

Im Voraus vielen Dank.

Bitte verwende für Multipolygon-Edits bitte künftig JOSM. iD macht Multipolygone gerne kaputt und warnt dich nicht, wenn du kaputte Daten hochlädst. JOSM hat einen eingebauten Validator und ist für das Editieren von Relationen deutlich besser geeignet.

http://tools.geofabrik.de/osmi/?view=multipolygon&lon=11.98872&lat=51.75221&zoom=18&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags

Da ich mich der Mehrheit beuge, habe ich die gelöschten note=* und source=* wiederhergestellt. changeset/34836925

source=* habe ich dabei ein wenig angepasst. Bei einer Tafel schrieb bigbug21, ihr Oberleitungsmast sei auf den damaligen Bing-Bildern nicht erkennbar gewesen. Da ich den Masten erkennen kann, habe ich "extrapolation" aus source=* entfernt. "survey" habe ich in "surveys" ergänzt, da die Tafeln zweimal vor Ort gesehen wurden.

Ich werde jetzt meine weiteren Hektometertafel-Changesets entland der Schnellfahrstrecke Würzburg–Hannover durchsehen und auch dort entsprechende Wiederherstellungen vornehmen. Dasselbe gilt für die Schnellfahrstrecke Köln–Rhein/Main.

Ich habe gerade einen Widerspruch zwischen dem, was du gemappt hast, und meinen eigenen Aufzeichungen. Du hast am ESig 16F46 von Weinsberg aus Richtung Heilbronn angegeben, dass dort eine Zs3-Tafel [80] hinge. Am EVSig hast du das entsprechend als Zs3v-Tafel auch gemacht. Meine Aufzeichnungen meinen, dass am EVSig eine Zs3v-Tafel [80] und am ESig eine Zs3-Tafel [80] hinge. Ich habe an den Signalen noch nichts geändert und würde gerne deine Meinung hören.

Btw, die Position des EVSig habe ich korrigiert. Mein 628er kam auch aus dem Tunnel, daher habe ich mangels gutem GPS-Fix einfach die Oberleitungsmasten bis zum Bahnsteig von Weinsberg West gezählt.