Hei CallMeDinsdale,

you have added oneway=yes to this way osm.org/way/330804670
It has also some lane tagging, i.e. lanes=3, lanes:forward=2 and lanes:backward=1, so it is now inconsistant with the oneway=yes. Could you please check and correct the lanes?

Bye,
Rainer

Hallo muc-osm,

bitte für Packstationen nicht die addr:-Tags verwenden. Für Objekte, die nicht selbst eine Adresse haben, sondern sich in der Nähe einer Adresse befinden, gibt es object: anstelle von addr: mit ansonsten demselben Schema city/postcode/street/housenumber.
Siehe osm.wiki/DE:Key:object

Hallo belladonna,
ich bin auch gerade auf diesen Änderungssatz gestoßen, zwar aufgrund überlappender Wege, aber hier nennst du borisbw als Quelle. Darin sind verschiedenste Geodaten enthalten, deren Lizenzbedingungen nicht für OSM passen. Meines Wissens ist in BW nur Maps4BW für die Nutzung in OSM freigegeben. Das kann als Hintergrund in den Editoren iD und JOSM eingeblendet werden und enthält keine Flurnamen. Die Nutzungsbedingungen auf BorisBW sind recht restriktiv und erlauben m.E. keine Verwendung für OSM.
Viele Grüße,
Rainer - nicht derselbe wie rainerU ;)

Korrektur:
source=Survey; Maps4BW (LGL-BW, www.lgl-bw.de); Maxar Premium Imagery

Ah, danke, dem Entkleben von linienförmigen und flächigen Elementen kann ich nur beipflichten. Das erschwert die weitere Bearbeitung oder produziert auch unbeabsichtigte Fehler.
Somit ist die Ursache geklärt :)
Mir scheint, iD warnt nicht bei doppelten Landuse-Punkten. Bin nicht der iD-Spezialist, vielleicht kennt jemand eine Möglichkeit? Daher, denke ich, hast du das nicht bemerkt.

Danke auch für die schnelle Antwort und das Abarbeiten. Vielleicht schnappe ich mir auch noch ein paar.

Viele Grüße,
Rainer

Hallo ticki_52,
in diesem und wahrscheinlich weiteren Änderungssätzen hast du eine Menge doppelter Punkte erzeugt (Punkte, die an derselben Position übereinander liegen). In dem Kartenausschnitt, den ich vorhin im JOSM geladen hatte, habe ich ca. 120 solche Doubletten zwischen Backnang und Steinbach bereinigt, aber in der Gegend gibt es viel mehr: https://ibb.co/B2hfPtx

Eigentlich setzt der iD-Editor gemeinsame Punkte, wenn man eine Landuse-Fläche entlang einer anderen zeichnet. Hast du evtl. Landuse-Flächen markiert und versehentlich die Taste "d" gedrückt? Das würde die gemeinsamen Punkte zu solchen Punkt-Pärchen machen. Man braucht das nur, wenn man zwei Flächen trennen will, weil man z.B. etwas dazwischen einfügen will.
Es wäre gut, wenn du der Ursache auf den Grund gehst, denn wie man sieht, wimmelt es in der Gegend nur so von doppelten Punkten.

Viele Grüße,
Rainer

Hier noch der Link zu Osmose, es kann aber evtl. etwas dauern bis alle Marker im Kartenausschnitt angezeigt werden: http://osmose.openstreetmap.fr/de/map/#zoom=15&lat=48.94556&lon=9.46914&item=1010,1050,1060,1070,1090,1110,1120,1140,1150,1180,1190,1200,1210,1221,1230,1250,1260,1270,1280,1290,2xxx,3xxx,4xxx,5xxx,6020,6030,6040,7xxx,8xxx,9000,9001,9002,9003,9004,9005,9006,9007,9009,9010,9011,9014,9015,9016,9017,9018,9019,9020&level=1,2,3&tags=geom&fixable=

Korrigering:
source= OSM Inspector geometry

Hallo townlion,

