Qgis Katasterdaten Format?

[RIDGiD]

Hallo erstmal der Forumsgemeinde, ich bin ganz neu hier.



Ich nutze ein L1 Rtk System auf Rtklibbasis, welches ich gerne für Livetraking auf Liegenschaftkatasterkarten nutzen würde.

Hierzu würde ich bei der Software gerne auch auf Windows setzen da ja auch Rtklib/Navi hier sein zuhause hat.

Nun gibt es hier ja mit Qgis ein sehr sehr vielseitiges und ausführliches Programm auf Windowsbasis das diese Funktionen ja beinhaltet und dazu noch als Freeware verfügbar ist.


Nun auch gleich zu den Fragen.

Ich möchte es wenn möglich nicht unnötig verkomplizieren, gibt es einfachere Alternativen als qgis?

und welche Format der Katasterdaten sind am besten für Qgis + event alternativen bereitzustellen?

Es soll nur eine Gemarkung ca. 600ha mit dessen Flurstücksgrenzen dargestellt werden, welches Format ist am einfachsten zu georeferenzieren?

Kartenmaterial dürften wir für einen vernünftigen Preis bekommen von der LGL in Baden Würtemberg, da wir als aktiver Landwirtschaftlicher Betrieb tätig sind. Nur sollte ich wissen was am besten geeignet ist

Hat jemand Erfahrungen mit Qgis und Liegenschaftkatasterdaten?

Die Gis Daten aus dem Gemeinsamen Antrag hier in BW (Fiona Gis) lassen sich die sich nutzen in irgendeiner Form? Mir ist zu Ohren gekommen das die Exportfunktion Shape Dateien ja ausgibt. Das sind dann aber nur Schlaggrenzen oder

Über ein paar Infos und Anregungen würde ich mich sehr Freuen

Grüße

[spunky]

Katasterdaten gibt es in vielen Bundesländer kostenlos, suche mal nach "WMS" und "Flurstücke" (oder "Kataster") und dein Bundesland. Das kannst du dann in QGIS als Layer hinzufügen. Manche Bundesländer bieten die Flurstücke getrennt als Gemarkung auch als Shape zum Download an.

[RIDGiD]

Ja ich hatte vor einiger Zeit schon mit der LGL und dem Katsteramt des Landkreises telefoniert, hier war dann aber nie die Rede von kostenfreien Daten des Liegenschaftkataster für jedermann. Aber ich werde mich hier nochmal schlau machen wie in BW die Daten gehandelt werden.

Das exportieren der Feldgrenzen aus dem Antragsprogramm des (Fiana Gis) in Qgis funktioniert dagegen echt einfach.

Danke Spunki für die Info

[RIDGiD]

Was das Liegenschaftskataster in Baden Württemberg angeht können Mitglieder des Deutschen Bauernverbandes diese mit dem (Rahmenvertrag Landwirtschaft) deutlich günstiger von der LGL beziehen.
In meinem Fall wurde mir empfohlen nur Landwirtschaftliche Nutzfläche zu beziehen, da sich der Preis aus Fläche und Parzellen ermittelt.
Durch den Rahmenvertag kostet der Bezug knapp ein Viertel des regulären Preises, 2,3Km³ mit 1250 Parzellen etwa 350€ also mit Rahmenvertag Landwirtschaft.

Nur das bestellen und das auswählen des Kartenausschnittes könnte einfacher funktionieren...die online Auswahl und Bestellung ist derzeit außer Betrieb

Nun hätte ich noch eine Verständnisfrage zum Koordinatensytem.
Importiert habe ich die Daten der Schlagumrisse aus dem online Antragssystem im Shapeformat als WGS 84. Qgis zeigt mir diese nun bei Layer Info Koordinatenbezugsystem als (EPSG:4326, WGS84) an soweit sogut.

Unter Projekteigenschaften/ Koordinatensystem im Qgis Projekt habe ich WGS 84 / Pseudo Merator ausgewählt.

Damit scheint alles schön zu passen auch der Google Earth Layer.

Stelle ich aber beide KBS (Koordinatenbezugsysteme) auf das selbe KBS mit der selben Epsg Nummer das dann verzerrt es mir alles? Was ist hier die richtige Einstellung?

oder passt das einfach so? Im Feld lagen die Grenzpunkte auch am rechten Fleck Basis ist auch genau eingemessen via N-trip

Bild Schlaggrenzen Qgis Export Fiona Layer + Google Earth Layer

Qgis bild.jpeg (198.38 KiB) 5673-mal betrachtet

[spunky]

ja, du musst die verschiedenen KBS verwenden, da die Layer auch mit verschiedenen KBS erzeugt wurden. Man kann die auch irgendwie konvertieren, hab ich jetzt aber keinen Plan wie das geht...

Die 2,3km² bekommst du vergünstigt für 350€, das würde sonst 1400€ kosten? Da fehlen mir die Worte...

[RIDGiD]

