ESRI-Shape-File: Typische Fehler im Handling

Wie stehst Du zum Shapefile? (Bildquellen: [6], [7])

Ja, trotz aller bekannten Mängel, dieses ESRI-Shape-File als Uralt-Geoformat [4] ist leider immer noch der “Quasi”-Standard beim Geodatenaustausch. Man kann sich die Zunge wund reden und ich habe auch genug drüber geschrieben ;-), Ihr findet es in [1] … [5]. Aber, wenn es nun mal so ist, die Anwender nutzen es und sie machen typische Fehler. Diese zu vermeiden, soll dieser Beitrag helfen. Er spiegelt unsere täglichen Erfahrungen an der GIS-Hotline wieder, ist aber sicher nicht vollständig, Ihr könnt gern in den Kommentaren, helfen, die Liste zu erweitern.

Was also ist zu beachten, wenn man Shape-Files nutzt?

  • Sind die minimalen Bestandteile (und damit Pflicht) vorhanden? *.shp, *.shx, *.dbf – alle mit gleichem Stammnamen?
  • Sind in den File- und Tabellespaltennamen keine Leer- und Sonderzeichen außer “_”?
    Auch “-” ist ungültig!
  • Ist die Codierung richtig? Können die Sachdateneinträge ordentlich gelesen werden (z. B. Umlaute, Sonderzeichen)? Am besten, alles immer einheitlich in UTF-8 umwandeln.
  • Ist die Projektion (EPSG) richtig? Ist ggf. die Anzahl der Stellen in den Koordinaten richtig? (Bsp. 4647 – 25832 – 35832). Wird auch die *.prj-Datei vom Ziel-GIS* richtig interpretiert, besser Ihr lasst Euch zusätzlich den EPSG-Code geben.
  • Ist die Objekt-Anzahl der Geometrie-Objekte und Einträge in Sachdatentabelle gleich?
  • Stehen ggf. Sonderzeichen bei langen Tabellenspalten am Ende (abgeschnitten bei 254)?
  • Ergibt die Geometrieprüfung im Ziel-GIS* mit Error-Count = 0?, falls nein: Repair-Funktion im Ziel-GIS* anwenden!
  • Beim Digitalisieren möglichst die “topologische Digitalisierung” aktivieren.
  • Manchmal hilft es auch, den Flächeninhalt von Polygonen zu bestimmen (im QGIS mit dem Feldrechner: $area). Flächen mit “NULL” oder “0” sind offensichtlich fehlerhaft (Geometrie oder Geometrietyp) oder inhaltlich unnötig, diese Datensätze sind zu löschen
  • Im QGIS/GRASS “v.clean” und ggf. “v.build” nutzen

    … hier folgen Eure Tipps …
  • Auf komplexe Geometrien achten. Kurvenzüge aller Art, Kreisbögen etc. werden beim speichern in einer Shapfile zu geraden Segmenten generalisiert.
  • Nur mit „ordentlichen“ GIS bearbeiten, auch wenn es ein „einfaches“ Format ist. Unmengen an Anwendungen sind der Meinung, Shapefiles schreiben zu können, gelegentlich mit eigenen „Geschmacksrichtungen“.
  • Flächeninhalte und Längen immer zusätzlich selbst berechnen (Buchwert Flächen natürlich nicht überschreiben…), dabei die Projektion beachten!
  • Beim Wechsel zwischen den GI-Systemen den räumlichen Index neu erzeugen.

* … z. B. QGIS!

[1] … https://geoobserver.de/2018/07/19/shapefile-die-neverending-story/
[2] … https://geoobserver.de/2017/10/26/shapefile-eine-hassliebe/
[3] … http://switchfromshapefile.org/
[3] … https://geoobserver.de/2016/03/29/theshapefilechallenge-the-winner-is/
[4] … https://geoobserver.de/2017/05/29/25-jahre-esri-shapefile-herzlichen-glueckwunsch/
[5] … https://geoobserver.de/2022/11/09/2022-und-immer-noch-das-shapefile/
[6] … https://twitter.com/shapefiIe/status/915656664421928960
[7] … https://twitter.com/ijturton/status/915582943883616256

2 Gedanken zu „ESRI-Shape-File: Typische Fehler im Handling

  1. Hier noch ein paar Tipps:
    Auf komplexe Geometrien achten. Kurvenzüge aller Art, Kreisbögen etc. werden beim speichern in einer Shapfile zu geraden Segmenten generalisiert.

    Nur mit “ordentlichen” GIS bearbeiten, auch wenn es ein “einfaches” Format ist. Unmengen an Anwendungen sind der Meinung Shapefiles zu schreiben. Alle mit ihrer eigenen “Geschmacksrichtungen”. Habe regelmäßig anfragen wegen negativen Flächeninhalten durch falsche Knotenreihenfolge bei einzelnen Flächen. Ich vermute irgendein R-Paket was gern in der Wissenschaft verwendet wird macht hier Mist. Siehe Tipp von Mike… Immer Geometrieprüfung anwenden.

    Flächeninhalte und Längen immer zusätzlich selbst berechnen (Buchwert Flächen natürlich nicht überschreiben…), es ist nicht klar in welchem Bezug eine “Area”, “Flaeche” oder wie auch immer sie heisst-Spalte berechnet wurde (Dokumentation, Metadaten habe ich so gut wie noch nie bekommen…) . Häufig machen Anfänger den Fehler, wenn eine Basemap im Spiel ist, ausversehen im Pseudomerkator die Fläche zu berechnen. Abweichungen sind im Bereich 20-30% und keine Kleinigkeit.

    Beim wechsel zwischen GIS den räumlichen Index neu erzeugen. Es können sonst Flächen fröhlich verschwinden oder auftauchen. Die sind ja nicht weg, aber führen zu einem Anruf was da los sei. Der Index ist nicht Teil der Spezifikation und damit softwarespezifisch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert