Umgehen des Feldnamens mit maximal 10 Zeichen in Shapefiles?

Ich exportiere Geometrie mit angehängten Textattributen aus der Oracle-Datenbank in das Esri-Shapefile-Format (.shp) mit Java- und Geotools-Bibliothek.

Attributspalten in unserer Datenbank haben Namen mit mehr als 10 Zeichen. Geotools erzwingt das Abschneiden dieser Namen. Ich verstehe, dass es an der Spezifikation von .shp- oder .dbf-Dateien liegt.

Ich kann das umgehen, indem ich eine einfache txt-Datei mit "shrtname" = "Der vollständige und lange Name" erstelle, aber offensichtlich wird sie von keiner anderen Software als unserer verstanden und importiert.

Gibt es eine offizielle Möglichkeit, die Zuordnung von kurzen Feldnamen zu langen Volltextnamen vorzunehmen?

Beispiel: XML-Datei neben allen anderen .shp .dbf .shx-Dateien.

Entschuldigung, die Antwort ist nein. Sie müssen Ihren eigenen Feld-Mapper ausrollen, und nur Software, die Ihren Mapper verwendet, wird ihn verstehen. Sie können auch andere Formate verwenden, für die diese Einschränkung nicht gilt (z. B. File-Geodatabase, Spatialite usw.).

Einige Ratschläge zu den Problemumgehungen aus eigener Erfahrung.

Wenn die Leute Shape - Dateien wählen (und darauf bestehen , auf ihnen) als Hauptformat wird in der Regel für ausgewählte Interoperabilität - man denke an sie als an eine spec haften. Wenn Sie sich dazu entschließen, Ihren eigenen Field Mapper zu rollen, tun Sie im Grunde das Gegenteil - da Sie Dinge außerhalb einer Spezifikation tun, haben Sie Ihre "erweiterte Spezifikation" erstellt.

Habe ich das in der Vergangenheit gemacht? Ja. Und es wird mit Sicherheit immer schmerzhafter, als ein Problem tatsächlich zu lösen, denn jedes Mal, wenn Sie versuchen, die Shapefiles in etwas anderes zu öffnen, das Shapefiles lesen / schreiben kann, erhalten Sie eine Tabelle mit einer ganzen Reihe schwer verständlicher Felder .

An diesem Punkt würde ich Sie fragen, warum Sie Shapefiles verwenden? Entwickeln Sie entweder eine Workflow-Lösung, die sich an die Shapefile-Spezifikation und ihre Einschränkungen hält, oder ändern Sie die Dateiformate. Alles andere ist nur ein Rezept für Kopfschmerzen.

Es gibt eine Standardmethode, um damit umzugehen, auch wenn Ihre Kunden möglicherweise nicht ganz zufrieden sind: Sie exportieren zwei Dateien, ein Shapefile und eine Datendatei in einem Format, das ihre Software lesen kann. Das Shapefile hat nur einen eindeutigen Bezeichner [Id] für Attribute. Die Datendatei hat mehrere Attribute: [ID], um der Form zu entsprechen, [Feld], um den Feldnamen bereitzustellen, [Typ], um den Typ anzugeben, und ein Attribut für jeden möglichen Datentyp, um den Wert zu speichern. Jedes Feld in der Originaldatei wird als Datensatz in dieser Datendatei gespeichert.

Eine Quelltabelle sieht beispielsweise so aus:

[Shape] [Id] [Name]     [Population2010]
shape1  A1   California         37253956
shape2  A2   Texas              25145561
shape3  A3   Wyoming              563626

hätte eine entsprechende datendatei

[Id] [Field]        [Type]  [Text]     [Integer]
A1   Name           Text    California    <Null>
A1   Population2010 Integer <Null>      37253956
A2   Name           Text    Texas         <Null>
A2   Population2010 Integer <Null>      25145561
A3   Name           Text    Wyoming       <Null>
A3   Population2010 Integer <Null>        563262

Es sollte offensichtlich sein, wie diese Daten in einem beliebigen RDBMS verwendet werden und wie zwischen den beiden Formaten hin und her konvertiert wird.

Wenn Ihr Kunde ArcGIS verwendet, können Sie ein Skript bereitstellen, um Feldaliase in großen Mengen zuzuweisen . Dies würde ihnen das Aussehen langer Feldnamen geben, wenn sie die Daten verwenden.

Ähnliche Skripte können auch Aliase in anderen GIS-Paketen enthalten.

Der einfachste Weg ist, NUR Ihre Geometrie als Shapefile zu speichern. Aufgrund der hervorragenden Bearbeitungsmöglichkeiten für Geometrien, die in vielen GIS-Anwendungen vorhanden sind, speichern Sie NOCH alle Ihre Felddaten (oder den Großteil davon) in sqlite als Tabellen. Machen Sie bei Bedarf mit, um Ihre Felddaten zu recherchieren.

ABER Wenn Sie die Tabellen bearbeiten müssen, während Sie räumliche Abfragen durchführen oder die Shapefile-Features in QGIS auswählen, müssen Sie [Shapefiles, die mit SQLite-Tabellen verknüpft sind] als Option vergessen und stattdessen alles nach Spatialite exportieren. Erfahren Sie, wie Sie Qspatialite und Spatialite_GUI verwenden (beide sind komplementär und enthalten viele Funktionen, die die anderen nicht bieten - Sie werden beide benötigen und verwenden, wenn Sie viele Dinge mit SQLITE tun).

Es ist wichtig zu beachten, dass diese Tabellen (mit Shapefile verbunden) nicht gleichzeitig mit dem Join bearbeitet werden können. Die Migration zu Spatialite wäre daher eine hervorragende Alternative zu Shapefiles. Es behält die Einfachheit und Portabilität von Shapefiles bei und bietet gleichzeitig die meisten Vorteile einer SQL-Datenbank, ohne die Komplexität von PostgreSQL.

Temporäre Korrekturen können als TAB-Datei gespeichert werden, die Spaltennamen mit bis zu 31 Zeichen enthalten kann.