Ja genau aber die 350€ sind in Ordnung. Was ich nicht ganz verstehe bei dem Vertag sind auch kostenpflichtige Updates in den 2 Folgejahren enthalten, dabei würde mir der einmalige Bezug ja ausreichen... ich warte noch auf Antwort

In einigen Bundesländern stehen die Liegenschaftskatasterdaten kostenfrei zur Verfügung,
da würde ich nicht mehrere tausend Euro hinlegen. Ich brauche sie auch nicht zwingend aber es ist eine schöne Ergänzung beim live tracking mit Qgis, gerade im Realteilungsgebiet. Oder falls der Nachbar auch ein paar Grenzen nachschauen möchte.

[123-flip]

Ich vermute, dass es sich bei den aus FIONA als WGS84 exportierten Daten in Wirklichkeit um Daten im ETRS89 Format handelt.
Wenn ich nämlich die Daten aus FIONA als GK3 exportiere und dann mittels Ntv2 Verschiebegitter in ETRS89 konvertiere, dann erhalte ich die gleichen Koordinaten wie aus dem Export von WGS84.

Hintergrund: WGS84 und ETRS89 liegen derzeit rund 60cm auseinander.

Nun stellt sich für dich die Frage, wie deine Station eingemessen wurde? SAPOS liefert beispielsweise ETRS89 Daten.

[Hagen.Felix]

Importiert habe ich die Daten der Schlagumrisse aus dem online Antragssystem im Shapeformat als WGS 84. Qgis zeigt mir diese nun bei Layer Info Koordinatenbezugsystem als (EPSG:4326, WGS84) an soweit sogut.

Dann sollte doch eigentlich eine gleichnamige *.prj-Datei mit ausgegeben worden sein, oder?

Und jene sollte doch eigentlich jedes Rätselraten bzgl. Lagebezug zuverlässig verhindern ...

