Ich habe einen meiner GIS-Techniker, der einige Zeilen in QGIS im Shapefile-Format digitalisiert. Ich weiß nicht, wie er es gemacht hat (und er auch nicht), aber irgendwie wurde das Shapefile korrupt. Es wurden zufällige Linien erzeugt, oder einige der Linien, die er erstellt hatte, verschwanden einfach. Ich habe in ArcCatalogue nachgesehen, wie es in ArcGIS aussah, und Folgendes habe ich gesehen:

Beachten Sie das Fragezeichensymbol, auf dem ein Shapefile-Liniensymbol angezeigt werden soll. Offensichtlich kann ArcCatalogue diese Datei nicht lesen. Außerdem schien eine zweite DBF-Datei mit dem angehängten '_packed' erstellt worden zu sein. Wenn ich mir das Shapefile mit dem Windows Explorer ansehe, sehe ich, dass es bereits eine DBF für das Shapefile 'M3_PRE_SMU_lines_10Apr13_SMC.dbf' gibt. Daher weiß ich nicht, woher dieses gepackte Shapefile stammt, und ich kann nichts online finden das spricht dafür.

Ich habe versucht, diese Datei zu ArcMap hinzuzufügen, und habe den folgenden Fehler erhalten:

Der Fehler ist ziemlich selbsterklärend ... Die Anzahl der Formen stimmt nicht mit der Anzahl der Datensätze überein. Ich weiß nur nicht, warum das passiert. Es scheint nichts online zu geben, das erklärt, wie dies in QGIS vor sich geht, aber ich sehe ein paar Reparaturwerkzeuge. Ich habe das selbst repariert, indem ich einfach QGIS geöffnet, die Ebene hinzugefügt und dann mit der rechten Maustaste auf die Ebene geklickt und als weiteres Shapefile gespeichert habe. Also habe ich mir eine Lösung ausgedacht, aber ich hoffe, eine Lösung zu finden, die das erst gar nicht mehr vorkommt. Danke, Mike

Erläuterung

OGR (Teil von GDAL) ist die Bibliothek, mit der QGIS auf Shapefiles zugreift. Wenn OGR Features löscht, werden diese nicht sofort gelöscht, sondern nur als gelöscht markiert. Hin und wieder wird ein Befehl namens repack ausgeführt, der eine neue Datei mit dem Suffix _repack erstellt und alle Features, die nicht als gelöscht markiert sind, in diese neue Datei kopiert. Sobald dies abgeschlossen ist, wird die ursprüngliche DBF durch die Datei _repack.dbf ersetzt. Das Shapefile wird dann auf die gleiche Weise bearbeitet: Erstellen Sie ein neues (_packed.shp), kopieren Sie alle nicht gelöschten Features und ersetzen Sie schließlich das ursprüngliche .shp.

Es scheint irgendwo in diesem Prozess etwas fehlgeschlagen zu sein (vielleicht ein Absturz?).

Während dieses Vorgangs ändern sich die Feature-IDs. Vermutlich verwenden shp (Geometrie) und dbf (Attributtabelle) unterschiedliche Feature-IDs für dieselben Features. Dies führt zu dem seltsamen Verhalten, das Sie feststellen. Es scheint, dass eine der beiden Dateien noch (einen Teil) der gelöschten Funktionen enthält, während die andere dies nicht tut.

Wie gehe ich damit um?

Update, Nov. 2016: GDAL 2.2 wird mit einer integrierten Funktion ausgeliefert, die das automatische Umpacken aufruft, sobald die Datei auf die Festplatte geschrieben wird. Bevor Sie etwas anderes tun, überprüfen Sie die GDAL-Version im QGIS-Info-Dialogfeld und aktualisieren Sie Ihre GDAL-Version (oft als Teil von QGIS geliefert) auf eine aktuelle Version.

