Hallo jngt,
danke erstmal für die schnelle Rückmeldung :)
Ja, zweiteres ist schade und ich wünschte, ich hätte es eher gesehen, weil du dir über einige CS Arbeit gemacht hast.
Baden-Württemberg, NRW und Meck-Pomm und Sachsen sind da offener, wie man auf https://regio-osm.de/hausnummerauswertung/maptheoevaluation.html schön sehen kann.
Ich hoffe, du läßt dich nicht entmutigen.
Servus,
Rainer

Hallo Feuerwehr Pocking,
diesen Änderungssatz habe ich revertiert, weil unzulässige Quellen (Bayernatlas und Google) verwendet wurden. Siehe https://geoportal.bayern.de/geoportalbayern/seiten/nutzungsbedingungen.html
Bitte verwendet nur erlaubte Quellen. In Bayern bleibt als zulässige Quelle für Adressen und Straßennamen nur Erfassung der Daten vor Ort. Mühselig, leider.

Servus,
Rainer

Siehe changeset/91386953 .
Revert wegen Nutzung unerlaubter Quelle (Bayernatlas)
Es ist in Bayern leider mühselig: die einzig zulässige Quelle ist Erfassung der Adressen vor Ort.

Servus,
Rainer

Hallo jngt,
der Änderungssatz ist mir aufgefallen, weil viele addr:street hinzugefügt wurden, wo richtigerweise addr:place verwendet wurde. Vielleicht ist dir das nicht so geläufig, weil die Vorlage für Adressen im iD-Editor das addr:place nicht anbietet, es aber anzeigt, wenn es gesetzt ist. addr:place ist in OSM Systematik für solche Adressen, die den Ortsnamen anstelle eines Straßennamens verwenden, siehe osm.wiki/DE:Key:addr und osm.wiki/DE:Key:addr:place

Schwerer wiegt aber, daß du den Bayernatlas als Quelle verwendet hast, was die Lizenzbestimmungen untersagen, siehe https://geoportal.bayern.de/geoportalbayern/seiten/nutzungsbedingungen.html , besonders Punkt 3.3.
Daher muß ich den Änderungssatz zurücksetzen.

Servus,
Rainer

Hallo Dr_Frank,

das Ändern der Adresse bewirkt nicht automatisch, dass der Punkt an die neue Position verschoben wird. Da an der neuen Adresse ein neues Objekt angelegt wurde, sollte dieses hier gelöscht werden.

Viele Grüße,
Rainer

Das hatte ich schon in changeset/90944425 repariert, den Laden als Punkt an der neuen Adresse angelegt node/7910169915 und in changeset/89305075 kommentiert.

Kopfschüttelnd,
Rainer

Hallo,
ich habe die Attribute vom Gebäude gelöst und als Punkt nach Rauschenberg verschoben. Dort sind noch keine Hausnummern erfaßt, daher ist ddie Position in der Bahnhofstraße geschätzt. Bitte prüfen und ggf verschieben (als Punkt sollte das einfacher sein).
Grüße,
Rainer

Du warst schneller mit den Meldungen :) war mir gestern zu spät.
Nun sind die Rad-/Feldwege jedenfalls nicht mehr als construction drin und stehen dem Radrouting zur Verfügung.
Mit dem Abschnitt der St2032 wird's sicher noch ein paar Monate dauern. Die unterste Asphaltschicht war hier schon zu sehen, aber wie es auf der gesamten Strecke aussieht, kann ich nicht sagen.
Servus,
Rainer

Hallo Limes,
deine Nachricht erreichte mich heute gerade, bevor ich auf der A8 unterwegs war und so bin ich spontan abgefahren und habe mir den aktuellen Stand angeschaut. Das Ziel der Baumaßnahmen ist die Ortsumgehung für Adelsried und Kruichen. In Betrieb ist der Abschnitt Welden - Abzweig Ehgatten bis Weg way/769462054. In Bau ist Weg way/265225236. Die Anbindung der Kreisstraße A33 von Streitheim her ist wie eingezeichnet und trifft im rechten Winkel auf die im Bogen verlaufende St 2032.
construction=track ist schon richtig. Die Wirtschafts- und Radwege wurden neu trassiert, sind aber jetzt fertig. Ich bin ein Stück abgelaufen und habe eine GPS-Spur aufgezeichnet und werde das in den nächsten Tagen überarbeiten.
Zum Verlauf der Straßen siehe auch https://www.stbaa.bayern.de/strassenbau/projekte/B71S.ALSA0018.00.html

Bin mir nicht sicher, ob Meldung 2344521 die Straße oder die Wirtschaftswege meint; der Marker liegt dazwischen.
Meldung 2332959 hingegen ist eigenartig, denn Weg way/25357119 wurde schon vor 6 Jahren von construction auf tertiary gesetzt. Nicht auszuschließen, daß es eine kurzfristige Sperrung gab, aber die war nicht gemappt.

Servus,
Rainer

