Bypassare il limite di 10 caratteri del nome del campo negli shapefile?

Sto esportando la geometria con gli attributi di testo allegati dal database Oracle in formato esri shapefile (.shp) con la libreria Java e Geotools.

Le colonne di attributi nel nostro database hanno nomi con più di 10 caratteri e Geotools forza a troncarli. Capisco che è dovuto alla specifica dei file .shp o .dbf.

Posso ovviare a questo, creando un semplice file txt con "shrtname" = "Il nome completo e lungo", ma ovviamente non sarà compreso e importato da nessun altro software diverso dal nostro.

Esiste un modo ufficiale per eseguire il mapping da nomi di campi brevi a nomi di testo completi lunghi?

Ad esempio, il file xml accanto a tutti gli altri file .shp .dbf .shx.

Siamo spiacenti, la risposta è no. Devi implementare il tuo mappatore di campo e solo il software che utilizza il mappatore lo capirà. Tuttavia, è possibile utilizzare altri formati che non presentano questa limitazione (ad es. File geodatabase, spatialite, ecc.).

Qualche parola di consiglio sulle soluzioni alternative per esperienza personale.

Quando le persone scelgono gli shapefile (e insistono su di essi) come il loro formato principale, di solito viene scelto per l' interoperabilità - pensalo come aderente a una specifica. Se scegli di creare il tuo mappatore di campi, fondamentalmente stai facendo esattamente il contrario - dato che stai facendo cose al di fuori di una specifica - hai creato la tua "specifica estesa".

L'ho fatto in passato? Sì. E sicuramente si trasforma sempre in più di un dolore che nel risolvere effettivamente un problema perché ogni volta che provi ad aprire gli shapefile in qualsiasi altra cosa in grado di leggere / scrivere gli shapefile, finisci con una tabella con un sacco di campi difficili da capire .

A quel punto, ti chiederei, perché stai usando gli shapefile? O escogitare una soluzione per il flusso di lavoro che rispetti le specifiche dello shapefile e i suoi limiti o modificare i formati di file. Tutto il resto è solo una ricetta per il mal di testa.

Esiste un modo standard per gestirlo, anche se i tuoi clienti potrebbero non esserne completamente soddisfatti: esporti due file, uno shapefile e un file di dati in un formato leggibile dal loro software. Lo shapefile ha solo un identificatore univoco, [Id], per gli attributi. Il file di dati ha diversi attributi: [Id] per abbinare la forma, [Campo] per fornire il nome del campo, [Tipo] per indicarne il tipo e un attributo di ogni possibile tipo di dati per memorizzare il valore. Ogni campo nel file originale viene archiviato come record in questo file di dati.

Ad esempio, una tabella di origine simile a questa:

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

avrebbe un file di dati corrispondente

[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

Dovrebbe essere ovvio come utilizzare questi dati in qualsiasi RDBMS e come convertire avanti e indietro tra i due formati.

Se il cliente utilizza ArcGIS, è possibile fornire uno script per assegnare gli alias di campo in blocco . Ciò darebbe loro l'aspetto di nomi di campi lunghi quando usano i dati.

Script simili possono funzionare anche per fornire alias in altri pacchetti GIS.

Il percorso più semplice da intraprendere è archiviare SOLO la geometria come file di forma, per le eccellenti capacità di modifica della geometria esistenti in molte applicazioni GIS, ANCORA archiviare tutti i dati del campo (o la maggior parte di essi) in sqlite come tabelle. Unisciti a loro se necessario per ricercare i dati sul campo.

MA Se è necessario modificare le tabelle mentre si eseguono query spaziali o selezionare le funzionalità dello shapefile in QGIS, sarà necessario dimenticare [gli shapefile uniti alle tabelle sqlite] come opzione e invece esportare tutto su Spatialite. Impara a usare Qspatialite e Spatialite_GUI (sono entrambi complementari tra loro con molte funzionalità che le altre mancano - ti serviranno e userai entrambe se fai molte cose con SQLITE)

È importante tenere presente che le tabelle (unite a shapefile) non sarebbero modificabili contemporaneamente al join. E quindi migrare su Spatialite sarebbe un'ottima alternativa ai shapefile. Mantiene la semplicità e la portabilità dei shapefile offrendo al contempo la maggior parte delle virtù di un database SQL, senza la complessità di PostgreSQL.

La correzione temporanea può essere, salvando come file TAB, che può avere nomi di colonna lunghi fino a 31 caratteri.