Gemeindegrenzen vs. PLZ-Gebiete ... reicht eine Relation, oder zwei?

wambacher · 2011-06-20T10:42:26.000Z

viw:

So dann werde mal konkret. Welche Vereinfachungen Deiner Meinung nach zulässig werden und ab wann eine Auswertbarkeit Verloren geht?

so könnte es aussehen:


./.                   Admin           PLZ                  beides
type                  boundary        boundary             boundary
boundary              administrative  postal_code          administative 
admin_level           *               -                    *
postal_code           -               *                    *

type=multipolygon ist eine “Null-Information”, die imho nicht notwendig ist.
Es handelt sich hier um eine Relation, deren interne Struktur bereits aus den Members hervorgeht.
Das ist ein Multipolygon; das braucht man nicht nochmal dranzuschreiben.
Es muss nur klar sein, dass es sich um eine beliebige Art von Grenze handellt.
beide Informationen in eine Relation reinzuschreiben erscheint mir irgendwie unsauber; dadurch sind schon speziellere Abfragen notwendig.
Andererseits ist das Erfassen/Pflegen der Rels einfacher.

Erst wollte ich type sogar ganz weglassen aber es gibt noch andere Rels mit postal_code (z.B. associatedStreet)

Das ist mein Vorschlag:


./.                   Admin           PLZ
type                  boundary        boundary                
boundary              administrative  postal_code    
admin_level           *               -                    
postal_code           -               *

rein theoretisch könnte man sogar noch boundary=* weglassen.


./.                   Admin           PLZ
type                  boundary        boundary                  
admin_level           *               -                    
postal_code           -               *

aber irgendwie geht mir das zuweit.

Gruss
Walter

viw · 2011-06-20T10:51:18.000Z

wambacher:


./.                   Admin           PLZ
type                  boundary        boundary                  
admin_level           *               -                    
postal_code           -               *

aber irgendwie geht mir das zuweit.

Gruss
Walter


./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

SunCobalt · 2011-06-20T10:55:39.000Z

viw:


./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?

viw · 2011-06-20T10:59:37.000Z

SunCobalt:

viw:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?

Das ist ein interessanter Einwand, aber wenn es der einzige ist, kann man hier ja auch 0 nehmen.

SunCobalt · 2011-06-20T11:04:08.000Z

viw:

SunCobalt:
viw:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
Wie willst Du eine Grenze taggen, deren admin_level Du nicht kennst?
Das ist ein interessanter Einwand, aber wenn es der einzige ist, kann man hier ja auch 0 nehmen.

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

viw · 2011-06-20T11:14:49.000Z

SunCobalt:

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

Mhhh auch ein berechtigter Einwand. Dazu kann ich bei Grenzen auch nichts entgegensetzen. Aber beim ÖPNV könnte man doch auch das type=route verzichten, da man danach ohnehin mit route=* den Type der route spezifiziert. Richtig? Da gäbe es dann auch nichts mehr daran zu interpretieren.

wambacher · 2011-06-20T11:18:06.000Z

viw:


./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *

Und was spricht dagegen?

bis auf die Tatsache, dass type=boundary hier fehlt, nicht viel (*)
Es gibt derzeit in DACH+ ca 230 Rels mit admin_level oder postal_code, die keine Boundaries sind oder zumindest nicht leicht als solche zu erkennen sind.

siehe: http://wnordmann.homeunix.com/images/stories/osm/forum/al_und_plz.txt

(*) ich muss erstmal die berechtigten Einwände von Thomas “verdauen”. wie schon geschrieben, geht mit diese absolute Minimalversion gegen den Strich.

Gruss
Walter

wambacher · 2011-06-20T11:25:57.000Z

viw:

SunCobalt:

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

Mhhh auch ein berechtigter Einwand. Dazu kann ich bei Grenzen auch nichts entgegensetzen. Aber beim ÖPNV könnte man doch auch das type=route verzichten, da man danach ohnehin mit route=* den Type der route spezifiziert. Richtig? Da gäbe es dann auch nichts mehr daran zu interpretieren.

lenk nicht ab
wir reden hier von Grenzen und nur Grenzen. Mach biite zum ÖPNV nen eigenen Thread auf anstatt die Sachen gemeinsam zu bekakeln. Dazu sind die zu unterschiedlich.
Gruss
Walter

viw · 2011-06-20T12:10:21.000Z

wambacher:

viw:
./.                   Admin           PLZ                  beides
admin_level           *               -                    *
postal_code           -               *                    *     
Und was spricht dagegen?
bis auf die Tatsache, dass type=boundary hier fehlt, nicht viel (*)
Es gibt derzeit in DACH+ ca 230 Rels mit admin_level oder postal_code, die keine Boundaries sind oder zumindest nicht leicht als solche zu erkennen sind.

