Boundaries Map 4.0-Beta Tester gesucht

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 :frowning:

Gruß
walter

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 :wink:

Gruss
walter

nachtrag: Ja, die Landmasse liegt mir auch immer noch quer.

Hi, die Version 0.9.7 ist fertig und live.

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 :wink:

Intensiv gesucht, leider kein Original gefunden. Hier http://forum.openstreetmap.org/viewtopic.php?pid=162283#p162283 gibt es einen Link auf Deinen Rechner, der funktioniert so auch nicht mehr, ist aber vielleicht ein Startpunkt?

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

HTH und Danke.
Michael

Warum änderst du laufend den Threadtitel? Ich finde das eher verwirrend …

Gruß Klaus

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.

Gruss
walter

Bei einem meiner beiden anderen Projekte (PLZ/Residentials) wurde ich sogar dafür gelobt. Kann nur den Beitrag dafür nicht finden.

Gruss
walter

Der hier? http://forum.openstreetmap.org/viewtopic.php?pid=352101#p352101

jo, genau den - daß der aber schon so alt ist, hätte ich nicht gedacht.

Gruss
walter

edit: typo

Hi,

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.

Gruß
walter

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

hajo, in schwaben sieht es wirklich schlimm aus.
Ich überprüf das nachher mal.

Gruss
walter

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.

Defekt sind die Grenzen in dem Sinne, dass sie nicht dem OSM-MP-Standard entsprechen und osm2pgsql sie verwirft.

Das sage ich ja die ganze Zeit! Vgl. auch http://forum.openstreetmap.org/viewtopic.php?id=23172
Höre ich jemanden “OGC” flüstern? :wink:

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.

Sven

Wenn ich das richtig verstehe, plädierst Du damit für Grenzrelationen mit Parts statt Linienelementen?
Bitte diskutiert das doch hier weiter.

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?

Gruß
walter

EDIT: Hat wohl hingehauen :slight_smile:

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

EDIT: Kommentar zu role “outer”