I have no preference

fixed now

yes

auf den blauen Schildern steht kein "A7", da steht nur "Göttingen"

Hier fehlte keine Adresse.

* Wir richten uns nach ALKIS, entsprechend sind Hausnummern für Gebäude (diese können entweder am Gebäude kleben oder als separate Node vorliegen) *einzeln*. Damit ist ein Datenbank-Sucherfolg gewährleistet, ohne die konkrete Range (x-y) kennen zu müssen!

* bei weiteren Nodes, z.B. für Firmen kann eine Range vorkommen, üblicherweise wenn die Firma auf ihrer Webseite sich selbst so adressiert.

Stop your actions! "13 & 13a" is not valid house number syntax, and assigning it to a shed of all things is just as wrong.

Stop your actions! House number 2 was already assigned and you just produced a duplicate.

Habe ich reverted. Ich war dort: das ist, wie vor 8 Jahren, immer noch eine Einfahrt. Das sieht man verdammt schon am Luftbild, weil da ein Carport steht.

wtf ist das für ein Unsinn? Haus Nr. 10 an einem Haus, das bereits als 16 getaggt wurde?

dem User würde ich nicht trauen...

Du hast hier in changeset/175790821 die Grenze nach ALKIS neugezeichnet und dabei von den tatsächlich erfassten Grenzsteinen (z.B. node/6775570746, "G10") abgetrennt. Die Sammlung an Steinen mit G-Eingravierung (Göttingen; eine Seite) und D-Eingravierung (andere Seite des Steins; Diemarden) zeugen von der tatsächlichen Grenze, und stimmen, minus der Ungenauigkeit meines GPS-Telefons von ±3m, eigentlich recht gut mit den in ALKIS hinterlegten runden Nodes überein. Wie am besten mit der Situation umgehen? Steine verschieben? Grenze zurückverschieben?

(Das hat erstmal nichts mit der kürzlich kommunizierten Situation um Stein "72E", node/8665773283, zu tun -- das wird wohl ein Waldparzellenmarker gewesen sein)

Hm ich hatte mich an
residential=* orientiert:
"Rural, mostly undeveloped residential landuse."

Aber undeveloped ist ein Stadtgebiet ja eigentlich schonmal überhaupt nicht.

Also hier residential=rural zu setzen ist schon arg gewagt... (und IMHO falsch)

Ich habe weiter recherchiert. Geh mal zu node/2142838616/node 8664659657 (Glombitza-Bank) und lass dir den AP2.5-Layer anzeigen. Was fällt auf? Die Borheckstraße ist im AP eine Linie die ca. 20px dicke pastellgelb mit 6px dick grauem Casing.

Abseits davon die 50px breite pastellgelbe Linie/Fläche mit 1px dickem grauen Rand, die direkt an der pinken Admingrenze klebt. Damit sollte klar werden, dass die 50px breite Linie nur rudimentär mit der Wegeposition korreliert.

Megageil. Aber dann hab ich trotzdem mal mit Overpass nach Fehlern geschaut und gefunden:

node/8665773283 wurde durch changeset/175792948 geändert.
Auch wenn die Lage des Stein-Nodes selber gewissen Ungenauigkeiten unterliegt, so ist es doch ein Fehler, sie von einer Straßenseite auf die andere zu verfrachten.

Das braune einmeterhohe Buschwerk: https://inai.de/20251119_140222240.JPG
Hütte: https://inai.de/20251119_140346052.JPG
Hab die Karte nochmal angepasst und die Waldgrenze bis vor die Hütte verlegt, halt dort wo die Büsche weichen und das (Wald-)Laub zu liegen beginnt.

Oder "steht wieder" 🤷
Der Gebüschteil jedenfalls ist gut gediehen seit dem letzten Jahr.

Es war auf jeden Fall nicht mehr so recht konsistent mit der restlichen Wegstrecke.

wenn Steingraben/Ossietzkystr. tertiary sei, dann müsste auch die Teichstr. so markiert werden. Aber dann merkt man: die Teichstr. hat doch eine niedere Bedeutung als die Kiesseestr. oder Danziger Str. - die ihrerseits schon tertiary ist/sind. Von daher kann die Ossietzkystr. so nicht als tert. gelten.

osm.wiki/DE:Bicycle/Radverkehrsanlagen_kartieren#highway=cycleway_und_highway=footway