siehe: http://wnordmann.homeunix.com/images/stories/osm/forum/al_und_plz.txt

(*) ich muss erstmal die berechtigten Einwände von Thomas “verdauen”. wie schon geschrieben, geht mit diese absolute Minimalversion gegen den Strich.

Gruss
Walter

Die Auswertung ist schon interessant. Vor allem scheint hier noch das veraltete “associatedStreet” vorhanden zu sein. Bei den admin_level sind es vorwiegend boundary_segment und municipality
Jetzt kann man also darüber streiten ob diese Relationen eine Berechtigung haben für dieses Tag. Bei route und enforcment ist der postal_code sicher genauso falsch wie das admin_level bei collection.
Andererseits sieht man hier auch gut das es offenbar Relationen mit dem Type postal_code gibt, welche nach dem anderen Schema nicht gefunden werden. Gleiches gilt natürlich auch für country und commune

ajoessen · 2011-06-20T12:17:11.000Z

wambacher:

lenk nicht ab
wir reden hier von Grenzen und nur Grenzen. Mach biite zum ÖPNV nen eigenen Thread auf anstatt die Sachen gemeinsam zu bekakeln. Dazu sind die zu unterschiedlich.
Gruss
Walter

Es wäre eine gute Idee, ** nichts ** einfach als “überflüssig” zu betrachten, was in OSM seit Jahren etabliert ist.
osm2pgsql wertet im postprocessing nach dem Import Relationen je nach Typ als Weg, Fläche oder garnicht aus. Das muß man nicht künstlich verkomplizieren.

gruß,
ajoessen

wambacher · 2011-06-20T12:48:52.000Z

ajoessen:

wambacher:

lenk nicht ab
wir reden hier von Grenzen und nur Grenzen. Mach biite zum ÖPNV nen eigenen Thread auf anstatt die Sachen gemeinsam zu bekakeln. Dazu sind die zu unterschiedlich.
Gruss
Walter

Es wäre eine gute Idee, ** nichts ** einfach als “überflüssig” zu betrachten, was in OSM seit Jahren etabliert ist.
osm2pgsql wertet im postprocessing nach dem Import Relationen je nach Typ als Weg, Fläche oder garnicht aus. Das muß man nicht künstlich verkomplizieren.

gruß,
ajoessen

sorry, ich verstehe hier nicht, was du damit meinst.
passt auch nicht zu meinem “dezenten” hinweis, in diesem thread am thema zu bleiben.

Gruss
Walter

ajoessen · 2011-06-20T12:53:03.000Z

wambacher:

ajoessen:

Es wäre eine gute Idee, ** nichts ** einfach als “überflüssig” zu betrachten, was in OSM seit Jahren etabliert ist.
osm2pgsql wertet im postprocessing nach dem Import Relationen je nach Typ als Weg, Fläche oder garnicht aus. Das muß man nicht künstlich verkomplizieren.

sorry, ich verstehe hier nicht, was du damit meinst.
passt auch nicht zu meinem “dezenten” hinweis, in diesem thread am thema zu bleiben.

Das type=* ist bei Grenzen genausowenig überflüssig wie bei Routen, weil sich Rohdatenverarbeitende Programme darauf verlassen, dass es vorhanden ist.

Gruß,
ajoessen

viw · 2011-06-20T14:18:11.000Z

Wir werden also nichts am tagging ändern solange es osm2pgsql gibt.
Warum sollte das unser Ziel sein?

wambacher · 2011-06-20T14:22:06.000Z

ajoessen:

Das type=* ist bei Grenzen genausowenig überflüssig wie bei Routen, weil sich Rohdatenverarbeitende Programme darauf verlassen, dass es vorhanden ist.

Prima,
das deckt sich dann ja hoffentlich mit meinem ersten “Wunschvorschlag”:


./.                   Admin           PLZ
type                  boundary        boundary                
boundary              administrative  postal_code    
admin_level           *               -                    
postal_code           -               *

Mir fehlten nur die Argumente, wieso man type=* dennoch braucht.

wenn jetzt noch Argumente für type=multipolygon kommen, hat sich der Kreis geschlossen und wir stehen wieder am Anfang.
osm2pgsql “zieht” hier aber nicht, der kommt mit type=boundary prima hin.

Gruss
walter

ein klitze-klitze-kleines om (mehr trau ich mich nicht), denn hier taggen wir für Programme, die das anscheinend brauchen , während andere da nicht so unwissend sind

