Danke für den Versuch! Ich weiß allerdings nicht, was Du alles ausprobiert hast - die Grenzen der Woiwodschaften sehen noch richtig aus, aber ich hab jetzt z.Bsp. mal innerhalb der Woiwodschaft Dolnoslaskie (Niederschlesien) noch die Ebene 6 (Powiaty) ausgewählt und mir als shp exportieren lassen. Da wird mir in QGIS nur eine zusätzliche Grenze innerhalb der Woiwodschaft angezeigt, die anderen fehlen. Ähnliches passiert, wenn ich z.Bsp. nur einige Gminy (Gemeinden, Ebene 7) auswähle. Schätze, das ist mein altes Problem mit der polnischen Karte?
Ich “probiere” da nichts aus, ich nehme die Daten so wie sie sind. Dabei interpretiere ich keinerlei irgendwie händisch eingetragenen Informationen wie “das ist die Sub-Area von der Master-Area”, sondern benutze dafür Spatiale Abfragen. “In welchen Grenzen liegt ein bestimmtes Gebiet?” - also allein die Geometrie der Objekte.
Dauert etwas (ca 20 Minuten für die 6699 Administrativen Grenzen Polens), sollte aber 100% sicher sein.
insert into boundaries
select -osm_id osm_id,'PL','admin',name,admin_level,wno_FindPath(-osm_id,1),st_multi(way),st_pointonsurface(way)
from planet_osm_polygon
where boundary = 'administrative'
and admin_level in ('2','3','4','5','6','7','8','9','10','11','12')
and osm_id < 0
and st_contains((select way from planet_osm_polygon where osm_id=-:country),pointonsurface)
;
und der Kern von wno_FindPath:
temp = (select array_agg("outer") from (
select o.admin_level,-o.osm_id "outer",-i.osm_id "inner"
from planet_osm_polygon o,
planet_osm_polygon i
where st_contains(o.way,i.pointonsurface)
and i.boundary='administrative'
and o.boundary='administrative'
and i.osm_id < 0
and o.osm_id < 0
and i.osm_id = -boundary_id
and o.admin_level::float <= al -- wegen 4x al 9.5 in Ungarn!!!
order by wno_number(o.admin_level)
) foo
right outer join generate_series(2,11) gal
on (foo.admin_level::int = gal)
);
Sorry, für den GIS-Laien wohl etwas undeutlich (und für einen richtigen GIS-Profi eventuell zu umständlich?) aber ich glaube, meine “Denke” sollte rüberkommen.
eventuell muß ich meiner vorigen Antwort widersprechen
Wenn die im Tree ausgewählten “gewünschten” Grenzen in der Karte angezeigt werden, sollten sie auch im Export drin sein - ich check das mal nach.
Gruss
walter
Zwischenergebnis: 30 Grenzen (1x al4, 29x al6) sind in dem Shapefile drin - angezeigt werden in QGIS aber nur 2
Grübel Grübel
ausgegrübelt: Mach den Fill-Modus aus, dann sind alle da. In der Attribut-Tabelle sieht man, dass al4 an Position 29 und das einzige angezeigte Gebiet an Pos 30 steht. Damit werden die ersten 28 überdeckt.
Hi, habe gerade mal beim Shape-Export die Namen der Files von Zufallszahlen auf Timestamp geändert. Da kann man wohl besser den Überblick behalten.
Wenn irgendwer 'ne bessere Idee hat, 4 Files mit x Shapes in einen Download zu packen, gerne her damit.
Das Teil ist immer noch Beta und manche Sachen sollten wohl besser sein.
die Export der POLY-Files steht ab sofort zur Verfügung. Als nächstes kommen die Buffered Poly-Files dran, mit denen das Clipping wohl schneller und besser möglich sein sollte.
So OT fand ich es nicht, da es mir (erst) beim betrachten des Admin-Level-Baumes auffiel. Da die Relation kein gültiges Admin-Level abbildet, fällt die für mich in die Kategorie Sammelrelation.
Ich würde die Relation köschen, was passiert mit dem Admin-Level-Baum in der Boundary-Anwendung??
gerade mal geprüft:
BB-S-SW ist (natürlich) noch im Tree, seine “Kinder” auch. Man kann alles mit machen (auch Kinder auswählen), aber das Gebiet wird nicht mehr in der Karte angezeigt. Und beim Export fehlt es einfach.
Toll, hab ich mir dem Teil eigentlich nicht zugetraut
Nachher baue ich den Baum mal neu auf und dann sollten die Kinder einfach eine Ebene hochrutschen.
Gruss
walter
ps: eventuell sollte ich eine Message einbauen “Rel nicht gefunden” oder so. Mal sehen.
Ja, es gibt solche (sorry) kruden Programme… Stichwort Mircrostation. Mit solchen Daten hab ich hin und wieder dienstlich zu tun.
aber
-∞
Das würde eine vollständige Umprojektion der Daten bedeuten (Datumsübergang). Bei Gauß-Krüger liegt as Bessel-Ellipsoid zu Grunde, also eine andere geographische Basis als OSM (=WGS84). Also physisches Umrechnung der Koordinaten. Das ist dann doch sicher schon etwas Rechenaufwand. …und wenn es nicht ontheFly ist, hat man trotzdem den Rechenenaufwand und hieße einen seperaten Datensatz bereithalten.
Na und andererseits muß man doch die Menschheit irgendwie von veralteten Gauß-Krüger abbringen. Ja und wenn sie es nicht lassen können, sollen sie die Daten selbst umrechnen.
Sorry, klingt zwar etwas hart, ist aber meine feste Meinung.
Hallo Walter,
konkretes Beispiel, an dem ich arbeite: Kartieren von Telekommunikations-Infrastrukturen (z.B. TELEKOM-KVz und Glasfaser-Trassen) im Kontext von Verwaltungs- bzw. politischen Grenzen, d.h. Potentiale für Gemeinden. Ebenso Findung von optimalen Trassen (parallel Straßen, Radwege etc.) zur Optimierung der Breitband-Infrastruktur, insbesondere im ländlichen Raum.
Und Gauß-Krüger: Das ist aktuell die Datenbasis der Vermessung und kommunaler Verwaltungen, ich kann’s mögen oder auch nicht: Tatsache ist das!
Danke.
Michael
Hm… Brandeburg hat 1996 ETRS (!!!) , seit 2012 AAA, Sachsen läuft die Umstellung, Rheinland-Pfalz dürfte Umgestellt sein, Thüringen auch, Niedersachsen auch… um nur einige zu nennen… Die AAA-Umstellung, also die Umstellung auf ETRS89 mit seinem zum WGS84 kompaktiblen geodätischen Referenzsystem GRS80 ist voll im Gange. Arbeitskraft in Gauß-Krüger sollte man da nicht mehr stecken.
Es werden immer weninger Amtliche Daten kommunaler Verwaltungen in Gauß-Krüger-Daten… zum Glück.
Aber ja, ich bekomme auch noch zur Genüge Gauß-Krüger-Daten, ich kovertiere sie mir aber vorher.
Naja ich will mal so sagen bevor irgend eine Straße neu-, aus- oder umgebaut wird, werden in Deutschland Planungen und Trassierungen gemacht. Das geschieht üblicherweise in CAD. Daher sind Grenzen dort wahrscheinlich auch nicht zu vernachlässigen.
Ja, ich weiß. Auch für AutoCad gibt es ähliche Programmerweiterungen (Landcad).
Gegen eine mögliche CAD-verarbeitende Schnittstelle (dxf?) hab ich auch nichts. Ich sehe nur keine Notwendigkeit, Arbeitskraft in Gauss-Krüger zu stecken.