Sollte allerdings FIONA eine *.prj-Datei für EPSG:4326 (http://spatialreference.org/ref/epsg/wgs-84/) erzeugen, obwohl die Daten tatsächlich in ETRS89 (http://www.spatialreference.org/ref/epsg/4258/) gelagert sind, ohne zuvor noch eine Transformation von ETRS89 nach WGS84 durchzuführen, wäre es geradezu skandalös.

Das dürfte daher vielleicht doch nicht allzu wahrscheinlich sein, oder?

Wenn ich nämlich die Daten aus FIONA als GK3 exportiere und dann mittels Ntv2 Verschiebegitter in ETRS89 konvertiere, dann erhalte ich die gleichen Koordinaten wie aus dem Export von WGS84.

Allerdings, hier liegt offenbar schon ein recht krasser Verdacht im Raum ...

Unabhängig von diesem konkreten Fall ist das von 123-flip genannte Problem aber leider allgegenwärtig.

Es gibt erschreckend viele Nutzer von Geodaten (leider auch in beruflichen Kontexten), die wie selbstverständlich davon ausgehen, dass geografische Koordinaten (also Wertepaare von Längen- und Breitengrad) sozusagen auf jeden Fall WGS84 sein müssen ...

[123-flip]

Ich habe heute nochmal ein bisschen gespielt und konnte meine Vermutung nur nochmal bestätigen.

Hier mal eine Beispielkoordinate:

Code: Alles auswählen

Ursprung Fiona GK3:
Y Rechtswert 3604749.30004
X Hochwert   5412124.26994

Breite       Länge
48.83774014° 10.42591583° (Koordinate in Fiona Export WGS84)
48.83774014° 10.42591583° (Geodatenzentrum GK3 nach GEO_ETRS89 mit Beta2007)
48.83774014° 10.42591583° (Geodatenzentrum GK3 nach GEO_WGS84 mit Beta2007)
48.83774014° 10.42591583° (QGIS Fiona GK3 mit ntv2_Beta2007 nach ETRS89)
48.83774014° 10.42591544° (SAPOS Bayern: Koordinate erkannt als GK3 (EPSG 5677) nach Zielsystem  ETRS89 (EPSG 6258) mit ntv2_Bayern2011)
48.83774004° 10.42591546° (SAPOS Bayern: Koordinate erkannt als GK3 (EPSG 5677) nach Zielsystem  ETRS89 (EPSG 6258) mit ntv2_Bayern2004)


Witzigerweise ist auch beim Geodatenzentrum (http://sgs.geodatenzentrum.de/coordtrans/) WGS84 gleich mit ETRS89...

[Hagen.Felix]

... SAPOS Bayern: Koordinate erkannt als GK3 (EPSG 5677) nach Zielsystem ETRS89 (EPSG 6258) ...

Bin gerade etwas irritiert.

Ist DHDN/GK3 nicht EPSG:31467 (http://www.spatialreference.org/ref/epsg/31467/)?

Und GEO_ETRS89 nicht EPSG:4258 (http://www.spatialreference.org/ref/epsg/4258/)?

[123-flip]

Im Rechner von SAPOS Bayern wird wohl das Ursprungssystem automatisch anhand der eingegebenen Daten ermittelt.

Als Zielsysteme können eingegeben werden:
Geodätisches Datum:
ETRS89 (EPSG 6258)
DHDN90 (EPSG 6314)

Koordinatensystem:
UTM32 (EPSG 4647)
UTM33 (EPSG 5650)
GK9 (EPSG 5677)
GK12 (EPSG 5678)
Geographisch B,L [°]

Höhensystem:
Ell. Höhe (EPSG 4937)
DHHN12 (NN, EPSG 5784)
DHHN92 (NHN, EPSG 5783)

Unterschiedliche EPSG Codes gibt es wohl auch dann, wenn Längengrad und Breitengrad in der Datei in umgekehrter Reihenfolge sind.

Ich habe heute einige verschollene Grenzsteine auf württembergischen Grund zusammen mit meiner von SAPOS Bayern in ETRS89 eingemessenen Basis gefunden. Ich nehme also definitv an, dass die von FIONA als WGS84 gelieferten Daten in Wirklichkeit ETRS89 sind.

[cr2_gps]

Es gibt erschreckend viele Nutzer von Geodaten (leider auch in beruflichen Kontexten), die wie selbstverständlich davon ausgehen, dass geografische Koordinaten (also Wertepaare von Längen- und Breitengrad) sozusagen auf jeden Fall WGS84 sein müssen ...

WGS84 ist reiner Papiertiger, es kann gar keine "WGS84 geodätischen Daten" geben ...
Gemessen wird in ITRF(t) und eine mathematische Transformation (14 Parameter) ist nur für ITRF* <-> ETRF* definiert.

[RIDGiD]

Danke für die Antworten, zu den Bezugssystemen! Es ist für einen Anfänger doch recht schwer den Durchblick zu waren.

Nun stellt sich für dich die Frage, wie deine Station eingemessen wurde? SAPOS liefert beispielsweise ETRS89 Daten.

Mir war neu dass es beim einmessen der Basis auch auf das Bezugsystem ankommt, klingt aber einleuchtend

Ein-gemessen wurde wurde mit freiem IGS-IP Ntrip Broadcaster
Station war Karlsruhe. Basisline war etwas lang 60km auf guten Tag und Fix gewartet.

Im Feldeinsatz sah das ganze mit der Istposition gar nicht so schlecht aus, wenn ich das Liegenschaftskataster vorliegen hab dann kann ich mal ein paar frisch vermarkte Grenzpunkte nachmessen.

Hier dürfte ich ja dann schnell feststellen ob sich irgendwo ein Fehler eingeschlichen hat.

[123-flip]

Eine ganz nette Erklärung gibt es auch hier: http://www.sapos-bw.de/bezugssysteme.php

Die Stationen von IGS-IP haben wohl ITRF2008 als Referenzrahmen, wenn ich das richtig gegoogled habe.

Ich verwende derzeit eine Einfrequenzbasis. Zum Auffinden von Grenzsteinen per Einfrequenz-RTK mit Koordinaten aus dem Katasteramt (ETRS89), haben sich hier die mit SAPOS eingemessenen Stationsdaten bewährt.

Verwende ich die Koordinaten aus dem Katasteramt (ETRS89) direkt auf einem Lenksystem (John Deere Starfire 6000 mit SF1 ohne RTK), dann liegen die Grenzpunkte meist einiges daneben. Nachdem ich die Daten aus dem Katasteramt noch zusätzlich in ein ITRF transformiert habe, waren die Abweichungen auf dem Lenksystem (im Rahmen der Ungenauigkeiten eines Zweifrequenzempfängers ohne RTK) um einiges geringer.

@cr2gps:
Korrigiere mich bitte, wenn ich bei den Begrifflichkeiten etwas durcheinander bringe.
Sehe ich das richtig, dass sich bei den IGS-IP Stationen in Europa über die Zeit die Koordinaten ändern müssen, da sich die Stationen auf der eurasischen Platte befinden, welches sich im Referenzrahmen ITRF aber bewegt?

[Hagen.Felix]

... Koordinaten aus dem Katasteramt (ETRS89) direkt auf einem Lenksystem (John Deere Starfire 6000) ohne RTK, dann liegen die Grenzpunkte meist einiges daneben. Nachdem ich die Daten aus dem Katasteramt noch zusätzlich in ein ITRF transformiert habe, waren die Abweichungen auf dem Lenksystem (im Rahmen der Ungenauigkeiten eines Zweifrequenzempfängers ohne RTK) um einiges geringer.

Wenn die grün-gelbe Murmel mit dem Starfire-SBAS (kostenpflichtiges Abo) läuft, ist deren Positionierung ja auch im ITRF gelagert.

Bin kein JD-Fachmann, würde aber vermuten, dass man in den SF-Geräten (deren eigentlicher Hersteller ja die seinerzeit komplett vom Hirsch gefressene Firma NavCom ist) vielleicht auch gleich eine On-the-Fly-Transformation zum ETRF einstellen kann.

Bei anderen High-End-Herstellern wie z.B. NovAtel sind solche Firmware-Optionen jedenfalls nicht unüblich.

Siehe z.B. unter http://www.novatel.com/support/known-so ... ormations/ ...