Fabi2 · 2011-06-20T16:21:38.000Z

viw:

SunCobalt:

Was, wenn es andere Dinge gibt oder geben wird, die eine administrative Rangordnung haben? Es wird halt von admin_level ein boundary impliziert. Und wo man impliziert, muss man sich sicher sein, dass das alle anderen intuitiv auch richtig verstehen. Und da habe ich einige Zweifel.

Mhhh auch ein berechtigter Einwand. Dazu kann ich bei Grenzen auch nichts entgegensetzen.

Der Einwand ist nicht wirklich berechtigt. Wenn man eine administrative Grenze, die identisch mit der PLZ-Grenze zusammenfällt mit:

type=boundary
boundary=administrative
admin_level=*
postal_code=*

taggen soll, woraus geht denn dann bitte intuitiv hervor, das das eine PLZ-Grenze ist?

Für die PLZ-Grenze ist das kein Unterschied zur alleinigen Verwendung von postal_code=*.

stephan75 · 2011-06-28T19:00:21.000Z

Sooo, da es ja offenbar keine so richtige Richtung gibt, in welche der Zug gehen soll, werde ich wohl auf Nummer sicher gehen und auch für deckungsgleiche Grenzen jeweils eine einzelne und ggf. somit doppelte Relation anlegen.

Es kann sein, dass der JOSM-Validator das auch schon bemerken kann, wenn ich das vorab richtig gedeutet habe.

Mal schauen wie weit ich komme …

SunCobalt · 2011-06-28T19:11:29.000Z

Redundanz hat bei OSM noch nie geschadet. Evtl mach note=deckungsgleich mit Gemeindegrenze und bei der Gemeindegrenze eine umgekehrte Notiz. Wenn was kaputt geht, ist es superschnell wieder hergestellt.

stephan75 · 2011-10-27T14:36:17.000Z

Sooo, nachdem ich auch nochmal in http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 genauer gelesen habe:

“Sollte die Grenze des PLZ-Gebietes identisch sein mit einer bereits vorhandenen Grenze einer Stadt oder Gemeinde, so können die für PLZ-Gebiete relevanten Tags an die Grenzrelation “angeheftet” werden. Es ist hier nicht zwingend notwendig, eine eigene separate PLZ-Relation zu erstellen.”

Somit werde ich entgegen meiner anfänglichen Arbeitsweise eine handvoll PLZ-Grenzrelationen in Gemeindegrenz-Relationen (inkl. de:amtl_gemeindeschluessel) umwandeln, und zwar wo diese definitiv DECKUNGSGLEICH sind. Allein im Landkreis Lüneburg sind dies bzw. fehlen noch:

21386 Betzendorf, 21409 Embsen, 21391 Reppenstedt, 21360 Vögelsen, 21358 Mechtersen, 21449 Radbruch, 21447 Handorf, 21380 Artlenburg, 21403 Wendisch Evern, 21400 Reinstorf, 21401 Thomasburg, 21371 Tosterglope und 21369 Nahrendorf

GeorgFausB · 2011-10-28T06:56:27.000Z

Moin,

da es thematisch hier mit rein passt:

Wie ist die allgemeine Vorgehensweise, wenn ein PLZ-Gebiet aus mehreren Gemeinden besteht?

Bisher habe ich es oft vorgefunden - und daher auch selbst so gemacht - dass auch bei den Gemeinde-Relationen dann ein postal_code=* steht.
Damit hat man dann aber bei der Auswertung zusätzlich zur Gesamt-PLZ-Relation mehrere kleine PLZ-Relation mit den gleichen Werten.
Andererseits fehlt aber sonst die PLZ, wenn man nur die Gemeinde betrachtet … bzw. sie muss erst woanders gesucht werden.

Gruß
Georg

wambacher · 2011-10-28T07:04:05.000Z

GeorgFausB:

Wie ist die allgemeine Vorgehensweise, wenn ein PLZ-Gebiet aus mehreren Gemeinden besteht?

Bisher habe ich es oft vorgefunden - und daher auch selbst so gemacht - dass auch bei den Gemeinde-Relationen dann ein postal_code=* steht.
Damit hat man dann aber bei der Auswertung zusätzlich zur Gesamt-PLZ-Relation mehrere kleine PLZ-Relation mit den gleichen Werten.
Andererseits fehlt aber sonst die PLZ, wenn man nur die Gemeinde betrachtet … bzw. sie muss erst woanders gesucht werden.

moin moin, georg
ich hab die PLZ als addr:postcode noch bei den Häusern und beim place=city, name=* drin. Das sollte eigentlich reichen.

Gruss
Walter