OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

Announcement

A fix has been applied to the login system for the forums - if you have trouble logging in please contact support@openstreetmap.org with both your forum username and your OpenStreetMap username so we can make sure your accounts are properly linked.

#376 2017-05-20 13:01:26

JSe
Member
Registered: 2016-02-22
Posts: 8

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

@geri-oc:
Das ist bereits jetzt der Fall, das addr:city verwendet wird, wenn es explizit gesetzt ist. Andernfalls ist OSMSuspects! darauf angewiesen, addr:city zu ermitteln, um unterscheiden zu können, ob zwei Adressen bei gleichen Werten addr:street und addr:housnumber im gleichen Ort (addr:city ist auch gleich) liegen und damit ein "bemeckernswertes" Duplikat darstellen oder eben nicht.
Diese Überprüfung ist aufgrund eines  Hinweises von mir (siehe Posting #283 in diesem Thread) von Dooley dankenswerter Weise eingeführt worden.

Hier geht es nun darum, den benutzten Algorithmus nochmals zu optimieren. Natürlich könnte man diese 3 Fälle auch "lösen", indem man addr:city einfach setzt, aber das wäre erstens eine Art Mapping zwar nicht für den Renderer sondern für den Qualitätssicherer und zweitens wäre es natürlich besser, diese false positives gar nicht anzuzeigen, wenn das mit vertretbarem Aufwand vermeidbar wäre.

Offline

#377 2017-05-20 14:34:45

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 2,920
Website

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

JSe wrote:

... Fälle auch "lösen", indem man addr:city einfach setzt, aber das wäre erstens eine Art Mapping zwar nicht für den Renderer sondern für den Qualitätssicherer

M.E. ist es detailliertes Mapping - also genaues erfassen der (addr:*=*) Daten.
Also nicht mappen für den Renderer, Qualitätssicherer, ...

Offline

#378 2017-05-20 20:39:50

seichter
Member
Registered: 2011-05-21
Posts: 1,999

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

geri-oc wrote:
JSe wrote:

... Fälle auch "lösen", indem man addr:city einfach setzt, aber das wäre erstens eine Art Mapping zwar nicht für den Renderer sondern für den Qualitätssicherer

M.E. ist es detailliertes Mapping - also genaues erfassen der (addr:*=*) Daten.
Also nicht mappen für den Renderer, Qualitätssicherer, ...

+1:
Der "postalische Ortsname" weicht nicht selten vom administrativen ab, bzw. umfasst andere Gebiete.
Das explizite Setzen von addr:city erhöht also die Datenqualität und ist dann nicht einmal Redundanz.
Es ist mMn damit kein "false positive".
Außerdem kommt es den Nutzern entgegen, die an den Häusern/POIs "unbedingt!!!" die volle Adresse haben möchten.

Last edited by seichter (2017-05-20 20:40:58)

Offline

#379 2017-05-22 08:08:00

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 313

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

JSe wrote:

@geri-oc:
Das ist bereits jetzt der Fall, das addr:city verwendet wird, wenn es explizit gesetzt ist. Andernfalls ist OSMSuspects! darauf angewiesen, addr:city zu ermitteln, um unterscheiden zu können, ob zwei Adressen bei gleichen Werten addr:street und addr:housnumber im gleichen Ort (addr:city ist auch gleich) liegen und damit ein "bemeckernswertes" Duplikat darstellen oder eben nicht.
Diese Überprüfung ist aufgrund eines  Hinweises von mir (siehe Posting #283 in diesem Thread) von Dooley dankenswerter Weise eingeführt worden.

Hier geht es nun darum, den benutzten Algorithmus nochmals zu optimieren. Natürlich könnte man diese 3 Fälle auch "lösen", indem man addr:city einfach setzt, aber das wäre erstens eine Art Mapping zwar nicht für den Renderer sondern für den Qualitätssicherer und zweitens wäre es natürlich besser, diese false positives gar nicht anzuzeigen, wenn das mit vertretbarem Aufwand vermeidbar wäre.

Ich habe mir am Wochenende nochmal die dupes-Erkennung genauer angeschaut und dabei einen kleinen Bug gefixt, daher ist die dupes-Anzahl seit heute etwas gestiegen.

Was nicht geht, wenn in keiner der Vergleichsadressen ein addr:city gesetzt ist, also genau die Fälle, die du in deinem vorherigen Post https://forum.openstreetmap.org/viewtop … 23#p647023 aufgezählt hast.
Ich bin (wahrscheinlich zum Leidwesen von dir) eine der Personen, die *unbedingt* ;-) komplette Adressen am Objekt haben wollen aus den Gründen, die geri-oc und seichter genannt haben. Daher geht mein Motivationlevel, an der dupes-Erkennung in dieser Richtung weiterzuschrauben, gegen Null.

Gruß, Frank


OSMsuspects!
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#380 2017-05-23 06:40:16

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 313

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Moin.

Ich habe die Prüfkriterien für die Hausnummern etwas strenger ausgelegt, damit auch Einträge wie "0", "12 u. 13", "30 | 1", "12, 14" etc. gefunden werden, über die ich gestern gestolpert bin.

Gruß, Frank


OSMsuspects!
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#381 2017-05-23 09:17:29

Chrysopras
Member
From: Germany
Registered: 2015-04-01
Posts: 757

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Danke! Das könnte zwar Diskussionen geben, weil mancher einer „12, 14“ für völlig richtig hält, aber es ist sicher richtig, so etwas anzumeckern – man muss es ja nicht ändern.

Offline

#382 2017-05-23 09:45:16

GeorgFausB
Member
From: Probstei, Schleswig-Holstein
Registered: 2008-10-14
Posts: 1,187

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Moin,

werden bei den Dupes nicht mehr die unterschiedlichen addr:city (explizit am Objekt gesetzt) berücksichtigt?

Grüße, Georg
Hat evtl. am Wochenende nur ein größerer/anderer Bug den kleineren bug gefressen? wink

Offline

#383 2017-05-23 09:58:16

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 313

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

GeorgFausB wrote:

Moin,

werden bei den Dupes nicht mehr die unterschiedlichen addr:city (explizit am Objekt gesetzt) berücksichtigt?

Grüße, Georg
Hat evtl. am Wochenende nur ein größerer/anderer Bug den kleineren bug gefressen? wink

Hmpf. Du hast recht, da scheint irgendwas mit der Erkennungslogik nicht mehr zu stimmen. Da muß ich wohl nochmal ran.

Edit: Die dupes werden für die nächsten ca. 30 Minuten nicht zur Verfügung stehen, ich generiere die grade neu.

Edit 2: So, sollte gefixt sein. Danke @GeorgFausB, für den Hinweis.

Last edited by dooley (2017-05-23 11:07:43)


OSMsuspects!
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#384 2017-05-23 22:11:45

pyram
Member
Registered: 2012-06-16
Posts: 650

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

@dooley

Sorry, aber so ganz passt das jetzt nicht, weil Adressen wie "1 1/2", also mit Leerstelle und nachfolgendem Bruch, verbreitet völlig korrekte Hausnummern sind (zum Beispiel in Augsburg oder Greding).

Offline

#385 2017-05-24 06:26:38

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 313

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

pyram wrote:

@dooley

Sorry, aber so ganz passt das jetzt nicht, weil Adressen wie "1 1/2", also mit Leerstelle und nachfolgendem Bruch, verbreitet völlig korrekte Hausnummern sind (zum Beispiel in Augsburg oder Greding).

Danke, habe es heute nacht noch gefixt.


OSMsuspects!
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#386 2017-06-18 07:48:39

PT-53
Member
From: Oberschwaben (BW, DE)
Registered: 2013-09-01
Posts: 473

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Hallo dooley,

ein Fehler, den OSMsuspects (noch?) nicht bemerkt:
Ich hatte z.B. an diesem Gebäude - duch Kopieren - den falschen Teilort eingetragen:
https://www.openstreetmap.org/way/501031567/history

Grüße aus Oberschwaben
Peter

Offline

#387 2017-06-18 10:25:23

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 313

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

PT-53 wrote:

Hallo dooley,

ein Fehler, den OSMsuspects (noch?) nicht bemerkt:
Ich hatte z.B. an diesem Gebäude - duch Kopieren - den falschen Teilort eingetragen:
https://www.openstreetmap.org/way/501031567/history

Grüße aus Oberschwaben
Peter

Das ist richtig, addr:suburb wird nicht geprüft. Die entsprechenden administrativen Einheiten sind oft nicht in OSM als Fläche verfügbar. In Zahlen haben wir nur 4983 x admin_level 9, 4450 x admin_level 10 und 1055 x admin_level 11 als boundary in Deutschland erfasst. Das ist meiner Meinung nach viel zu wenig, um es sinnvoll auszuwerten. Bei viel Freizeit mach ich mal einen Testlauf, um da Erkenntnisse zu gewinnen.


OSMsuspects!
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#388 2017-06-18 11:29:34

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 13,560
Website

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

dooley wrote:

In Zahlen haben wir nur 4983 x admin_level 9, 4450 x admin_level 10 und 1055 x admin_level 11 als boundary in Deutschland erfasst.

Komisch, ich komme auf ganz andere Werte:

 wno_number | count 
------------+-------
          2 |     1
          4 |    16
          5 |    19
          6 |   399
          7 |  1258
          8 | 11164
          9 |  4762
         10 |  4157
         11 |  1016
         12 |   164

magst du mir mal deine Query zeigen? auch gerne per PN oder Mail.

Gruss
walter

Offline

#389 2017-06-18 12:03:40

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 313

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

wambacher wrote:

magst du mir mal deine Query zeigen? auch gerne per PN oder Mail.

select count(*), admin_level
from public.germany_polygon
where admin_level::numeric between 9 and 11
and boundary = 'administrative'
group by admin_level
order by admin_level::numeric asc;

Ich schliesse nicht aus, dass da ggf. ein paar dabei sind, die nicht zu Deutschland gehören bzw. durch osm2pgsql Relationen aufgelöst wurden und damit mehrfach gezählt werden. Ich hab die Zahlen nur mal als Anhaltspunkt genommen ohne Gewehr auf 100% Genauigkeit.

Gruß, Frank


OSMsuspects!
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#390 2017-06-18 12:32:24

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 13,560
Website

Re: OSMSuspects - Qualitätssicherung Adressen (Deutschland)

dooley wrote:

Ich schliesse nicht aus, dass da ggf. ein paar dabei sind, die nicht zu Deutschland gehören bzw. durch osm2pgsql Relationen aufgelöst wurden und damit mehrfach gezählt werden.

Ist halt die Frage, woher die Daten im germany-polygon stammen und wie "scharf" das ist.

Achtung: es gibt eine ganz schlimme Falle, die mir zur Zeit auch Probleme macht.
Relationen mit type=multipolygon "erben" die Tags des Outers und das kann katastrophal sein. So werden z.B. aus falschen TMC-Relationen plötzlich Admin-Grenzen.

Beispiel: https://openstreetmap.org/relation/62722 wird durch osm2pgsql ein Grenzpolygon:

select each(tags) from planet_osm_polygon 
where osm_id=-62722;
                 each                  
---------------------------------------
 (boundary,administrative)
 (old_name,Müritz)
 (way_area,0.232755)
 (admin_level,7)
 (TMC:cid_58:tabcd_1:Class,Area)
 (TMC:cid_58:tabcd_1:LCLversion,8.00)
 (TMC:cid_58:tabcd_1:LocationCode,551)

nur weil manche Outer-Member mit boundary=administrative, admin_level=x getaggt sind. Dieses Tagging ist ja durchaus üblich.
Glücklicherweise hat der Mapper keinen Namen vergeben, dann wäre das durch mein Filter für die Boundaries-Analyse gerutscht.
Nachher werde ich aus type=multipolygon type=TMC machen und dann ist das hier gefixt. Bei AL6 gab es das Gleiche 3x.

Vorhin musste ich übrigens den Thüringer Landtag ändern, der als MP-Building mit admin_level=4 erfasst war. Schwupps hatten wir 17 Bundesländer wink

Das Ganze ist ein Problem wie osm2pgsql mit echten Multipolygonen (type=multipolygon) umgeht.

Gruss
walter

Last edited by wambacher (2017-06-18 12:34:06)

Offline

Board footer

Powered by FluxBB