Klaro, wenn sich die Basisdaten ändern, schlägt das natürlich auch in die DB durch. Aber halt nur dann und nicht, wenn jemand bei OSM die Grenzrelation neu aufbaut. Das sind aber langfristig geplante und bekanntgegebene Strukturänderungen, die der Auswerter für “seinen Bereich” wohl kennen muß.
Ich warte schon auf den Tag, wo jemand 51477 (Deutschland) durch eine neue “bereinigte” Version ersetzt - dann fliegen mir nämlich einige Auswertungen um die Ohren
Ich baue mir DE meist aus seinen Teilen selbst zusammen (bzw. PostGIS macht das für mich). Ein Grund ist auch, dass die DE-(Festland-)Grenzen sonst teils nicht mit denen der Küsten-Gemeinden übereinanderliegen
geht bei mir nicht: ich hab meistens Abfragen in der DB der Art: “suche alle Nodes/Ways/Relations, die in Deutschland liegen” und betrachte diese dann näher. Eigentlich müsste ich das so machen:
suche die Relation für Deutschland (boundary=‘administrative’, admin_layer=‘2’, name = ‘Deutschland’)
verwende die gefundene osm_id für weitere Auswertungen.
Aber ich drücke mich immer davor
Gruss
walter
nachtrag: Ja, die Landmasse liegt mir auch immer noch quer.
Highlight: Automatischer Zoom auf die ausgewählten Boundaries
Ich habe ziemlich drastische interne Änderungen machen müssen, da die ganze Fensterverwaltung noch ein wenig gesponnen hat.
Wenn also was nicht mehr so laufen sollte wie vorher, meldet euch bitte.
Gruss
walter
@thomas: Danke für deinen “kleinen Verbesserungsvorschlag”, dessen Realisierung mir 3 nette und spannende Tage mit Javascript im IFrames-Umfeld gebracht hat
Dann habe ich noch eine wohl von mir modifizierte .POLY-Datei zum LK Landshut, die schaut so aus:
62657 version=44 tstamp=“2011-03-05 08:33:22” admin_level=6 name=“Landkreis Landshut” note=“” ags=09274
1
12.375472 48.344337
12.374775 48.34431
dann 7.295 Koordinatenpaare und danach
END
END
ja, das ist doch genau das POLY-Format, dass ich immer schon ausliefere. Zeile 1 ist eh nur ein Kommentar; da ist es völlig egal, was drinsteht. Wenn du damit klar kommst, wäre doch alles in Butter. Die Beschreibung gibt es hier: https://wiki.openstreetmap.org/wiki/DE:Osmosis/Polygon_Filter_File_Format
Ich kann mich ehrlich gesagt auch garnicht daran erinnern, irgend was spezielles jemals gemacht zu haben. Waren immer nur Poly-Files und Shapes.
Der Rechner ist übrigens lange tot und die damaligen Daten auch. können aber nur shapes oder poly-files gewesen sein.
der Export der Buffered Poly-Files ist (wohl) fertig.
Ab sofort können unten links im Format-Menu auch bpoly-Files ausgewählt werden. Diese habe 2 Vorteile:
Sie haben wesentlich weniger Nodes als das Original (maximal etwa 1000 war mein Ziel) und somit ca 10% der Größe der Full-Poly-Files.
Dies beschleunigt das Clippen mit Osmosis oder OSMConvert erheblich.
Ihre geometrische Ausdehnung ist etwas größer als das Grenzpolygon.
Damit wird erreicht, daß auch wirklich alles incl. der Grenzpunkte selber, im Ergebnis enthalten ist.
Ich habe die bpoly-Files daraufhin überprüft und keine Ausreißer gefunden.
Danke. Die Shapes sind jetzt so wie gewünscht und lassen sich schnell zum Filtern benutzen. Außerdem lassen sich leicht die Einwohner über die GSN zu ordnen. Danke auch für diesen Tip.
Wenn ich mich nicht verguckt habe, fehlen die Landkreise Oberallgäu und Ostallgäu im bayr. Schwaben. Deren Geometrie ist wohl auch (schon lange) defekt (siehe Untrasried, Wildpoldsried).
Die Grenze OA/OAL ist nicht defekt, die Geometrie ist nur sehr speziell.
Einmal berührt eine Exklave nur in einem Punkt, das wird von OSMI bemängelt. Aber das ist nun mal so. Man kann die Eckpunkte um ein paar Millimeter auseinanderziehen, dann meckert OSMI nicht mehr. Das widerstrebt mir aber, dann das ist lupenreines Taggen für den Inspektor.
Etwas weiter östlich ist es noch etwas komplizierter: Zwei Exklaven berühren das “Mutterland” jeweils an zwei Punkten, dazu grenzen sie auch noch genau aneinander (System Schachbrett).
Wenn das Geometriemodell die Wirklichkeit nicht abbilden kann, stellt sich für mich die Frage, was von beidem eigentlich angepasst werden müsste.
Je mehr ich überlege, desto eher komme ich zum Ergebnis, daß die beiden Exklaven als separate Objekte (eigene Grenzrelation mit eigenen Tags) behandelt werden müssen. Ich vermute, seitens der amtlichen Grenzen (ALK/ATKIS/Flurkarte; je nach dem) sind die entsprechenden Exklaven mit einer eigenen Gemarkungsnummer und Flurnummer sowie einer Eigenschaft “Exklave” gekennzeichnet.
Erst über den Gemeindeschlüssel entsteht der Zusammenhang.
ein fiktives Beispiel (die Zahlen stimmen nicht):
Wildpoldsried hat den Gemarkungsschlüssel “1111”
Exklave Wildpoldsried hat den Gemarkungsschlüssel “1112” und die Eigenschaft Exklave=ja
Wildpoldsried und Exklave Wildpolsried haben gemeinsam den Gemeindeschlüssel “199999”
Ich denke so könnte man das sauber abbilden. Ein Blick in die ALK-Richtlinie könnte da aber sicher nicht schaden.
Diese Stelle ist OGC-Konform, genau so wie das Dreieck um Jungholz im Süden von Schwaben. Das wird von osm2pgsql in 2 Polygone umgewandelt, von denen ein Punkt des kleinen Ringes den anderen Ring an genau einer Stelle berüht.
Genau da liegt der Hase im Pfeffer. Osm2pgsql kommt da garnicht mir klar und schmeisst daher die beiden großen Outer der Kreise Oberallgäu und Ostallgäu weg.
Ob dieses Konstruk OGC-konform wäre, wage ich zu bezweifeln, bin mir aber nicht 100% sicher. Klar ist, daß osm2pgsql mit den beiden ein riesiges Problem hat.
ich hätt da ne Idee, das zu umgehen. Soll ich mal?
Habs mir in JOSM angeschaut. Funktioniert wohl. Ist es auch OSM-MP-konform? Sieht nicht danach aus. JOSM mag’s auch nicht. Wäre mir aber egal…
Aber: Warum haben die auszuschließenden Flächen die rolle “outer”, nicht “inner”? Ist das falsch oder gar Teil des “Hacks”?
Ich glaube PostGIS ist beim Polygonbauen die Rolle eh schnuppe. Ist es Innen, kommt es raus (Even-Odd-Regel).