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
Ein echter Flächentyp wäre ein geschlossenes Polygon mit erzwungener Reihenfolge (Ende des Vorgängers = Anfang des Nachfolgers).
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.
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.
Ich könne das mal so bauen, wie ich es meine, würde es aber nicht hochladen wollen…
Ich meine, die beiden betreffenden Exklaven brauchen nur als eigene separate Grenzrelation erstellt zu werden und nicht als Teil (zweites outer) der zugehörigen Relation. Dann ist es fehlerfrei, und meiner Ansicht nach auch OGC-Konform und auch von den Geometrien in OSM sauber.
Es scheint einen kleinen fehler in den Shapes zu geben. Dort wird fälschlicherweise die Codepage DOS/OS2-850/International
Damit werden aber Umlaute nicht korrekt interpretiert. Müsste das vielleicht eine UTF-8 Codepage werden? jedenfalls sieht es in libreoffice damit dann schön aus.
Ich glaube, ich hab gar keine Codepage angegeben; ich werfe die Relationen einfach pgsql2shp zum “Fraß vor”, und jage das Ergebnis raus.
Aber ich schau mir das mal an.
erster Eindruck: Ich mach wirklich nix, da es keine Option dafür zu geben scheint. → todo
Also libre Office ist nicht das Problem! Das fragt vorher nach wie es das interpretieren soll.
Allerdings läuft das nicht unter PTV Visum. Dort werden die Namen verunstaltet.
Das kann man zwar über Umwege auch lösen, aber von der hotline habe ich die Antwort bekommen, dass es sich um einen Fehler in den shpfiles handelt.
Ich kann theoretisch auch Qgis benutzen. Die Arbeiten werden unter Windows7 ausgeführt.
wie jede vernünftige Software, die auf mehreren Plattformen arbeiten kann bzw. Daten davon bekommt.
Klaro, alles was deren Software nicht verarbeiten kann, muß falsch sein! Dabei definiert ESRI, was richtig ist und nicht dieser Saft-Laden ;(
Daß die mit Umlauten perfekt umgehen können, sieht man ja hier:
Wenn du Qgis installiert haben solltest, probier es doch bitte mal unter Win7 aus. “mein” Qgis unter Ubuntu bietet geschätzte 50 Encodings an, wenn man ein Shape einlesen will.
Rennt das Zeug eigentlich nur unter Windows? Konnte nirgenswo die Anforderungen der Software finden, sonst würde ich mir ne 30-Tage-Version besorgen.Klaro, nur Windows
ansonsten schick mir mal ein “PTV-kompatibles” Shape rüber: walter punkt nordmann at web punkt de
Gruss
walter
Noch zur Klarstellung: Ich bin nicht DER Experte für Shapes, aber irgendwie kriegen wir die Kuh schon vom Eis.
Also mir ist bisher keine Version unter Linux bekannt. Daher gehe ich davon aus das nur Windows möglich ist.
Die Testversionen sind schwierig. Denn dort kann man nicht mehr speichern. Außerdem ist nach einer bestimmten Zeit schluss mit Arbeiten. Ich glaube so nach 60 Minuten.
Aber der importer für OSM Daten ist sehr gut geworden. Sogar Multipolygone schafft er. Allerdings ist die Konfiguration alles andere als einfach, weshalb mir die Shapfiles gerade recht kamen.
Das Problem mit den Umlauten ist so eine Sache. Vorallem in den Skripten. Ich habe so eine Schnittstelle auch bereits angepasst und UTF-8 fähig gemacht. Aber im Prinzip sind Sonderzeichen ins Strings kein Problem.
Nur das einlesen macht eigentlich das Problem.
Mail ist raus.
hab ihn mal unter xp installiert, damit ich an die Doku rankomme. PTV verweist auf die Beschreibung von Esri, in der nichts über Codepages steht. Esri verweist auf www.inprise.con (Nachfolger von Borland), aber der Server ist tot → Dead End
Da sich “dein” Software-Lieferant aber wohl auf den ‘Standard’ beruft “DBase war immer Windows und daher können wir nur Windows-Codes”, ist ist bei denen wohl nix zu machen. Könntest denen ja mal den “State of the Art” zukommen lassen.
Ich könnte das ja generell auf die Windows Codepage ändern aber irgendwie mag ich das noch nicht.
ich glaube, da werde ich mich wohl daran halten
Gruss
walter
edit: Ziel noch unklar; bin mit viw dran, die Sache endgültig zu klären.
ich habe heute die Release 1.0 freigeschaltet. Damit ist die Betatest-Phase wohl vorbei.
Highlight: Suchfeld für Grenzen. Einfach den Namen oder einen Teil des Namens mit Wildcards (%) eingeben. Bei mehr als einem Treffer kommt ein Popup zum Auswählen.
I was curious if I could assist in expanding the tool’s library to include a larger number of national boundaries. Was hoping to grab shapefiles of the OSM country boundaries in East Asia in order to conduct a project detailing the territorial waters and EEZs of various nations in the South China Sea.
at the moment i’m not planning to extend the list of supported countries exept some in europe around germany. The tree on the left site would get to complex, there is no mechanism so search only one country, long update-times (the update of 6 countries needs about 90 minutes at night)
BUT: If you tell me the names and relation-ids, i can create the shapes easily and you can download them.
Regards
walter
@alle: ich glaube, ich hab mal wieder was zum Basteln. Step1: alle al2? was meint ihr?
funktioniert die seite nicht mehr? ich kann nur bei luxemburg und switzerland die ordner aufklappen. bei deutschland lädt er kurz lässt den ordner ab zu.
jub, danke. da wäre noch eine sache, gibt es eine möglichkeit sich zusammengestellte grenzen als .svg vektorgrafikformat zu exportieren? wollte damit weiterarbeiten (in Inkscape) und für wikipedia Karten für die alten preußischen Kreise zu machen. hatte das hier https://de.wikipedia.org/wiki/Kreis_Diepholz schonmal gemacht, aber mit einem screenshot der grenzen, und deswegen ziemlich unsauber, und nochmal abpauschen der grenzen wollte ich nicht.
