Wochenaufgabe KW33/34 Adressen ohne Strasse

Bitte keine addr:=-tags an Stolpersteine hängen. Stolpersteine haben keine Adresse. Zur Not memorial:addr=* verwenden, wenn es für den Vollständigkeitsabgleich benötigt wird.

Wenn du sowas mit Overpass turbo zählen willst, dann musst du, aus den Gründen die du bereits genannt hast, einzelne Abfragen für nodes, ways und relations durchführen. Sonst nützt ein Vergleich mit der google Tabelle nichs.

Bin kein Overpass-User und kann das daher nicht beantworten.

Ok, dann frag ich mal anders herum: die Abfrage basiert ja bestimmt auf mind. einem SQL Statement. Kann man das irgendwo nachlesen? Ich würde dann mein Overpass Statement ggfs. überarbeiten und neu posten.

Gut, wenn man die ganzen recurse Dinger weglässt und mit out geom meta arbeitet, ist die Zahl schon recht nahe dran: 2030 (nodes: 288, ways: 1742, relations: 0) vs. 2059. Schade, dass out geom noch nicht von Turbo gerendert wird, sonst würde ich gleich auf diese Form umsteigen. Das Ticket ist noch offen…

http://overpass-turbo.eu/s/4Bj

Da ich ein eigenes DB-Schema habe, würde die SQL-Abfrage nicht viel helfen. Meine Definition einer Straßenangabe ist: Nehme entweder “addr:street”, “addr:place” oder “name” von associatedStreet. Trifft nichts zu, ist die Straße “null”. Ich zähle nun alle Fälle (nur nodes und ways), wo es zwar eine Hausnummer gibt, aber die Straße “null” ist, und gruppiere diese Fälle nach Kreisgebieten.

Prima, das hilft mir schon mal sehr weiter. Da muss ich wohl nur noch addr:place nachrüsten. Andererseits würde das die Ergebnismenge aus der Overpass Query eher nochmal reduzieren. Hoffen wir mal, dass der Unterschied von 29 Treffern der zeitlichen Unschärfe geschuldet ist.

Edit: Aktualisierte Query ist auf der Overpass Beispielseite zu finden.

Uii, war mir neu.

Da käme ich jetzt gerne drauf zurück, alle Boundaries aus overpass holen ist am Stück etwas schwieriger.

Bei meinem Versuch den join (die Verknüpfung) zur CSV Datei über den amtlichen Schlüssel zu machen, bin ich gescheitert, nehme jetzt Name. Ich bekomme in QGIS den Schlüssel nur ohne führende Null gelesen. Den Datentyp String per CSVT angeben habe ich versucht, in der Attributtabelle sind sie (die führenden Nullen) dann am Ende trotzdem weg.

Christoph (Gmail adresse: thefive.osm@…)

Hast du es denn schon mit “meinen” Boundaries versucht? Alle Landkreise (AL6) einer Region (ich empfehle Niedersachsen) herunterzuladen, ist doch ein Klacks. Nur für alle 400 Landkreise von Deutschland “am Stück” müsste ich aktiv werden - das mach ich aber erst wenn du die Sache im Griff hast.

Gruss
walter

Wenn man die Zahlen in eine Tabelle importiert, klappt das recht schnell, z.B. mit Postgres:

CREATE TABLE measurements
(
id integer NOT NULL,
schluessel text,
name text,
count integer,
CONSTRAINT measurements_pkey PRIMARY KEY (id)
)
WITH (
OIDS=FALSE
);

copy measurements from ‘/home/couch/2014-08-15_de-county-addresses-without-street.csv’ DELIMITER ‘;’ CSV HEADER ENCODING ‘ISO-8859-1’;

Original

Join-Kriterium: measurements schluessel → REGION_KEY

Bei der Tabellenauswahl darauf achten, dass auch Tabellen ohne Geometry angezeigt werden. Eingebunden in QGis war direkt das Shape-File von Walter.

Jetzt schaue ich mal noch, ob das direkt mit einem CSV-File klappt…

Zunächst ein namesgleiches CSVT-File erzeugt: (siehe Link):


"Integer","String","String","Integer"

Dann CSV importiert mit Encoding ISO-8859-1 (ist aber nicht so wichtig).

Join-Kriterium: 2014-08-15_de-county-addresses-without-street schluessel → REGION_KEY

funzt auch.

Das mit dem Join in QGIS kannte ich noch nicht. Habe bisher immer die Werte einer SQL-Tabelle dargestellt und da war immer alles drin was ich brauchte.

Hatte mich schon gefragt, wie man die Statistik-Daten nachträglich in den Shape reinkriegt - aber das hat sich ja nun erledigt.

Danke und Gruss
walter

ps: QGIS gefällt mir immer besser :slight_smile:

Feddich:

[https://osm.wno-edv-service.de/DataServer/osm/files/alle_al6_von_deu.zip]](https://osm.wno-edv-service.de/DataServer/osm/files/alle_al6_von_deu.zip])

Mal(e) mit Zufallsfarben.

Gruss
walter

Sorry, hab mich irgendwie beim Zitieren vertan.

So sieht das hier aus (Ubuntu mit QGis 2.4.0)

Und so bei mir mit dem folgenden CSVT File.

"Integer","String","String","Integer"

Ich habe alle Kombinationen probiert, “;” “,”…

Allerdings kein Ubuntu sondern Mac.

Die neuen Zahlen für fehlende Straßenangaben sind da (etwas verzögert am Sonntag) und als CSV hochgeladen (Datenstand ca. 2014-08-16T20:20Z):

Insgesamt gibt es in Deutschland noch 91.913 Fälle (Tag davor 100.514). Wieder ein gutes Stück vorangekommen.

Die Highlights hervorzuheben, überlasse ich mal TheFive.

Hmm, bei mir sind Spalte 2 und 3 noch QString, bevor sie über das CSVT als String interpretiert werden. Die Frage ist, warum der Schluessel schon als double reinkommt. Seltsam.

Google Calc
ist aktuell.

30% der Fehler sind gefixt, 40.000 in absolut. Die 100.000 er Marke ist geknackt.

Der Kreis Borken ist nicht mehr auf Platz 2 (zu viel QGIS :slight_smile: ), und wurde von Hamburg abgelöst.
Der Landkreis Harburg ist mit -1.668 neu eingestiegen und voll im Rennen.

Und was mit am meisten freut, es kommen immer noch Kreise dazu:

Landkreis Saarlouis
Kreis Pinneberg
Landkreis Neunkirchen
Wetteraukreis
Landkreis Waldeck-Frankenberg
Landkreis Sonneberg
Landkreis Zwickau
Landkreis Coburg
Landkreis Haßberge
Freiburg im Breisgau
Emden
Landkreis Meißen
Landkreis Merzig-Wadern
Duisburg

Christoph

Danke! In der Spalte für den 15. sind noch Geisterwerte/Artefakte.

Bin cachen fix ich später :slight_smile: