You are not logged in.

#1 2013-11-15 15:52:47

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Pflege der deutschen PLZ-Daten in OSM

Hallo!

Dieser Thread diskutiert das Vorgehen und die Fortschritte bei der Konsolidierung der (vornehmlich deutschen) PLZ-Daten in OSM.
Damit führt er die betreffenden Posts aus dem Thread zur OSMPC Map separat weiter.

Diskutiert wurde dort insbesondere die vollständige Abbildung der PLZ-Gebiete in dedizierten "boundary=postal_code"-Relationen.
Darüber hinaus ist zu klären, wie und ob PLZ-Angaben in admin-Relationen noch Anwendung finden sollen.

Ziel ist einerseits eine aktuelle und vollständige PLZ-Karte für Deutschland (bzw. die konsistenten Daten für deren Erstellung) und eine Einigung über das "korrekte" Tagging (mit einem entsprechenden Wiki-Beitrag).

Viele Grüße
Jan

Wiki-Artikel zum Thema: Konsolidierung der PLZ-Relationen in Deutschland 2013
Für Kontrolle und Überblick: Wambachers PLZ-Karte

Last edited by Gehrke (2014-07-03 17:30:11)

Offline

#2 2013-11-15 16:09:30

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

Status quo der deutschen PLZ in OSM (23.11.2013, ca. 21:00 Uhr):

  • Echte PLZ-Relationen:  6266

  • PLZ ohne eigene Relation:  1942 (davon 978 mit postal_code_level=8)

  • Erfasste PLZ:  8208 (in DE mit tag postal_code und boundary=postal_code oder boundary=administrative)

  • PLZ-Gebiete in DE:  8208 (laut Dt. Post AG, Stand Mai 2013; unbekannt ob mit oder ohne die 4 DE-PLZ in Österreich)

  • Bekannte fehlende PLZ:  keine

  • Offene Polygone:  (unbekannt)

Fazit: Alle PLZ sind abgedeckt, wenn nicht noch falsche dabei sind.

Aktuellere Werte sind im Wiki-Artikel zu finden.

Last edited by Gehrke (2013-11-25 09:06:01)

Offline

#3 2013-11-15 19:55:38

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,434
Website

Re: Pflege der deutschen PLZ-Daten in OSM

Vorschlag:
* Nur echte PLZ-Relationen: boundary=postal_code, da diese auch mehrere Gemeinden oder Verwaltungsbereiche betreffen können.
* Administrative in PLZ überführen und in admniistrative key-postal_code ändern in postcode (damit noch findbar)

Offline

#4 2013-11-15 20:57:34

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

Re: Pflege der deutschen PLZ-Daten in OSM

Ich versuche mal, die aktuellen offenen Punkte/Fragen zusammenzustellen:

1: Es gibt Gebiete, wo die PLZ nur in Administrativen Grenzen erfasst sind.
2: Es gibt Gebiete, wo sowohl "echte" PLZ-Relationen als auch Admin-Relationen mit postal_code vorhanden sind.
3: Welchen "Namen" sollen die PLZ-Relationen erhalten? (note? description? identifier? ?)
4: was machen wir mit dem postal_code in den  Admin-Boundaries?
5: manche Relationen sind noch mit type=multipolygon erfasst.
6: tbc.

Meine Vorschläge:
1: Admin-Boundaries duplizieren, im Original postal_code und postal_code_level entfernen, in der Kopie die administrativen Tags entfernen.
   was mit postal_code geschieht, siehe 4.
2: Admin-Boundaries bereinigen
3: unklar. Derzeit haben von 6172 PLZ-Relationen 5851 note, 151 name, 0 ref, identifier 4 und 59 description, wobei mehrfache Tags auch vorkommen.
   Was mit der Differenz zu den 6172 ist, hab ich noch nicht rausgefunden aber der Trend ist klar.
4: postcode gefällt mir ganz gut. sollte nach einem Vorschlag von Gehrke die PLZ der Gemeindeverwaltung sein.
5: auf type=boundary umstellen

Gruss
walter

edit: tüpo

Last edited by wambacher (2013-11-15 23:10:23)

Offline

#5 2013-11-15 22:28:32

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Pflege der deutschen PLZ-Daten in OSM

wambacher wrote:

Ich versuche mal, die aktuellen offenen Punkte/Fragen zusammenzustellen:
...
3: Welchen "Namen" sollen die PLZ-Relationen erhalten? (note? description? identifier? ?)
4: was machen wir mit dem postal_code in den  Admin-Boundaries?
...
Mein Vorschläge:
...
3: unklar. Derzeit haben von 6172 PLZ-Relationen 5851 note, 151 name, 0 ref, identifier 4 und 59 description, wobei mehrfache Tags auch vorkommen.
   Was mit der Differenz zu den 6172 ist, hab ich noch nicht rausgefunden aber der Trend ist klar.
4: postcode gefällt mir ganz gut. sollte nach einem Vorschlag von Gehrke die PLZ der Gemeindeverwaltung sein.
...

Hallo Walter

Zu Punkt 3:
Ich würde die note=* lassen und die name=* zu note=* ändern. Gegebenfalls kann man zur Einführung identifier als zusätzliches Tagg verwenden.
Die 59 description=* würde ich ebenfalls lassen wie sie sind. Gegebenenfalls würde ich ein früheres note=* wieder ergänzen.

Zu Punkt 4:
Das postcode gefällt mir wegen der Verwechslungsgefahr überhaupt nicht. Wenn man die PLZ des Verwaltungszentrums eintragen will, dann sollte man das auch deutlich sagen. Etwas wie admin_centre:postcode würde diese Anforderung erfüllen.

Einfach postcode für diese Funktion wieder zu verwenden öffnet Missverständnissen Tür und Tor.

Edbert (EvanE)

Offline

#6 2013-11-15 22:41:12

seichter
Member
Registered: 2011-05-21
Posts: 2,727

Re: Pflege der deutschen PLZ-Daten in OSM

wambacher wrote:

1: Admin-Boundaries duplizieren, im Original postal_code und postal_code_level entfernen, in der Kopie die administrativen Tags entfernen.
   was mit postal_code geschieht, siehe 4.

Ich habe das bei ein paar Gebieten gemacht: Ist nicht viel, zieht sich aber doch hin. Problem: Es gibt hunderte davon. Für mich lohnt sich der Aufwand bei 1:1-Gebieten nicht, aber wer es unbedingt machen will ...

wambacher wrote:

2: Admin-Boundaries bereinigen

Zwingend für mich da, wo mehrere Gemeinden dieselbe PLZ haben -> PLZ-Relation, postal_code aus admin-Rel. löschen oder umbenennen (mein Vorschlag: per is_in_ unschädlich machen)

wambacher wrote:

3: unklar. Derzeit haben von 6172 PLZ-Relationen 5851 note, 151 name, 0 ref, identifier 4 und 59 description, wobei mehrfache Tags auch vorkommen.
   Was mit der Differenz zu den 6172 ist, hab ich noch nicht rausgefunden aber der Trend ist klar.

Gegen note gibt es Einwände wegen des eigentlichen Zweckes, description ist eigentlich auch für etwas anderes gedacht (und wird in JOSM auch nicht in der Relationenliste angezeigt), name führt zu Doppelanzeigen in der Karte, identifier ist ein Versuchsballon (wird natürlich nicht angezeigt)

wambacher wrote:

4: postcode gefällt mir ganz gut. sollte nach einem Vorschlag von Gehrke die PLZ der Gemeindeverwaltung sein.

keine Einwände (meinerseits)

wambacher wrote:

5: auf type=boundary umstellen

+1

Offline

#7 2013-11-15 22:45:13

seichter
Member
Registered: 2011-05-21
Posts: 2,727

Re: Pflege der deutschen PLZ-Daten in OSM

EvanE wrote:

Das postcode gefällt mir wegen der Verwechslungsgefahr überhaupt nicht. Wenn man die PLZ des Verwaltungszentrums eintragen will, dann sollte man das auch deutlich sagen. Etwas wie admin_centre:postcode würde diese Anforderung erfüllen.

Finde ich auch treffender, insbesondere da, wo es mehrere PLZ pro Kommune gibt.

Zusatz: Ist eine Anwendung denkbar, wo man alle PLZen einer Kommune aufgelistet haben möchte?

Last edited by seichter (2013-11-15 22:49:01)

Offline

#8 2013-11-15 23:23:02

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

Re: Pflege der deutschen PLZ-Daten in OSM

EvanE wrote:

Zu Punkt 3:
Die 59 description=* würde ich ebenfalls lassen wie sie sind. Gegebenenfalls würde ich ein früheres note=* wieder ergänzen.

lohnt sich wohl nicht. umtaggen sollte reichen.

 ?column? | postal_code |              description              |    note    
----------+-------------+---------------------------------------+------------
  1437293 | 51107       | 51107 Köln                            | 
  1437290 | 51069       | 51069 Köln                            | 
  1435109 | 53844       | 53844 Troisdorf                       | 
  1434451 | 53177       | Bereich mit Postleitzahlen 53177 Bonn | 53177 Bonn
  1437294 | 51143       | 51143 Köln                            | 
  1434546 | 53123       | Bereich Postleitzahlen 53123 Bonn     | 53123 Bonn
  1434470 | 53225       | Bereich Postleitzahlen 53225 Bonn     | 53225
  1434453 | 53125       | Bereich mit Postleitzahl 53125 Bonn   | 53125 Bonn
  1435448 | 50739       | 50739 Köln                            | 
  1435426 | 50935       | 50935 Köln                            | 
  1435451 | 50933       | 50933 Köln                            | 
  1435434 | 50767       | 50767 Köln                            | 
  1435449 | 50827       | 50827 Köln                            | 
  1435442 | 50825       | 50825 Köln                            | 
  1435431 | 50735       | 50735 Köln                            | 
  1435424 | 50733       | 50733 Köln                            | 
  1437284 | 51105       | 51105 Köln                            | 
  1437283 | 51063       | 51063 Köln                            | 
  1437286 | 51103       | 51103 Köln                            | 
  1437295 | 51065       | 51065 Köln                            | 
  1437288 | 51149       | 51149 Köln                            | 
  1437291 | 51067       | 51067 Köln                            | 
  1437292 | 51145       | 51145 Köln                            | 
  1435429 | 50969       | 50969 Köln                            | 
  1435443 | 50939       | 50939 Köln                            | 
  1435435 | 50858       | 50858 Köln                            | 
  1435428 | 50829       | 50829 Köln                            | 
  2024404 | 50968       | 50968 Köln                            | 
  1435439 | 50996       | 50996 Köln                            | 
  1435427 | 50765       | 50765 Köln                            | 
  1435450 | 50999       | 50999 Köln                            | 
  1435436 | 50937       | 50937 Köln                            | 
  1434472 | 53119       | Bereich Postleitzalen 53119 Bonn      | 53119 Bonn
  1434471 | 53117       | 53117 Bonn                            | 
  1434454 | 53179       | Bereich mit Postleitzahlen 53179 Bonn | 53179 Bonn
  1434459 | 53175       | Bereich Postleitzahlen 53175 Bonn     | 53175 Bonn
  1434457 | 53173       | 53173 Bonn                            | 
  1434468 | 53227       | 53227 Bonn                            | 
  1435430 | 50668       | 50668 Köln                            | 
  1434543 | 53127       | Bereich Postleitzalen 53127 Bonn      | 53127 Bonn
  1435438 | 50678       | 50678 Köln                            | 
  1435440 | 50677       | 50677 Köln                            | 
  1435421 | 50931       | 50931 Köln                            | 
  1435432 | 50823       | 50823 Köln                            | 
  1435444 | 50679       | 50679 Köln                            | 
  1457041 | 51379       | 51379 Leverkusen                      | 
  1457042 | 51371       | 51371 Leverkusen                      | 
  1435437 | 50670       | 50670 Köln                            | 
  1434541 | 53113       | Bereich Postleitzahlen 53113 Bonn     | 53113 Bonn
  1434469 | 53229       | Bereich Postleitzahlen 53229 Bonn     | 53229 Bonn
  1434477 | 53111       | Bereich Postleitzalen 53111 Bonn      | 53111 Bonn
  1435445 | 50859       | 50859 Köln                            | 
  1437285 | 51109       | 51109 Köln                            | 
  1457038 | 51373       | 51373 Leverkusen                      | 
  1437287 | 51061       | 51061 Köln                            | 
  1457037 | 51377       | 51377 Leverkusen                      | 
  1457043 | 51469       | 51469 Bergisch Gladbach               | 
  1437289 | 51147       | 51147 Köln                            | 
  1435425 | 50769       | 50769 Köln                            | 
(59 rows)

Offline

#9 2013-11-16 10:41:04

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

seichter wrote:
EvanE wrote:

Das postcode gefällt mir wegen der Verwechslungsgefahr überhaupt nicht. Wenn man die PLZ des Verwaltungszentrums eintragen will, dann sollte man das auch deutlich sagen. Etwas wie admin_centre:postcode würde diese Anforderung erfüllen.

Finde ich auch treffender, insbesondere da, wo es mehrere PLZ pro Kommune gibt.

Recht langer tag, aber da könnte ich mit leben. Ich habe lange hin- und herüberlegt, ob postcode oder sogar einfach postal_code reichen würde (wäre ja für die Auswertung kein Problem mehr, sobald komplette PLZ-Relationen da sind). Gegen postcode spricht aus meiner Sicht, dass wir damit einen tag-key mit eigener Bedeutung haben, der aber sehr, sehr ähnlich zu postal_code wäre. (Verwechslungsgefahr!).

Gegen postal_code spricht, denke ich, Folgendes: Normalerweise gibt postal_code die PLZ für das gesamte Element (Relation, Polygon, Street) an.  Bei admin-Relationen gilt dies jedoch (sehr) oft nicht. Bei Großstädten ist das klar. Aber selbst bei ländlichen Gemeinden, die vermeintlich nur eine PLZ haben (auch laut Wikipedia oder Post-PLZ-Suche), gibt es dann doch wieder abseitige Gebiete (Höfe am Gemeinderand), die eine andere PLZ haben.

Fazit: Entweder gar keine PLZ-Angaben für Gemeinden oder eine klar abgegrenzte Angabe mit eigener Bedeutung wie admin_centre:postcode.
Im Moment tendiere ich zu letzterem - wie von mir bereits vorgeschlagen mit Bezug zu den offiziellen Angaben von DESTATIS.

seichter wrote:

Ist eine Anwendung denkbar, wo man alle PLZen einer Kommune aufgelistet haben möchte?

Natürlich ist solch eine Anwendung denkbar. Ich hätte das gerne. Aber es wäre, wie bereits angedeutet, mit tags an den admin-Relationen (Beispiel is_in_postal_code) nicht vernünftig zu leisten. Sowas ist sehr fehleranfällig und schwer zu warten.

Der einzige Weg dafür scheint mir tatsächlich ein spatial query zu sein, also die Überlappung von admin-Relationen mit postal-Relationen.

Offline

#10 2013-11-16 10:52:39

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

Ich möchte noch einmal eine kleine Lanze für das Tagging mit "postal_code_level=8" brechen.

Die Sinnhaftigkeit und der Nutzen dieses tags bei PLZ-Relationen kann mit Recht angezweifelt werden.
Ich sehe aber auch Argumente dafür. Es besteht ja eine gewisse Parallelität mit "admin_level=8". Wenn man nun fragt: "Aber was sind dann andere levels?", sage ich, in Deutschland gibt es neben Postleitgebieten (5 Ziffern) ja noch Postleitregionen (erste 2 Ziffern) und Postleitzonen (führende Ziffer). Ich könnte mir vorstellen, dass es hier nochmal eine sinnvolle Anwendung für Relationen auf diesen Ebenen geben könnte. Als "postal_code_level" könnte ich mir da (ähnlich zu den admin-Relationen) die Werte 4 (PLZ-Zone) und 6 (PLZ-Region) vorstellen.

Darüber hinaus gibt es in Europa und der Welt ja unterschiedliche Postgebiete für jede Nation. Diese hätten, auch wenn es sie (noch) nicht explizit in OSM gibt, dann logischerweise postal_code_level=2.
Passend zu diesem internationalen Thema: Wie markieren wir eine PLZ-Relation bzgl. des Postleitsystems bzw. "operators"?

Offline

#11 2013-11-16 13:13:56

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

Re: Pflege der deutschen PLZ-Daten in OSM

Gehrke wrote:

Fazit: Entweder gar keine PLZ-Angaben für Gemeinden oder eine klar abgegrenzte Angabe mit eigener Bedeutung wie admin_centre:postcode.
Im Moment tendiere ich zu letzterem - wie von mir bereits vorgeschlagen mit Bezug zu den offiziellen Angaben von DESTATIS.

mal so ins Blaue gedacht: Die PLZ für das "Gemeindezentrum" / Stadtverwaltung / admin_centre,  ... steht doch im Wiki, genauso wie andere Daten, die wir bei OSM nicht unbedingt pflegen (wollen). Reicht das nicht aus?

Gehrke wrote:
seichter wrote:

Ist eine Anwendung denkbar, wo man alle PLZen einer Kommune aufgelistet haben möchte?