Hello harinikh,
To your edits I have some concerns/requests:
1. No source is indicated in your change set; imagery_used is not the same and not sufficient. Is it based on survey or only on aerial pictures?
2. It looks like you haven't checked the offset that the Revalstraße has here. In a qulaity edit, this offset should be corrected before adding side ways. For that you need to compare differrent aerial pictures and GPX traces in that area. As a consequential error the gate is in the wrong place.
3. Access ways without infrastructure function, means which lead only to single addresses, should be service=driveway., please se the Wiki service=driveway .
4. which access restrictions are given for the way/845383611? As it is on private estate, surely the will be such. Your edit is missing that.

Summary: target is to improve the quality of OSM data: here it looks like the target is only to draw hw=service as much as possible in the shortest time, in other words quick and dirty.

Please improve the edit or revert it.

Best regards,
Rainer

Hello kumarxeq,
thank you for the quick response. The background image used does not yet tell you what the source of the data entered is. Does that mean that only aerial photos are used for painting? Such access roads typically have access restrictions because they often run on private ground. How is this information added, where does it come from? Without access tags this often leads to trouble with the owners. For example: access=private|destination|delivery or motor_vehicle=destination
Best regards,
Rainer

Translated with www.DeepL.com/Translator (free version)

Hallo kumarxeq,

you are adding many hw=service.

To your changesets I have 2 questions/requirements:
1. What is the source of your edits?
Please add the source to each of the changesets.
2. Pure driveways shall be tagged with hw=service AND service=driveway.
Please have a look in the Wiki: service=driveway
Would you please rework your changesets accordingly?

Best regards,
Rainer

Hallo Dennis,
danke für die Rückmeldung. Wenn du einen Link zu den Adressen hast, wäre das mal interessant.
Vor einigen Wochen gab es schon mal einen Edit hier, bei dem die Adressen aber aus dem Bayernatlas übernommen waren, der für OSM aus Lizenzgründen tabu ist.
Dein Edit hatte nun exakt denselben Inhalt, weshalb ich nachgefragt habe.
Die meisten dieser Adressen existieren vor Ort (noch) nicht, weshalb ich den Änderungssatz zurückgesetzt habe, aber den jetzigen Status im Neubaugebiet eingezeichnet habe und auch die Handvoll tatsächlich ausgeschilderte Adressen.
Viele Grüße,
Rainer

Super, danke für die Rückmeldung :)

Hallo coezbay,
willkommen bei OSM!
Du hast den Wunsch nach Überprüfung angekreuzt, daher schreibe ich.
Im wesentlichen paßt der Edit. Ein paar Korrekturen wären aber ganz schön:
1. In OSM schreiben wir nur echte Abkürzungen in Versalien (Großbuchstaben), Firmennamen jedoch in normaler Schreibweise, Anfangsbuchstaben groß, Rest klein, also in diesem Falle Coezbay GmbH.
2. die Telefonnummer im internationalen Format ohne die Klammern um 89
3. description ist kein Feld für Werbung, dafür hast du ja die Webseite verlinkt, als obitte neutral und möglichst kurz formulieren; wenn description von der Landessprache abweicht, besser description:en bzw. das passende Kürzel verwenden.
Viele Grüße,
Rainer

Hallo Nicor,
hat Streetcomplete hier einen Fehler oder hast du dich vertan?
Bei den Gebäuden steht jetzt in addr:street die Hausnummer, aber die gibt's in addr:housenumber ja schon.

Viele Grüße,
Rainer

Hallo Nearest!
du warst schnell mit der Korrektur, aber du hast offensichtlich nur den Zustand wiederhergestellt, den Ana Luisa korrigieren wollte. Die Hausnummer ist 29a und war fälschlicherweise in addr:city eingetragen worden. Die angegebene Quelle sagt auch 29a und nicht 26. Die gibt's jetzt zweimal.
Ich korrigiere das nun.
Viele Grüße,
Rainer

Hallo Ralph, danke für die Rückmeldung. Beim alten Polizeiposten waren die Attribute ans Gebäude geheftet, daher kann man nicht einfach das Objekt löschen, sondern muß dienicht mehr zutreffenden Attribute identifizieren und löschen.
Da ich mit JOSM und nicht nicht mit iD arbeite, kann ich nicht aus dem Stand die Vorgehensweise mit dem Editor beschreiben. Ich habe das einfach mal gemacht.
Grüße,
Rainer

Hui, das scheint komplizierter als ich dachte. Der Validator stört sich an doppelten Linien nur am Aufzug am Bahnsteig, nicht beim Lift nördlich der Gleise.
Die Unterführung hat kein building=*, nur die Außenhülle des Lifts.
Die S-Bahn-Station kenne ich, aber sollte ich Bilder / Infos brauchen, melde ich mich.
Für heute lasse ich's unverändert.

Hallo Strubbl,
nach dem changeset/89652148 habe ich hier auch noch einen Blick drauf geworfen.
Streetcomplete will immer für jedes Gebäude eine Adresse haben, egal wie die Realität aussieht. Nun sind für das Bahnhofsgebäude dreimal teils unvollständige Adressen gemappt. Damit ist zwar Streetcomplete zufrieden, der Datennutzer aber wird durch die dreifache Adresse verwirrt. Daher bitte immer schauen, ob fehlende Information hinzugefügt wird oder nur der sture Formalismus der App befriedigt wird.
Auch hier schaue ich mir an, ob bzw. das Gebäude besser gemappt werden kann.

Servus,
Rainer