der Weg osm.org/way/285561867 war schon kartiert, den von dir hinzugefügten osm.org/way/1105576559 braucht es nicht. Auch beim Weg osm.org/way/268123051 war schon alles richtig, nun ist das erste kurze Stückchen doppelt (osm.org/way/286132292 seit 8 Jahren da).
access=private geht nicht bis Straßenmitte, insofern war das hier schon sehr detailliert gemappt.
Ich mache die Änderungen an diesen beiden Wegen mal rückgängig.

Viele Grüße,
Rainer

Hallo GekkoRider,

du hast hier die neue Straße über den Feldweg drüber gezeichnet, so dass nun beide übereinander lagen. Das habe ich korrigiert und außerdem den tracktype für den Abschnitt des Feldwegs, bei dem du surface=ground ergänzt hast.
Richtige Editoren wie iD oder JOSM warnen bei solchen Fehlern, Go Map!! scheinbar nicht.

Viele Grüße,
Rainer

Ups, ja, habe ich übersehen. Hab's bereinigt, aber die Webseite aktualisiert.

Servus,
Rainer

Hallo PriNahr,
willkommen bei Openstreetmap! Super, dass du zur Vervollständigung der Geodaten bei OSM beiträgst.
Ein paar Hinweise möchte ich dir geben:
bei deinen Bearbeitungen sind ein paar doppelte Punkte entstanden, d.h. Punkte, die an derselben Position übereinanderliegen. Zwei Flächen, die aneinandergrenzen, sollten entlang ihrer Randlinien gemeinsame Punkte haben. Der Editor verschmilzt die eigentlich auch, evtl. hast du versehentlich solche Punkte markiert und die Taste d gedrückt? Das spaltet einen gemeinsamen Punkt in zwei auf und wird verwendet, wenn man den Punkt nur für eine der Flächen verschieben will.
Der iD-Editor (im Browser) warnt übrigens davor. In der Statusleiste rechts unten gibt es dann eine orange Fläche mit ! im Dreieck und der Zahl der gefundenen Fehler. Da kann man drauf klicken und bekommt eine Liste angezeigt, die man nach "meine Bearbeitungen" filtern kann. Wenn man dann einen der Fehler anklickt, erscheint links eine Auswahl der Lösungsmöglichkeiten.

Als ich zur Korrektur den Kartenausschnitt geöffnet habe, bekam ich noch einige weitere Warnungen angezeigt (ich arbeite mit dem Editor JOSM, der für einige detailliertere Bearbeitungen Vorteile bietet), nämlich überlappende Landnutzungsflächen. Und da möchte ich einen zweiten Hinweis loswerden: der Konsens in der OSM-Gemeinde ist, Flächen nicht mit linienförmigen Elementen zu verkleben, also z.B. landuse nicht mit highway oder waterway. Hintergrund ist, dass linienförmige Objekte in der Realität eine Breite haben, d.h. z.B. landuse=farmland geht nicht bis Straßenmitte, sondern endet neben der Straße. Außerdem erleichtert dieses Vorgehen späteres Bearbeiten.
Weiter viel Spaß bei OSM :)

Viele Grüße,
Rainer

Hallo Silberner See,
hier in Frielendorf habe ich einige doppelte Punkte, genauer gesagt Punkte, die doppelt in einer Linie vorkommen, korrigiert. Dafür kannst du nichts, das ist leider ein unschöner Bug des Editors Go Map!!. Zum Bearbeiten von Flächen und Wegen ist es besser am PC mit den Editoren iD (im Browser) oder JOSM zu arbeiten. Im Qualitätssicherungstool OSM Inspector sah das so aus: https://ibb.co/JvnnnqR

Und sicherlich ist dir auch schon aufgefallen, dass sehr viele Gebäude in dem Ort nach einem verschobenen Luftbild eingezeichnet wurden. Die stammen aus 2018 / 2019. Inzwischen sind ja die die Hessen DOP 20 Luftbilder verfügbar und dürften hier die zuverlässigste Quelle sein. Da ist wohl viel Überarbeitungsbedarf hier in Frielendorf.

