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

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

stephan75 · 2011-10-28T12:47:38.000Z

GeorgFausB:

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.

Hi Georg,

das ist meiner Meinung nach prinzipiell nicht so gut.

Denn einzelne Postleitzahlen-Gebiete sollten genau so wie Gemeindegrenz-Gebiete nur EIN EINZIGES mal in den OSM-Daten vorkommen.

Als einziges Unterscheidungskriterium muss dann die PLZ oder bei Gemeindegrenzen der amtliche Gemeindeschlüssel ausreichend sein.

(Es wäre mal interessant ob an eine maschinelle Auswertung aus einer OSM-Datenbank für Deutschland auf solche Doppelungen fahren könnte …)

Wenn du nun z.B. drei kleine Gemeinden mit deren Grenzen hast, die alle die gleiche Postleitzahl haben, dann sollte für das eine einzige PLZ-Gebiet eine extra Relation angelegt werden, welche nur die ÄUßEREN Grenzteile der Mitgliedsgemeinden enthält.

Im übrigen gehen doch die Verläufe aller PLZ-Gebiete (nach Ausgleich von Verschiebungen) aus dem
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 hervor … damit dürfte es leicht möglich sein, die PLZ-Grenzen zur Not neu anzulegen.

Kontrolle dann gut möglich über http://tools.geofabrik.de/osmi/debug.html?view=plz

stephan75 · 2011-10-31T16:25:04.000Z

eine weitere Prüfungsmöglichkeit für PLZ- bzw. Gemeindegrenzen bietet ja auch z.B. der http://www.openstreetbrowser.org

da mal die Kategorien “Orte” → “administrative Gebiete” oder auch “Mehr Kategorien” → postal_code areas auswählen …

Daran kann man sehen, dass auch der openstreetbrowser damit zurecht kommt, wenn man bei deckungsgleichen Grenzen für PLZ und Gemeinde dann auch nur eine einzige Relation verwendet.