OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Ich kann die Putzaktion übernehmen … aber die Frage ist tatsächlich: wo die Adresse entfernen und wo lassen?

Hm, ich würde in diesem Fall für a) votieren, also die Adresse am Gebäude lassen und am Eingang entfernen, weil 1. diese Gebäude alle nur jeweils eine Adresse haben (nicht mehrere verschiedene je nach Eingang – dann müssten wir ja b) wählen) und weil 2. in der Umgebung die Adressdaten meistens am Gebäudeumring erfasst wurden, a) also konsistenter ist als b).

Was meint Ihr?

Edit: Hat sich mit dem Beitrag von geri-oc überschnitten, der ja für b) votiert hat, und zwar auch mit einem guten Argument. Was meinen andere, nachdem wir nun sozusagen Gleichstand haben? :wink:

Ich würde natürlich auch bei der Wahl von a) die Knoten mit entrance=main/yes belassen, nur die Adressdaten entfernen.

Ich schliesse mich “a” an.

Wenn die Adressen schon am Eingang hängen, würde ich auch b) bevorzugen. Das können im Zweifel die entscheidenden Meter sein, die entscheiden, ob mich der Router an den Zaun auf der Rückseite oder den Haupteingang leitet.

Mir ist auch noch ein (Pseudo?)-Argument für b) eingefallen: Zumindest bei Stichproben sieht es so aus, als sei hier überall die Adresse zuerst am Eingang eingetragen worden und erst später am Gebäude. Da ich die OSM-Historie gerne respektiere (Ehre, wem Ehre gebührt) und Euer Routing-Argument sehr einleuchtend ist, lasse ich mich überzeugen. :wink:

Werde also die doppelten Adressdaten an den Eingängen belassen (b) und vom Gebäude (wieder) entfernen. Ich schaue mal, ob ich gleich nachher zu der kleinen Putzaktion komme …

Ich wäre auch für die Adressdaten im Gebäudeumriss, weil es in der Kartendarstellung eleganter aussieht.
Wenn es für das Routing notwendig ist, noch am Umriss (nackten)Eingang gesetzt. Es gibt auch Gebäude mit mehreren gleichwertigen Eingängen pro Adresse, da kann der Router entscheiden was günstiger ist. Z.b. routet Osmand zu den Eingängen ohne Adresse wenn die Daten im Umriss stehen. Daher ist das Argument mit den Daten am Eingang wegen den Routing nicht stichhaltig.

Ich plädiere dafür es so zu lassen, wie es der Ersterfasser gemacht hat. Schon aus Respekt vor seiner Arbeit.

ts, ts, ts. Tagging für den Renderer :frowning:
Der könnte das im Übrigen auch bei der Darstellung vom Eingangsknoten auf den Gebäudemittelpunkt (oder noch eleganter mit Schriftausrichtung zur passenden Straße, wie es die bayerische Vermessungsverwaltung in der Flurkarte macht) verlagern.

OSM ist eine Weltkarte:
In Italien wäre es zum Beispiel falsch, die Adresse an das Gebäude zu hängen. Dort sind Adressen als Punkt an einer Straße definiert.
Was spricht denn eigentlich dagegen, wenn man die Adresse dort erfasst, wo das Schild hängt. Das hat doch auch seinen Grund :wink:

Privat heßt doch “mit Einzelerlaubnis” und nicht “verboten”. Bei mir darf auch nicht jeder 'rein, der glaubt mein Besucher sein zu wollen.

Info: Ich bin jetzt beim Putzen … also bitte nicht noch jemand anderes gleichzeitig, sonst kommen wir uns nur in die Quere. :wink:

Update: Fertig. Teil I, Teil II, Teil III, Nachtrag.