Der einzige Weg dafür scheint mir tatsächlich ein spatial query zu sein, also die Überlappung von admin-Relationen mit postal-Relationen.

Das ist mMn genau der richtige Weg, mit OSM-Daten umzugehen: Relationen oder auch ein einfache geschlossene Ways beschreiben  Flächen; mit Flächen kann die jedes vernünftige GIS-Programm "rechnen" und unsere Datenbank "spricht" GIS.
Jeder von euch, der z.B. zum Rendern eine eigene kleine DB erstellt - und sei es auch nur zum einmaligen Gebrauch - hat die tollsten technischen Voraussetzungen - er muss sie nur benutzen.

select distinct adm.name,
                -(pc.osm_id) osm_id,
                pc.postal_code,
                coalesce(pc.note,pc.name,pc.tags->'description') "Name"
  from planet_osm_polygon adm, 
       planet_osm_polygon pc
 where adm.osm_id='-62713'
   and pc.boundary='postal_code'
   and pc.way && adm.way
   and st_intersects(st_buffer(pc.way,-0.00001),adm.way)
 order by pc.postal_code;

 name  | osm_id  | postal_code |    Name     
-------+---------+-------------+-------------
 Essen | 2085719 | 45127       | 45127 Essen
 Essen | 2081504 | 45128       | 45128 Essen
 Essen | 2073330 | 45130       | 45130 Essen
 Essen | 2070572 | 45131       | 45131 Essen
 Essen | 2060351 | 45133       | 45133 Essen
 Essen | 2055204 | 45134       | 45134 Essen
 Essen | 2064512 | 45136       | 45136 Essen
 Essen | 2079745 | 45138       | 45138 Essen
 Essen | 2094676 | 45139       | 45139 Essen
 Essen | 2133092 | 45141       | 45141 Essen
 Essen | 2101976 | 45143       | 45143 Essen
 Essen | 2083959 | 45144       | 45144 Essen
 Essen | 2082575 | 45145       | 45145 Essen
 Essen | 2074930 | 45147       | 45147 Essen
 Essen | 2063069 | 45149       | 45149 Essen
 Essen | 2010974 | 45219       | 45219 Essen
 Essen | 2047909 | 45239       | 45239 Essen
 Essen | 2046171 | 45257       | 45257 Essen
 Essen | 2047771 | 45259       | 45259 Essen
 Essen | 2100882 | 45276       | 45276 Essen
 Essen | 2050992 | 45277       | 45277 Essen
 Essen | 2100868 | 45279       | 45279 Essen
 Essen | 2049452 | 45289       | 45289 Essen
 Essen | 2139190 | 45307       | 45307 Essen
 Essen | 2139191 | 45309       | 45309 Essen
 Essen | 2131119 | 45326       | 45326 Essen
 Essen | 2095780 | 45327       | 45327 Essen
 Essen | 2104867 | 45329       | 45329 Essen
 Essen | 2074493 | 45355       | 45355 Essen
 Essen | 2106265 | 45356       | 45356 Essen
 Essen | 2072078 | 45357       | 45357 Essen
 Essen | 2055456 | 45359       | 45359 Essen
(32 rows)
Time: 182,183 ms

Gruss
walter

ps: coalescs() listet den ersten gefundenen Wert auf, also erst Note, dann Name, dann Description
     st_buffer() verkleinert das zu suchenden Gebiet ein wenig, damit die umliegenden Städte nicht einbezogen werden
     und st_intersects() macht den eigentlichen Job.

Last edited by wambacher (2013-11-16 13:14:46)

Offline

#12 2013-11-16 13:40:27

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

wambacher wrote:

ps: coalescs() listet den ersten gefundenen Wert auf, also erst Note, dann Name, dann Description
     st_buffer() verkleinert das zu suchenden Gebiet ein wenig, damit die umliegenden Städte nicht einbezogen werden
     und st_intersects() macht den eigentlichen Job.

Und A && B nutzt den Geo-Index, um nicht jedes Polygon mit jedem anderen vergleichen zu müssen, nehme ich an.

Das Konstrukt mit st_buffer() gefällt mir weniger. Müsste es nicht auch gehen mit st_crosses() OR st_contains() statt st_intersect() ?

Die Performanz wäre aber zu prüfen.

Offline

#13 2013-11-16 23:10:43

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

Re: Pflege der deutschen PLZ-Daten in OSM

Gehrke wrote:

