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)
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.
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.
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
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
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.
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
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.
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.
“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:
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.
