Hallo PT-53 und hallo Michael,
danke daß du in die Diskussion gleich mit einsteigst wg. der Auswertung im OSMI.
Die unterschiedliche Zählweise der Fahrradstreifen bei turn:lanes und lanes ist ein gutes Argument und dann fiel mir ein, es könnte ja auch noch psv:lanes geben.
Da taugt dann mein minimalistischer Ansatz nicht mehr und eine allgemeinere Lösung ist besser. Also Angaben in der Hierarchie lanes - lanes:DIR - turn:lanes und sonstige xyz:lanes und möglichst vollständig.
Mittlerweile verwende ich das Plugin /
turnlanes-tagging, das die Tags in dieser Vollständigkeit einfügt, wie ich durch Überprüfung festgestellt habe.
Fazit: lieber ein bißchen Redundanz beim Fahrspurtagging und damit allgemeingültiges Tagging und bessere Überprüfbarkeit.
Viele Grüße,
Rainer

Hallo PT-53,
ich habe lanes:backward=1 nicht anstelle von
lanes:forward=2 verwendet, sondern um die Eigenschaft des dritten Fahrstreifens zu beschreiben. Fahrstreifen 1 und 2 werden durch turn:lanes:forward=through|right beschrieben, Fahrstreifen 3 durch lanes:backward=1.
Für OSMI sind also vermutlich die Informationen aus turn:lanes:xxx und lanes:xxx nicht gleichwertig.
Also wird's dafür vermutlich zusätzlich (nicht anstelle von lanes:backward) lanes:forward brauchen. Im Grunde ist das redundante Information.
Viele Grüße,
Rainer

Hallo Christian,
ah super, das sieht gut aus. :)
Servus,
Rainer

Hallo FirefighterCGH,
was ist denn das für ein seltsames Wasserschutzgebiet?
relation/11082637
Ein solches Schutzgebiet muß ein geschlossenes Polygon sein. Evtl. ist es noch nicht fertig?
Es darf auch keine Abschnitte haben, die von der Polygonlinie abzweigen. Die Wege, die man dafür verwendet, müssen ggf. aufgeteilt werden und nur das notwendige Stück in die Relation eingefügt werden.
Servus,
Rainer

Hallo Andy,
nein, das ist kein Survey. Die Hausnummern stammten aus dem Bayernatlas. Vor Ort werden gerade einige Häuser gebaut und es ist überhaupt noch keine Hausnummer angeschrieben, von 2, 3 Ausnahmen abgesehen. Vor Ort nicht ermittelbare Hausnummern aus anderer Quelle einzutragen ist kein Survey, auch wenn man durch die Straße gefahren ist.
Servus,
Rainer

Hallo Andy,
danke für die Antwort. Das ist leider, was ich befürchtet habe. Der Bayernatlas ist eine unzulässige Quelle, siehe https://geoportal.bayern.de/geoportalbayern/seiten/nutzungsbedingungen.html speziell Punkt 3.3.
Daher revertiere ich diesen Änderungssatz.

Servus,
Rainer

Hallo mappy123,
die Adressen in Abrain waren doch mit addr:place + addr:housenumber korrekt gemappt, da es in dem Weiler keine Straßennamen gibt. Daraus addr:street + addr:suburb zu machen, halte ich für falsch. Siehe osm.wiki/DE:Key:addr#.C3.BCbliche_Adressebenen .
Das würde ich wieder zurückbauen.
Diese 4 Adressen:
way/104831293
way/104831283
way/104831279
way/104831286

Servus,
Rainer

Hallo sirach,
mit node/3778490363 scheint etwas schiefgegangen zu sein; die Adresse war doch vorher mit Schillerstraße 9 korrekt?
Servus,
Rainer

Hallo pgoerti,
willkommen bei OSM!
Auf diese Änderung bin ich gestoßen, weil in addr:street die Hausnummern standen. In addr:housenumber waren sie auch (richtig), aber in addr:street gehört der Straßenname.
Ich habe das korrigiert und die Adressen einzeln auf die Eingänge gelegt wie das bei den Nachbargebäuden auch gemacht ist.
Aber vermutlich geht das mit Streetcomplete nicht, man wird nur Angaben an bestehenden Objekten hinzufügen können.

Viele Grüße,
Rainer

Hallo AndySchulte,
bei diesem Änderungssatz ist werder Kommentar noch Quelle angegeben, daher die Frage, aus welcher Quelle du die Adressen hast. Vor Ort gibt's die nämlich teils (noch) gar nicht.
Bitte schreib immer einen Kommentar und die Quelle dazu, das macht's anderen Mappern leichter nachzuvollziehen, welche Änderungen vorgenommen wurden. JOSM fragt da ja ausdrücklich nach.

Gruß,
Rainer

Hallo Rafael MN,
wenn dieses Fitnessstudio die Hausnummer 180 hat, müßte es 50 m weiter stadtauswärts sein. Warst du vor Ort und kannst die Position korrigieren? Oder stimmt die Position, aber nicht die Hausnummer?

Und noch eine Bitte, achte auf die richtige Schreibweise des Straßennamens, hier "Dachauer Straße" und in anderen deiner Edits -straße und nicht -strasse.

Servus,
Rainer