Und A && B nutzt den Geo-Index, um nicht jedes Polygon mit jedem anderen vergleichen zu müssen, nehme ich an.

Jo, ist irgendwie schneller als ohne. Bei manchen spatialen Abfragen steht in der Doju, dass er sowas automatisch macht, aber bei st_intersects nicht. Da bin ich auf Nummer sicher gegangen.

Das Konstrukt mit st_buffer() gefällt mir weniger. Müsste es nicht auch gehen mit st_crosses() OR st_contains() statt st_intersect() ?

Mag sein, aber hier ging es mir erstmal darum, das Prinzip anschaulich darzustellen - und die Frage von seichter mit einem klaren JA zu beantworten.

Gruss
walter

Offline

#14 2013-11-17 18:45:30

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

So. Ich habe heute 7 PLZ-Relationen in Düsseldorf von Haus zu Haus gezeichnet und bin ganz geschafft.
5 PLZ bleiben (dort) übrig. Nächste Woche könnte der große Moment kommen: Alle PLZ-Gebiete in OSM abgedeckt!

Offline

#15 2013-11-18 09:35:08

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

Noch ein paar Fakten zur Konsolidierung:

Folgende PLZ gehören weder zu einer PLZ-Relation noch zu einer Gemeinde, sondern nur zu einer Verwaltungsgemeinschaft oder zu einem Ortsteil:
06792, 06796, 14789, 23569, 23570, 23629, 27412, 27419, 27628, 27729, 37136, 38173, 38312

EDIT: Habe nun alle umgewandelt (als boundary=postal_code dupliziert).

Last edited by Gehrke (2013-11-19 12:21:49)

Offline

#16 2013-11-18 10:15:25

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

wambacher wrote:

Meine Vorschläge: [...]
5: auf type=boundary umstellen

Im Moment sind nur 1024 PLZ-Relationen als "type=boundary" getaggt. Der Rest (5053) ist "type=multipolygon".

Das soll aber nicht heißen, dass ich das nicht ändern wollte.

Offline

#17 2013-11-19 09:20:05

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

Schadensbericht. Was durch den Oberförster gestern postalisch kaputt gegangen ist:

55234 Albig, 55599 Gau-Bickelheim, 67292 Kirchheimbolanden, 67294 Kirchheimbolanden, 67808 Steinbach, 67819 Kriegsfeld, 67822 Winterborn

EDIT: Nach den Korrekturen von Frederik ist wieder alles in Ordnung.

Last edited by Gehrke (2013-11-20 13:28:57)

Offline

#18 2013-11-19 15:48:39

seichter
Member
Registered: 2011-05-21
Posts: 2,727

Re: Pflege der deutschen PLZ-Daten in OSM

Wenn ich mir nach getaner Arbeit die folgende Gegend ansehe http://osm.wno-edv-service.de/plz/?zoom … FTTTFFFFTT, kommen mir schon Zweifel, ob innerstädtische PLZ-boundaries Sinn machen.
Zur Erläuterung: Hier haben Längs- und Querstraßen unterschiedliche PLZ, bei Eckhäusern hängt die Zugehörigkeit davon ab, welcher Straße sie zugeordnet wurden.

Offline

#19 2013-11-19 15:55:52

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

seichter wrote:

Wenn ich mir nach getaner Arbeit die folgende Gegend ansehe http://osm.wno-edv-service.de/plz/?zoom … FTTTFFFFTT, kommen mir schon Zweifel, ob innerstädtische PLZ-boundaries Sinn machen.
Zur Erläuterung: Hier haben Längs- und Querstraßen unterschiedliche PLZ, bei Eckhäusern hängt die Zugehörigkeit davon ab, welcher Straße sie zugeordnet wurden.

Das ist aber auch ein Extremfall. Und so schlimm finde ich es auch gar nicht. Durch Walters neue Art Grenzen zu zeichnen (mit Margin), sieht es reingezoomt auch schlimmer aus als es ist.

Ein Nutzen der PLZ-Gebiete ist ja auch, dass man geographisch (spatial query) die PLZ eines Hauses/Punktes ermitteln kann. Die sind ja nicht immer getaggt.

Offline

#20 2013-11-19 16:02:57

seichter
Member
Registered: 2011-05-21
Posts: 2,727

Re: Pflege der deutschen PLZ-Daten in OSM

Gehrke wrote:

Ein Nutzen der PLZ-Gebiete ist ja auch, dass man geographisch (spatial query) die PLZ eines Hauses/Punktes ermitteln kann. Die sind ja nicht immer getaggt.