Viele Grüße,
Rainer

Hallo Norbert59,
bei osm.org/way/975812962 hast du ja schon barrier=fence gesetzt. name=Zaun ist überflüssig und falsch, weil name nur für Eignnamen verwendet wird. Siehe auch osm.wiki/DE:Namen#name_ist_nur_der_Name

Servus,
Rainer

Uriweg und Malojaweg sind keine Fußgängerzone, da steht kein Zeichen DE:242, also kein highway=pedestrian.

Hallo AP_MUC,

willkommen bei OSM!
Dein Kommentar an diesem und anderen Änderungssätzen ist immer nur "fußwege". Guter Stil bei OSM ist, in diesem Kommentar zu erläutern, was man warum geändert hat. Damit können andere leichter verstehen, was deine Intention ist. Siehe auch osm.wiki/DE:Good_changeset_comments

Hier konkret sehe ich Gehsteige neben schon kartierten Gehsteigen neu eingezeichnet, z.B. entlang der Graubündener Straße. Da würde ich dich bitten, dich erstmal eingehend mit dem Getrennt-Mappen von Straße, Rad- und Fußwegen zu befassen. Das ermöglicht sicher genaueres Kartieren von Bordsteinen, Übergängen, Oberflächen usw., aber es erfordert auch besondere Sorgfalt, um Routing nicht kaputtzumachen und es müssen ggf. an der Straße, zu der der Gehsteig gehört, Attribute (Tags) gesetzt werden, die Anwendern der OSM-Daten mitteilen, dass der Gehsteig separat gemappt ist.
Zu beachten ist auch, dass Straßen, bei denen keine bauliche Trennung zum Gehsteig vorliegt (der Randstein gilt nicht als bauliche Trennung), meist sidewalk=left|right|both und teils auch die zugehörigen surface-Tags haben, was dann auf die separten Wege übertragen werden muss.

Außer dem Kommentar am Änderungssatz sollte auch immer die Quelle für die Änderungen angegeben werden. Wenn du mit dem iD-Editor arbeitest, gibt es direkt unter dem Feld "Änderungssatz-Kommentar" die Möglichkeit ein Feld hinzuzufügen, wobei "Quellen, Hashtags" schon als Auswahlmöglichkeiten sichtbar sind. Bei vor-Ort Erkundung wird gerne der englische Begriff Survey verwendet, aber man kann da natürlich auch "Radtour durch Fürstenried" oder passendes schreiben.

Viele Grüße,
Rainer

Hallo Michael,

das ist leider nicht so einfach. Mehrere place-Knoten "Schwabmünchen" zu platzieren, damit die näher liegen als der place-Knoten von Mittelstetten hätte dann andere Rückwirkungen, z.B. dass Schwabmünchen mehrfach auf Karten erscheint.
Ein solches Vorgehen, Daten irgenwie hinzubasteln, damit in einer Anwendung, hier die Nominatim-Suche auf osm.org, ein gewünschtes Ergebnis erzielt wird, ist bei OSM unerwünscht, weil damit unter Umständen andere Nutzer der Daten aus der OSM-Datenbank Probleme bekommen können.
Es ist grundsätzlich nicht möglich die Zugehörigkeit eines Objekts zu einer Fläche anhand des Abstandes zu einzelnen Punkten zu bestimmen. Dafür braucht man die Fläche bzw. hier die Grenzlinien, die die Fläche definieren. D.h. wenn man Grenzlinien für den Kernort Schwabmünchen, Mittelstetten und die anderen Ortsteile hätte, ließe sich die Lage einer Straße innerhalb einer solchen Grenzlinie eindeutig bestimmen. Die Nominatim-Suche wendet halt eine Pi x Daumen-Regel an, die bei fehlenden Grenzlinien ein meist, aber eben nicht immer brauchbares Ergebnis liefert.
OSM hat 2010 die bayerischen Gemeindegrenzen als Datenspende bekommen: osm.wiki/Bayern/Gemeindegrenzen-Spende-2010
Darin sind aber nur die Gemeinden selbst, nicht deren Untergliederungen enthalten. Es gibt also keine offizielle und verwendbare Quelle dafür. Vor Ort sind solche Grenzverläufe nicht sichtbar. M.E. bleiben nun zwei Möglichkeiten:
- von der Gemeinde die Grenz-Daten mit passender Lizenz (am besten Datenlizenz Deutschland Zero) bekommen
- die Grenzlinien mit lokalem Wissen grob einzeichnen (mit Vermerk, dass nur geschätzt)