Hallo Toni,
das building_1 habe ich gar nicht bemerkt. Ist wohl ein iD-Artefakt. Das habe ich nun bereinigt.
Zu dem privaten gelöschten Tierarzt kann ich nichts sagen.
Und das tourism=attraction, nun ja, das ist sicher Ansichtssache. Die Kriterien für die Benutzung des Tags sind mir nicht klar. Wenn man will, kann man die Karte damit zupflastern.

Servus,
Rainer

Hallo koastoas,
bei diesem Änderungssatz war das Häkchen bei "ich möchte, dass jemand meine Bearbeitungen überprüft" gesetzt, daher antworte ich.
Du hast bei der Münchner Straße maxspeed ergänzt. Wenn die Geschwindigkeit in beiden Richtungen gleich ist, genügt es maxspeed=* zu setzen. maxspeed:forward und maxspeed:backward hingegen sind für die Fälle, in denen die Geschwindigkeit in beiden Richtungen unterschiedlich ist.. Sprich: entweder nur maxspeed=* oder maxspeed:forward und maxspeed:backward.
Da du mit JOSM editierst, hast du ein gutes Werkzeug, um solche Fehler zu erkennen: den Validator. Ein-/ausschalten kannst du ihn mit dem blauen Häkchen links in der Werkzeugleiste. Eingeschaltet siehst du ein Fensterchen rechts bei den Bedienfeldflächen. Darin dann den Button "Prüfung" betätigen. Da wird unter anderem "verdächtige Merkmalskombination - Gleicher Wert von maxspeed:forward, maxspeed:backward und maxspeed, dafür maxspeed benutzen (4)" angezeigt und die betroffenen Linien markiert. Wenn man die Fehlerkategorie aufklappt, werden die einzelnen Elemente angezeigt und man kann mit rechter Maustaste + "Auf Problem zoomen" gezielt zu dem Element kommen, das angemeckert wird.
Der Validator unterscheidet zwischen Fehlern und Warnungen. Fehler sollte man unbedingt beheben und Warnungen mit gesundem Mapperverstand anschauen. Oft sind es Fehler, aber auch oft nur scheinbare Fehler. Häufig sieht man z.B. "Linienende nahe anderer Straße". Da kann es sein, daß die Linien verbunden sein sollten (dann ist es ein Fehler) oder auch so sein, daß es keine Verbindung zwischen dem Wegende und dem Weg in der Nähe gibt (dann ist es kein Fehler).
Ich lasse oft die Prüfung laufen, wenn ich ein Gebiet heruntergeladen habe, um den Anfangszustand zu sehen und ggf. Fehler erst zu beheben, bevor ich editiere und danach wieder, damit ich meine Fehler angezeigt bekomme.
Viele Grüße,
Rainer

Hallo Hardl_MC,
was ist denn daran falsch? Zuvor war es durchaus richtig mit leisure=swimming_pool kartiert. Wenn es darum geht, daß das Schwimmbecken momentan gesperrt ist, läßt sich das entweder mit den Covid-Tags oder mit access abbilden.
Servus,
Rainer

Hallo Christpoh,
danke für den Hinweis. Bei OSM schreiben wir Namen üblicherweise aus. Das hat den Hintergrund, dass Maschinen (z.B. für Kartendarstellung, Routing, Adressensuche) vom ausgeschriebenen Namen auf Abkürzungen schließen können, es aber umgekehrt oft nicht eindeutig ist. DR. für Doktor ist da sicher unproblematisch, aber z.B. bei St. wird's schwierig, Sankt, Stefan, auch Saint in D ist mir schon untergekommen.
openstreetmap.org schreibt Namen wie sie in name=* stehen, openstreetmap.de setzt das in gebräuchliche Abkürzungen um, wenn du mal die beiden Karten an der Stelle vergleichen willst.
Viele Grüße,
Rainer

Hallo olh,
bist du sicher, daß die Adresse hier Richtersgraben 20 ist? Die Straße Richtersgraben liegt doch in Cadolzburg. Zautendorf scheint keine Straßennamen zu haben und müßte daher nicht addr:street, sondern addr:place=Zautendorf bekommen.
Das betrifft dann alle Adressen hier in Zautendorf. Du hast ja für jede Adresse einen eigenen Änderungssatz gemacht, daher kommentiere ich hier exemplarisch.

Servus,
Rainer

So, 15 Konflikte, die sich aber alle lösen ließen. Damit sollte das erledigt sein.

Hui, ich stelle gerade fest, daß hier eine Route gezeichnet werden sollte, indem highway=path über die Straßen drüber gelegt wird. Das ist so nix und wird andere verwirren. Ich versuche mal das zu revertieren.
Viele Grüße,
Rainer

Hallo eiskalt-glasklar und Michael,
ich hatte u.a. GTFS-Daten herangezogen, um die Lücken in den Relationen zu verifizieren. Der VRN liefert GTFS-Daten für die 5xxer Linien, beim KVV sind sie jedoch nicht enthalten. Daher habe ich network=VRN eingetragen. Aber sicherlich ist Michaels Vorschlag, das Gebiet als Übergangsgebiet KVV/VRN mit network=KVV;VRN einzutragen, die bessere Lösung. Es ist ja in den Tarifgebietsplänen beider Verkehrsverbünde enthalten.

Viele Grüße,
Rainer

Hallo wermak,
mit addr:suburb=korail ist sicher etwas schiefgegangen; das sollte nach wie vor addr:suburb=Dornach sein.
Servus,
Rainer