Nebenbei habe ich auch die Gebäudetypen (building=house/apartments) wiederhergestellt, die der Doppelerfasser oft einfach durch building=yes ersetzt hatte, und ein paar offensichtliche Kleinigkeiten korrigiert. Lustig war noch ein Fußweg mit Postanschrift und interessant die Frage, zu welcher Straße die Hausnummern 19, 21, 23 gehören – die beiden Mapper waren da verschiedener Meinung, ich denke, dass in diesem Fall der Doppelerfasser recht hatte, nicht der Ersterfasser.

Nächstes Thema bitte. :slight_smile:

Kann es sein, dass die Funktion „Adresse als korrekt markieren“ nicht mehr funktioniert?

  • Früher als korrekt markierte Adressen werden zur Zeit wieder als problematisch markiert (z.B. hier (Stocksberg), die waren doch alle mal als korrekt markiert)

  • Wenn ich eine Adresse im Popup als korrekt markiere, wird sie weiter als problematisch angezeigt.

  • Allerdings: Wenn ich mir „als korrekt markierte“ Adressen anzeigen lasse (magentafarbene Marker), erscheinen doch einige. Teilweise tut es also doch? Hm, jetzt bin ich verwirrt …

Danke für den Hinweis, da hab ich wohl vor kurzem was kaputt gemacht. Leider bin ich im Moment mit 250l-Wasserpfütze aufstellen und einrichten etc. und meinem Tagesgeschäft voll beschäftigt. Kann also noch etwas dauern, bis das gefixt wird.

Gruß, Frank

Kein Problem! Freut mich aber, wenn der Hinweis hilfreich war …

So, das mit dem als korrekt markieren sollten wieder gehen. Ich hab nach dem Einfügen der Datumsfilter vor ein paar Wochen vergessen, diesen Key beim Zusammensammeln der betroffenen Tiles zum Löschen des Cache aufzunehmen.

Grüße, Frank

Gerade ausprobiert – funktioniert wieder. Ganz herzlichen Dank!

Ich habe hier https://osm-suspects.gbconsite.de/#17/48.22162/9.26360/osm-wrongcity-minimalmissing-wrongstreet-wronghousenumber-outsideplz-dupes zwei falsche (?) Fehlermeldungen. Da werden fehlende addr:street bemängelt. Die gibt es aber gar nicht. Als Ersatz sind dafür addr:place eingetragen.

Grüße

Wenn du addr:place verwendest, sollte auch place=* und name=* getaggt sein, z.B. an einem Node.

Heute keine Auswertung? Ich sehe immer noch „(Datenstand 2018-01-03T21:43:02Z)“ … (Ich frage nicht, um zu meckern, sondern nur für den Fall, dass bei der Auswertung irgendetwas hängt oder so … ;))

Heute etwas :wink: später, weil ichs auch erst kurz vor mittag gemerkt habe.

Ich prüfe ab 01:00 alle 1/4 Stunde bis 04:00, ob die Geofabrik-Daten zur Verfügung stehen. Das hat heute nicht gereicht - ich setz das morgen hoch bis max. 10:00.

Danke dir!

Grrr… Der Import mit osm2pgsql hat heute nicht funktioniert, hab eben die Datenbank und die Auswertung neu gestartet. Sorry.

2018-01-06 01:19:21.935 CET [464] xxx@xxx ERROR:  unexpected message type 0x58 during COPY from stdin

In den letzten Tagen ist mir im Norden von BW zufällig noch ein neuer Typ von Adress-Problemen aufgefallen: nämlich eigenwillige Verwendungen von addr:place. In einer Reihe von Fällen wurde es (a) für den Gemeindenamen verwendet – also statt addr:city – oder b) für eine Angabe des Ortsteils – also statt addr:suburb.

