rempshaener (2025-05-26 17:55:23+00:00): Hallo,

nach aktuellen Umbauten hat sich die Situation vor Ort mal wieder etwas geändert. Insbesondere ist nun an der Beschriftung der Eingangstür auch die Hausnummer ausgewiesen. Insofern hat sich das Problem mittlerweile erledigt. Für www.openstreetmap.org/node/10596601955 sind keine Anpassungen mehr notwendig.

>> vorab: der Änderungssatz ist zu groß.
> Welchen meinst Du? Meinen? Der enthielt doch nur 3 Objekte.

Das Gebiet ist zu groß. Zumindest in Deutschland sind Changesets meist auf Städte/Kreise eingegrenzt. Sonst laufen Änderungen bei Leuten mit einfachen QA-Tools Änderungen auf, die sie nicht betreffen.

>> „ist das contacts-Schma kein Ersatz für das Adress-Schema, weder definitionsgemäß, noch von der Logik her“
>Es gibt durchaus Fälle, in denen die Kontaktadresse anders ist als die physische. Das ist hier aber nicht der Fall. Abgesehen davon ... wenn man dann schon mit dem Schema arbeitet, sollte man wenigstens konsequent sein und die Webseite dort einbeziehen, auch wenn es rein statistisch vielleicht nicht ganz klar ist, was häufiger verwendet wird bzw. nur "Altlast" ist.

Genau das war hier der Fall, kein Ausweis vor Ort, einzige Quelle die Website.

>> 2. „Und eine physische Adresse muss auch nicht explizit ausgewiesen sein.“
> Insbesondere zum letzten Punkt: das stellt vor dem Hintergrund des On-the-ground-Prinzips eine nicht allzu weit verbreitete Meinung dar. Wie kommst du zu dieser Erkenntnis?
>Auch das Ground-Truth-Prinzip hat seine Grenzen. Wenn man es wörtlich nehem würde, dürfte man z.B. keine Postleitzahlen taggen und auch nur bei sehr wenigen Gebäuden die Straßennamen. Du weißt, worauf ich hinaus will. Darüber hinaus wüsste ich nicht, warum ein "contact"-Key von diesem Prinzip ausgenommen sein sollte, der "addr"-Key aber nicht. Interessanter ist das vermutlich z.B. beim "name"-Key, bei dem man sich ja wirklich an die vorgefundene Realität halten sollte (wobei ich trotzdem keine offensichtlichen Schreibfehler auf Schildern in Tagging übernehme).

Das Thema der Postleitzahlen hat erst einmal nichts mit der Hausnummer zu tun - nur um die geht es hier. Und Straßennamen sind allenfalls an Straßenecken mal nicht zuzuordnen. Solche Fälle werden spätestens dann 
korrigiert, wenn die Eigentümer aus genau diesem Grund den Straßennamen mit an die Wand schreiben. Erst gestern noch bei einem einschlägigen Neubau gesehen.

>Grundsätzlich kann man aber hier die Frage aufwerfen, wie man mit POIs und Adressen umgeht (auch wenn ein Changeset-Kommentar nicht der richtige Ort dafür ist). Man könnte sagen, dass man nur dem Gebäude (das meines Wissens übrigens sehr wohl eine sichtbare Hausnummer hat irgendwo) eine physische Adresse gibt, den einzelnen Läden oder Einrichtungen aber nicht, wenn sie nur Teil des Gebäudes sind. Die Logik dahinter wäre, dass man vom umschließenden Gebäude auf die Adresse schließen kann. Rein semantisch ist das eindeutig, technisch eigentlich auch (für einen Renderer), nur ggf. mit mehr Aufwand verbunden. Aber hier kommt dann wieder "wir taggen nicht für den Renderer" ins Spiel, auch wenn es manchmal vielleicht besser wäre ;)

Das ist unproblematisch. Gerade die Doppelung von Adressen an POI und Gebäude ist weitreichend akzeptiert. Und wenn man es nicht macht, ist es auch okay. Und für den Renderer wird es erst problematisch, wenn zufällig der (amenity|office|craft…)-POI nicht gerendert wird, die Adresse aber schon. Das ist/war hier aber nicht das Problem.

>Wenn man sich also steif an den (losgelösten) Satz aus der Wiki oben hält, sollte man die physische Adresse aus dem "contact"-Key rauslassen und entweder den "addr"-Key verwenden oder das umliegende Gebäude damit versehen. Letzteres halte ich wie gesagt für sauber, aber ich tagge ehrlich gesagt die Adressen auch oft an POI-Knoten, weil viele Karten- oder andere Tools eben leider nicht die schließenden Gebäude bei der Darstellung der Adressen berücksichtigen, obwohl es rein technisch möglich wäre. Man hat dann also im Zweifel eine Redundant und im schlimmsten Falle soger ein doppeltes Rendering der Hausnummer, was ja beides auch nicht im Sinne des Erfinders ist.

Das war hier nicht das Problem.
Auf dem Gelände sind wild Hausnummern vergeben: Manche Hallen “teilen” sich Hausnummern, manche Hallen haben “Halle XYZ” als Angabe.
Und manche Mieter haben Adressen “erfunden”. Alles völlig okay, das wird entsprechend erfasst. Egal, ob “offiziell” oder nicht - nur vor Ort kontrollierbar muss sie sein.
In diesem Beispiel ging es um eine Hausnummer, die bis vor Kurzem nicht vor Ort ausgewiesen war. Und das erfassen wir nicht als physische Adresse.

Daher auch noch einmal mein Hinweis auf die übrigen Objekte, die du in diesem CS bearbeitest hast. Wenn beispielsweise die “Gesenkschmiede Hendrichs” auf ihrer Website 289-297 als Hausnummer angibt, vor Ort - rein theoretisch, ich war nicht vor Ort - aber nur die Hausnummern 289, 291 und 297 verzeichnet sind, wäre die richtigere Angabe “289;291;297” am “Gesamtobjekt”. Oder aber, weil manche Mapper den String mit Semikolon kritisch sehen - als drei Nodes. Was wiederum spätestens dann zu unserem Datenmodell nicht gut passt, denn die Objekte www.openstreetmap.org/way/112953007, www.openstreetmap.org/way/307581548 und www.openstreetmap.org/way/307581549 sind bereits angegeben. Da offensichtlich die einzige Quelle für die “289-297” die Website des LVR ist - dessen Beweggrund für mich beinahe nachvollziehbar ist, denn dort hätte man sich sonst als Kontaktadresse willkürlich für eine der Hausnummern auf dem Gelände entscheiden müssen - war das contact:*-Schema genau passend und für diesen Zweck gemacht. Wenn du der Meinung bist, dass das contact:*-Schema aus anderen Gründen völlig unpassend ist, wäre es besser, die Adresse vollständig herauszunehmen, statt eine zu generieren, die es mutmaßlich nicht gibt.
Das andere Objekt habe ich mir nicht angeschaut. Ich möchte dich bitten, mindestens die Gesenkschmiede wieder in den ursprünglichen Zustand zurückzuversetzen.

Viele Grüße