¿Omitiendo el límite de 10 caracteres del nombre del campo en los archivos de forma?

Estoy exportando geometría con atributos de texto adjuntos desde la base de datos Oracle al formato de archivo de forma esri (.shp) con la biblioteca Java y Geotools.

Las columnas de atributos en nuestra base de datos tienen nombres con más de 10 caracteres, y Geotools obliga a truncarlos. Entiendo que se debe a la especificación de archivos .shp o .dbf.

Puedo solucionar esto creando un simple archivo txt con "shrtname" = "El nombre completo y largo", pero obviamente no será comprendido e importado por ningún otro software que no sea el nuestro.

¿Hay alguna forma oficial de hacer la asignación de nombres de campo cortos a nombres de texto completo largos?

Por ejemplo, archivo xml junto a todos los demás archivos .shp .dbf .shx.

Lo siento, la respuesta es no. Debe desplegar su propio mapeador de campo y solo el software que use su mapeador lo entenderá. Sin embargo, podría usar otros formatos que no tengan esta limitación (por ejemplo, geodatabase de archivos, espacio espacial, etc.).

Algunos consejos sobre las soluciones de la experiencia personal.

Cuando las personas eligen los archivos de forma (e insisten en ellos) como su formato principal, generalmente se elige por interoperabilidad ; piense en ello como si se apegara a una especificación. Si elige rodar su propio mapeador de campo, básicamente está haciendo todo lo contrario, ya que está haciendo cosas fuera de una especificación, ha creado su "especificación extendida".

¿He hecho esto en el pasado? Sí. Y ciertamente siempre resulta más doloroso que realmente resolver un problema porque cada vez que intentas abrir los archivos de formas en cualquier otra cosa que pueda leer / escribir archivos de formas, terminas con una tabla con un montón de campos difíciles de entender .

En ese momento, te preguntaría, ¿por qué estás usando shapefiles? Cree una solución de flujo de trabajo que se ajuste a las especificaciones del archivo de forma y sus limitaciones, o cambie los formatos de archivo. Todo lo demás es solo una receta para los dolores de cabeza.

Hay una forma estándar de lidiar con esto, aunque es posible que sus clientes no estén completamente satisfechos: exporta dos archivos, un archivo de forma y un archivo de datos en un formato que su software pueda leer. El archivo de forma solo tiene un identificador único, [Id], para los atributos. El archivo de datos tiene varios atributos: [Id] para que coincida con la forma, [Campo] para proporcionar el nombre del campo, [Tipo] para indicar su tipo y un atributo de cada tipo de datos posible para almacenar el valor. Cada campo en el archivo original se almacena como un registro en este archivo de datos.

Por ejemplo, una tabla fuente con este aspecto:

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

tendría un archivo de datos correspondiente

[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

Debería ser obvio cómo usar estos datos en cualquier RDBMS y cómo convertir de ida y vuelta entre los dos formatos.

Si su cliente está utilizando ArcGIS, puede proporcionar un script para asignar alias de campo de forma masiva . Esto les daría la apariencia de nombres de campo largos cuando usan los datos.

Una secuencia de comandos similar también puede funcionar para proporcionar alias en otros paquetes SIG.

La ruta más fácil de tomar es almacenar SOLO su geometría como un archivo de forma, por las excelentes capacidades de edición de geometría que existen en muchas aplicaciones SIG, TODAVÍA almacena todos sus datos de campo (o la mayor parte de ellos) en sqlite como tablas. Únase a ellos según sea necesario para investigar sus datos de campo.

PERO si necesita editar las tablas mientras realiza consultas espaciales, o selecciona las características del archivo de forma en QGIS, deberá olvidar [los archivos de forma unidos a las tablas sqlite] como una opción, y en su lugar exportar todo a Spatialite. Aprenda a usar Qspatialite y Spatialite_GUI (ambos son complementarios entre sí con muchas características que el otro carece; necesitará y usará ambos si hace muchas cosas con SQLITE)

Es importante tener en cuenta que esas tablas (unidas a shapefile) no serían editables al mismo tiempo que la unión. Y, por lo tanto, migrar a Spatialite sería una excelente alternativa a los shapefiles. Se mantiene con la simplicidad y la portabilidad de los archivos de forma al tiempo que ofrece la mayoría de las virtudes de una base de datos SQL, sin la complejidad de PostgreSQL.

Se puede solucionar temporalmente, guardando como archivo TAB, que puede tener nombres de columna de hasta 31 caracteres de longitud.