Alle Fälle machten mir den Eindruck, dass es sich mehr oder minder um bloße Versehen handelt, die dann durch Copy&Paste (oder die Auto-Komplettierung von JOSM) im jeweiligen Viertel vervielfacht wurden. Zudem herrscht über die Bedeutung von addr:place offenbar relative große Einigkeit (siehe OSM-Wiki; in meinen Worten: addr:place ist kein Ersatz für addr:city oder so, es komplettiert vielmehr addr:housenumber und ersetzt dabei gewissermaßen addr:street, nämlich bei Gehöften oder Weilern, bei denen die Hausnummern nicht einzelnen Straßen, sondern dem ganzen Wohnplatz zugeordnet sind). Daher habe ich mir gestattet, diese Adressen gleich zu korrigieren; zu (a): 55996836, 55996956, 55997095, 55997207; zu (b) 55736351, 55997498. Ich führe die Changesets hier nicht an, um mich zu rühmen, sondern weil sie eben Beispiele für diese Art von Adress-Problem enthalten.

Erstens hoffe ich, dass ich mich da nicht vertan habe; mir schien die Sachlage hier aber ausnahmsweise einmal relativ eindeutig zu sein. :wink: (Falls jemand Einwände hat, korrigiere ich meine Fehler auch!)

Zweitens: Haltet Ihr es für möglich und für sinnvoll, einen Test auf solche Probleme in OSMsuspects! zu integrieren? Das waren jetzt doch eine ganze Menge Treffer in einem relativ kleinen Gebiet. Vielleicht kann jemand mal in „seinem“ Gebiet nachsehen, ob es dort diese Probleme auch gibt. Falls ja, würde es sich vielleicht lohnen, zu prüfen, ob ein Test machbar wäre …

Einen Test für Problem (a) stelle ich mir als Laie relativ einfach vor: Man müsste alle Adressen als zweifelhaft markieren, die ein Tag addr:place haben, das mit dem Gemeindenamen übereinstimmt, also mit dem Wert, der in addr:city stehen sollte. Dabei sollte es nicht allzu viele falsch-positive Treffer geben, denn in Deutschland sind die meisten Weiler und Wohnplätze, in denen addr:city zu Recht verwendet wird, keine eigenständigen Gemeinden, der Wert in addr:city sollte also meistens anders lauten als der in addr:place.

Ein Test für Problem (b) dürfte schwieriger sein, vermute ich.

Ein anderer, vielleicht besserer Ansatz wäre: Alle Adressen als zweifelhaft markieren, die sowohl addr:place als auch addr:street haben; ein solches doppeltes Tagging sollte doch eigentlich nie nötig sein und könnte ebenfalls auf Fehler wie (a) und (b) hinweisen. Vielleicht kann man das auch mit dem für (a) vorgeschlagenen Test kombinieren?

Edit: Eine Overpass-Turbo-Abfrage nach Objekten, die sowohl addr:place als auch addr:street haben, hat allein in BW schonmal zahlreiche Treffer. Darunter sind viele Objekte, wo addr:place und addr:street übereinstimmen (unnötig, aber harmlos?), viele Objekte, die Problem (a) oder (b) entsprechen, einige weitere Arten von Problemen (z.B. addr:place, die versehentlich die PLZ enthalten) sowie einige Fälle, wo sich jemand etwas gedacht hat. Hm, also eine Inspektion dieser Objekte wäre schon lohnend – fragt sich, ob das etwas für OSMsuspects! ist, oder ob es zuviele harmlose und falsch-positive Fälle gibt? Dann bleibt immer noch Problem (a) …

Moin,

Zum Stichwort addr:place ersetzt addr:street:

Hier in Schleswig-Holstein gibt es einzelne Wohnplätze, wo die Hausnummern eindeutig sind und die Adressen in der Regel aus Wohnplatzname + Hausnummer gebildet werden - es aber zusätzlich vereinzelte Straßennamen gibt.
In diesen Fällen sind sich die Bewohner selbst nicht einig, ob dort der Wohnplatzname oder der Straßenname verwendet wird - der Postbote ist entsprechend auf beides ‘geschult’. :wink:
In diesem Fall habe ich sowohl addr:place als auch addr:street vergeben.
Beispiele:
https://overpass-turbo.eu/s/vNU
https://overpass-turbo.eu/s/vNX

Grüße, Georg