Sehe ich schon ein. In dieser Gegend habe ich aber versucht, darauf zu achten, dass die PLZ auch an den Häusern hängt, aus den Grenzen allein wird man da ja (mit dem Auge) nicht schlau.

Offline

#21 2013-11-19 16:28:02

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

Re: Pflege der deutschen PLZ-Daten in OSM

Gehrke wrote:

Das ist aber auch ein Extremfall. Und so schlimm finde ich es auch gar nicht. Durch Walters neue Art Grenzen zu zeichnen (mit Margin), sieht es reingezoomt auch schlimmer aus als es ist.

Stimmt, so extrem hab ich das auch noch nicht gesehen; werde da wohl nachbessern und dieses "Schrumpfen" abhängig vom Zoom-Level machen.

Schaun 'mer mal.
Walter

edit: ist jetzt in der TODO-Liste Nr 77

Last edited by wambacher (2013-11-19 16:35:37)

Offline

#22 2013-11-20 16:36:46

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

Re: Pflege der deutschen PLZ-Daten in OSM

seichter wrote:

Wenn ich mir nach getaner Arbeit die folgende Gegend ansehe http://osm.wno-edv-service.de/plz/?zoom … FTTTFFFFTT, kommen mir schon Zweifel, ob innerstädtische PLZ-boundaries Sinn machen.

Immer noch? Probier es einfach noch mal aus smile

Gruss
walter

ps: 1x Reload machen oder maximal 2 Stunden warten.

Last edited by wambacher (2013-11-20 16:39:21)

Offline

#23 2013-11-20 20:28:24

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Pflege der deutschen PLZ-Daten in OSM

Um 19:20 Uhr Z-Zeit war es soweit! Mit Edit 19021162 sind nun alle PLZs Düsseldorfs und damit vielleicht gar alle Deutschlands mit einer postal_code- oder admin-Boundary (admin_level=8) erfasst.

Eine Menge Arbeit findet damit einen Abschluss. Aber das führt jetzt natürlich nur zum nächsten Schritt: einem kontinuierlichen Verbesserungsprozess. Die bestehenden Gebiete sind bzgl. ihrer Detailausdehnung zu überprüfen. Außerdem müssen alle Änderungen der PLZ-Gebiete mitgepflegt werden.

Offline

#24 2013-11-20 23:11:27

seichter
Member
Registered: 2011-05-21
Posts: 2,727

Re: Pflege der deutschen PLZ-Daten in OSM

wambacher wrote:

Immer noch? Probier es einfach noch mal aus smile

Ich habe mich ja nicht an der PLZ-Karte gestoßen, sondern am irrwitzigen Verlauf der Grenze. Der ist nicht besser geworden.

Was besser geworden ist, ist aber die Karte insbesondere bei hohen Zoomleveln, dadurch konnte ich jetzt eine kleine Unstimmigkeit erkennen: Die Grenze geht jetzt sogar durch ein Doppelhaus, bei dem die Hälften zu verschiedenen Straßen gehören. Das artet fast schon in Micro-Tagging aus.

Offline

#25 2013-11-21 00:21:41

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

Re: Pflege der deutschen PLZ-Daten in OSM

seichter wrote:

Ich habe mich ja nicht an der PLZ-Karte gestoßen, sondern am irrwitzigen Verlauf der Grenze. Der ist nicht besser geworden.

so ist er aber nun mal im richtigen Leben. http://osm.wno-edv-service.de/plz/?zoom … FFTFFFFFFT Die 4 hellblauen Nodes am der Konrad-Adenauer-Ring sind nun mal so und hier ist (noch) unsere PLZ-Grenze falsch. Die macht da wohl einen Schlenker nach Nord-West.

Was besser geworden ist, ist aber die Karte insbesondere bei hohen Zoomleveln, dadurch konnte ich jetzt eine kleine Unstimmigkeit erkennen: Die Grenze geht jetzt sogar durch ein Doppelhaus, bei dem die Hälften zu verschiedenen Straßen gehören.

Genau das zu zeigen, war mein Ziel.

Das artet fast schon in Micro-Tagging aus.

That's Live

Gruss
walter

ps:. ich hatte wirklich verstanden, daß dir die Genauigkeit der Darstellung nicht exakt genug war - und diese Meinung natürlich geteilt.

Offline

Board footer

Powered by FluxBB