Ignorando o limite de 10 caracteres do nome do campo em shapefiles?

Estou exportando geometria com atributos de texto anexados do banco de dados oracle para o formato esri shapefile (.shp) com a biblioteca Java e Geotools.

As colunas de atributo em nosso banco de dados têm nomes com mais de 10 caracteres e o Geotools força para truncá-los. Entendo que é devido à especificação de arquivos .shp ou .dbf.

Eu posso contornar isso, criando um arquivo txt simples com "shrtname" = "O nome completo e longo", mas obviamente ele não será entendido e importado por nenhum outro software que não o nosso.

Existe uma maneira oficial de fazer o mapeamento de nomes curtos de campos para nomes longos de texto completo?

Por exemplo, arquivo xml próximo a todos os outros arquivos .shp .dbf .shx.

Desculpe, a resposta é não. Você precisa implementar seu próprio mapeador de campo e somente o software que usa o seu mapeador o entenderá. Você pode usar outros formatos que não possuem essa limitação (por exemplo, geodatabase de arquivo, espaço espacial, etc).

Alguma palavra de conselho sobre as soluções alternativas da experiência pessoal.

Quando as pessoas escolhem os shapefiles (e insistem neles) como seu formato principal, geralmente é escolhido para interoperabilidade - pense nisso como aderente a uma especificação. Se você optar por rolar seu próprio mapeador de campo, estará basicamente fazendo o contrário - já que está fazendo coisas fora de uma especificação - você criou sua "especificação estendida".

Eu fiz isso no passado? Sim. E certamente sempre se torna mais problemático do que realmente resolver um problema, porque toda vez que você tenta abrir os arquivos shapefiles em qualquer outra coisa que possa ler / escrever arquivos shapefiles, você acaba com uma tabela com vários campos difíceis de entender .

Nesse ponto, eu perguntaria: por que você está usando shapefiles? Crie uma solução de fluxo de trabalho que atenda às especificações do shapefile e suas limitações ou altere os formatos de arquivo. Tudo o resto é apenas uma receita para dores de cabeça.

Existe uma maneira padrão de lidar com isso, embora seus clientes possam não estar completamente satisfeitos com isso: você exporta dois arquivos, um shapefile e um arquivo de dados em um formato que seu software possa ler. O shapefile possui apenas um identificador exclusivo, [Id], para atributos. O arquivo de dados possui vários atributos: [Id] para corresponder à forma, [Field] para fornecer o nome do campo, [Type] para indicar seu tipo e um atributo de cada tipo de dados possível para armazenar o valor. Cada campo no arquivo original é armazenado como um registro nesse arquivo de dados.

Por exemplo, uma tabela de origem parecida com esta:

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

teria um arquivo de dados correspondente

[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

Deve ser óbvio como usar esses dados em qualquer RDBMS e como converter entre os dois formatos.

Se seu cliente estiver usando o ArcGIS, você poderá fornecer um script para atribuir aliases de campo em massa . Isso lhes daria a aparência de nomes longos de campos quando eles estiverem usando os dados.

Os scripts semelhantes também podem funcionar para fornecer aliases em outros pacotes GIS.

A rota mais fácil a seguir é armazenar SOMENTE sua geometria como um arquivo de forma, para os excelentes recursos de edição de geometria que existem em muitos aplicativos GIS, YET armazena todos os seus dados de campo (ou a maior parte deles) no sqlite como tabelas. Junte-se a eles conforme necessário para pesquisar seus dados de campo.

MAS Se você precisar editar as tabelas ao fazer consultas espaciais ou selecionar os recursos de shapefile no QGIS, será necessário esquecer [arquivos de shapefile associados a tabelas sqlite] como opção e exportar tudo para o Spatialite. Aprenda a usar o Qspatialite e o Spatialite_GUI (ambos são complementares entre si com muitos recursos que o outro carece - você precisará e usará ambos se fizer muitas coisas com o SQLITE)

É importante ter em mente que essas tabelas (associadas ao shapefile) não seriam editáveis ​​ao mesmo tempo que a associação. E assim, migrar para o Spatialite seria uma excelente alternativa aos arquivos de forma. Ele mantém a simplicidade e portabilidade dos shapefiles, oferecendo a maioria das virtudes de um banco de dados SQL, sem a complexidade do PostgreSQL.

A correção temporária pode ser, salvando como arquivo TAB, que pode ter nomes de colunas com até 31 caracteres.