Es gibt wahrscheinlich nicht viel, was Sie dagegen tun können, abgesehen von regelmäßigen Sicherungen, um nicht mehr Daten zu verlieren, als Sie verarbeiten können (tun Sie das trotzdem, oder? 😉). Und wenn Sie einen Weg finden, dies zu reproduzieren (am besten mit einem Beispieldatensatz), erstellen Sie einen Fehlerbericht .

Wenn dieses Problem erneut auftritt, können Sie auch versuchen , einen räumlichen Index für das Shapefile zu erstellen . In diesem Prozess ruft QGIS erneut das Repacken des Shapefiles auf und "repariert" möglicherweise das shp / dbf. Dies ist jedoch nur eine unbestätigte Vermutung.

Wie von @rhm und in den Kommentaren erwähnt, kann es auch hilfreich sein , die Datei {xyz} _packed. {Ext} in {xyz}. {Ext} umzubenennen . Wenn die gepackte Datei bereits vollständig geschrieben wurde und nur die Umbenennung fehlgeschlagen ist, ist es absolut gültig, diesen Schritt manuell auszuführen. Wenn die _packed-Datei jedoch nicht vollständig geschrieben wurde, fehlen möglicherweise Informationen in Teilen Ihrer Funktionen. Also , bevor Sie versuchen , diese Sicherungskopien aller beteiligten Dateien.

Hintergrundinformationen darüber, wann das Umpacken aufgerufen wird

Zwischen QGIS 2.0 und 2.8 wurde das Umpacken aufgerufen, wenn der Layer entladen wurde (QGIS beenden, anderes Projekt laden ...). Wenn ein Feature gelöscht oder eine Geometrie geändert wurde, waren SHP- und DBF-Dateien mit als gelöscht gekennzeichneten Datensätzen vorhanden.

Ab QGIS 2.10 wird repack immer dann aufgerufen, wenn der Layer nach einer Operation gespeichert wird, bei der möglicherweise das gelöschte Flag zu Datensätzen hinzugefügt wird. Daher sollten sich die Dateien jetzt immer in einem vernünftigen Zustand befinden, damit sie von anderen Anwendungen verarbeitet werden können.

Das ist mir in QGIS passiert. Ich habe es geschafft, das Problem einfach zu beheben, indem ich '_packed' aus dem Dateinamen gelöscht habe, wie jemand im obigen Kommentarabschnitt vorgeschlagen hat.

Möglicherweise ist dies ein weiteres Problem einer beschädigten .shx-Indexdatei. Der Geometrietyp sollte in den Kopfzeilen .shp und .shx gespeichert werden. Wenn sie nicht übereinstimmen, generiert die Software einen Fehler.

Es sieht so aus, als ob QGIS bei defekten Indexdateien nicht sehr streng ist und diese mit neu erstellen kann Save As..., während ARCGIS auf einer korrekten Indexdatei besteht und eine gepackte DBF (Attributtabelle) für die Features erstellt, die über die korrekten Teile der gefunden werden können Indexdatei oder möglicherweise ohne Verwendung des Index.

Das erneute Auftreten gelöschter Features und / oder ungewöhnliches Verhalten von Shapefiles, aus denen Features in QGIS gelöscht wurden, ist ein bekannter Fehler. Weitere Informationen hierzu finden Sie in diesem Fehlerbericht 11007 und in dieser verwandten Frage. Gelöschte Polygone scheinen auf ältere Versionen zurückzukehren . Wenn ArcGIS Probleme mit solchen Shapefiles hat und diese in QGIS als MapInfo-TAB-Dateien gespeichert werden, führt dies zum Absturz des MapInfo-RouteFinder-Plugins, es sei denn, die Tabellen werden vor dem Laden von RouteFinder zuerst in MapInfo gepackt. Das Ausführen von Universal Translator zum Konvertieren dieser beschädigten Shapefiles in MapInfo schlägt fehl.

Wie Sie festgestellt haben, kann das Problem durch Speichern unter in QGIS behoben werden.