Boundaries Map 4.0-Beta Tester gesucht

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”

aber sicher, warte mal den nächsten Lauf ab.

was mag der nicht? hab es ja mit Josm erstellt.

EDIT ok, 2 punke lagen etwas zu nah beieinander; das wird es wohl gewesen sein.

Gruss
walter

Ach so. Ich sehe erst jetzt, dass Du die Wege nicht direkt aufeinander gelegt hast. So geht natürlich ein OSM-MP. Der “geometrischen Wirklichkeit” entspricht es nicht ganz.

EDIT: Ich kriege wegen der Rollen immer noch JOSM-Warnungen. Leider ist JOSM da unzuverlässig. Manchmal warnt es, manchmal nicht. Nachdem ich die Rollen lokal geändert hatte, hieß es dann das Untrasried-Polygon schneide sich.

Klar, aber irgendwann muß Schluß sein.

Gruss
walter

ps: Import der “neuen” Grenzen in den Tree läuft gerade, sollte in ca 1 Stunde fertig sein.

ist durch und sieh verd… gut aus :slight_smile:

Danke für das Hervorholen des anderen Threads, die Namen kamen mir doch bekannt vor …

Jetzt wird mir das (auch damalige) Problem klarer:
In OSM gibt es bei Polygonen keinen echten Flächentyp, sondern letztlich nur Ansammlungen von Linienzügen ohne Reihenfolge. Bei realen Flächen, die sich in einem Punkt berühren, führt das dazu, dass das abbildende Polygon auf mehrere Arten angeordnet (durchlaufen) werden kann: Zwei getrennte Kreise oder eine Acht.

Um diese Mehrdeutigkeit aufzulösen sehe ich im OSM-Geometriemodell nur die Möglichkeit, das in zwei Objekte aufzutrennen und dann in eine Superrelation einzufügen. Das ist aber sicher auch nicht ohne Nebenwirkungen, da viele Anwendungen nicht mit geschachtelten Relationen umgehen können.
Die andere (schon erwähnte) Möglichkeit ist die, die “Wirklichkeit” den Möglichkeiten des Datenmodells anzupassen, also winzige Trennungen einzubauen. Aber auch das führt zu Irritationen, wie man sieht.
Vielleicht sind die beiden Gemeinden ja bereit, den ca. 5 cm x 50 m breiten Streifen an OSM abzutreten, die darauf eine Gemeinde gründen, damit das Datenmodell wieder stimmt :wink:

Ein echter Flächentyp wäre ein geschlossenes Polygon mit erzwungener Reihenfolge (Ende des Vorgängers = Anfang des Nachfolgers).

LOL, und das als Ferien-Refugium für die von MultiPolygonen gestressten Mapper :wink:

Ich bin mir nicht sicher, ob die “saubere” Lösung ohne freischwebende Flächen überhaupt OGC-konform wäre. Dann lägen die Probleme garnicht bei OSM.

Aber was solls: ich bin müde zufrieden.

Gruss
walter

Doch, eine saubere Lösung ohne “freischwebende Flächen” wäre OGC-Konform, da diese Exklaven, von vorn herein als seperate Flächen betrachtet werden. Die Gemeindegrenzen sind schließlich nur eine Aggregation aus Ortsteilen/Gemarkungen und diese wiederum aus Flure und die aus Flurstücke. Wenn die Gemeinden eine Grenzrelation wären und die beiden Exklaven jeweils eine völlig eigene Grenzrelation wär, wäre es konform.

Sven

viel zu viele Wenns - es geht darum, ob ein Konstrukt, bestehend aus 2xOuter und 1xInner, die so wie an dieser Grenze miteinander verbunden sind, ein Polygon im OGC-Sinn darstellen. Also ob das eine legale Geometrie sein kann.

Ob es sich um Grenzen in der realen Welt, Farbflächen auf Papier oder gar um Bakterien in einer Petri-Schale handelt, ist dabei total unwichtig.

Gruß
walter