An anderer Stelle habe ich mal geprüft, dass das funktioniert. In München gibt es die Grenzlinien für Stadtbezirke und Bezirksteile. Die Albert-Schweitzer-Straße überquert für ein kleines Stück die Grenzlinie, daher findet die Suche den Abschnitt, der in Neuperlach liegt, mit diesem Bezirksteil und den Abschnitt, der die Grenze zu Gartenstadt Trudering überquert, mit beiden Bezirksteilen.

Fazit: ein sauberes Suchergebnis für Ortsteile gibt es nur, wenn deren Grenzlinien erfasst sind.
Bei weiter entfernten Ortsteilen funktioniert die Zuordnung via Entfernung zum place-Knoten gut, aber bei aneinandergrenzenden Ortsteilen nicht so gut.

Viele Grüße,
Rainer

Korrektur: source= Maxar Premium

Die Daten in OSM waren schon korrekt.
Es liegt an der Art wie die Suche funktioniert. Orte, die mit place erfasst sind, werden in einem bestimmten Umkreis mitberücksichtigt. Je nach Bedeutung des place-Knotens sind bestimmte Abstände definiert. Die Augsburger Straße reicht nah genug an Mittelstetten heran, so daß die Suche den Namen Mittelstetten mit ausgibt.
Gegenbeispiel: die Höfatsstraße im Süden von Schwabmünchen ist weiter weg und bekommt Mittelstetten nicht in der Ergebnisliste.

Mehr dazu: https://nominatim.org/release-docs/latest/customize/Ranking/

Das Herumbasteln an Landuse-Attributen bringt nichts außer Fehlermeldungen in QS-Tools.

Viele Grüße,
Rainer

Dank :)
Ich habe nun den Text auf der Wikiseite bzgl. der Angabe des Schätzwertes etwas verbessert, so dass (hoffentlich) weniger Unsicherheit aufkommt.

Wenn man die Seite im Quelltext editiert, sieht man, dass dort {{key|seats}} steht, woraus dann in der Wikdarstellung seats=* vor hellblauem Hintergrund wird. Will man den Schlüssel mit zugewiesenem Wert haben, wird z.B. {{tag|seats|5}} geschrieben. D.h. der letzte Bearbeiter hatte nicht im Sinne das * als Wert für seats zu definieren.

Servus,
Rainer

Hallo jngt,

danke für den Hinweis, woher du das Sternchen hast.
Das ist aber wohl ein Missverständnis. * wird als Platzhalter für irgendeinen Wert verwendet, es ist nicht buchstäblich * als Wert zu setzen. Das gilt für alle Beschreibungen im Wiki, z.B. amenity=*, building=* oder auf der Wikiseite zu seats direction=*.

Die Ergänzung der Beispiele auf der seats-Wikiseite sind von einem neuen Mapper; wenn sie für jemanden, der die Platzhalterfunktion des * nicht kennt, tatsächlich so missverständlich sind, muss man das evtl. mal präzisieren.
Der Link zu taginfo im Kästchen rechts auf der Wikiseite führt zu den für den Schlüssel seats verwendeten Werten; gefiltert nach * kommt es weltweit 9 mal vor: https://taginfo.openstreetmap.org/tags/seats=*
Über den dortigen Link zu Overpass turbo https://overpass-turbo.eu/?w=%22seats%22%3D%22*%22+global&R kann man diese 9 Fälle finden, sechs davon sind von dir.

Servus,
Rainer