¿Saltar el límite de 10 caracteres del nombre del campo en los shapefiles?

Question

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

Las columnas de atributos de 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 los archivos .shp o .dbf.

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

¿Existe una forma oficial de hacer el mapeo de nombres de campo cortos a nombres largos de texto completo?

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

Answer 1

Lo siento, la respuesta es no. Tienes que desplegar tu propio mapeador de campos y sólo el software que utiliza tu mapeador lo entenderá. Sin embargo, podrías utilizar otros formatos que no tengan esta limitación (por ejemplo, geodatabase de archivos, spatialite, etc).

---

Algunos consejos sobre las soluciones de la experiencia personal.

Cuando la gente elige los shapefiles (e insiste en ellos) como formato principal, se suele elegir por interoperabilidad - pensar en ello como la adhesión a una especificación. Si eliges hacer tu propio mapeador de campos, básicamente estás haciendo todo lo contrario - ya que estás haciendo cosas fuera de una especificación - has creado tu "especificación extendida".

¿He hecho esto en el pasado? Sí. Y ciertamente siempre se convierte en una molestia más que en la solución de un problema, porque cada vez que intentas abrir los shapefiles en cualquier otra cosa que pueda leer/escribir shapefiles, terminas con una tabla con un montón de campos difíciles de entender.

Llegados a este punto, te preguntaría: ¿por qué utilizas shapefiles? O bien se propone una solución de flujo de trabajo que se ciña a la especificación de los shapefiles y sus limitaciones, o bien se cambia de formato de archivo. Todo lo demás es una receta para los dolores de cabeza.

Answer 2

Hay una forma estándar de hacerlo, aunque sus clientes no estén del todo contentos: se exportan dos archivos, un shapefile y un archivo de datos en un formato que su software pueda leer. El shapefile sólo 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 del archivo original se almacena como un registro en este archivo de datos.

Por ejemplo, una tabla de origen con el siguiente 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 utilizar estos datos en cualquier RDBMS y cómo convertir de ida y vuelta entre los dos formatos.

Answer 3

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

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

Answer 4

El camino más fácil es almacenar SÓLO su geometría como un shapefile, por las excelentes capacidades de edición de la geometría que existen en muchas aplicaciones SIG, PERO almacenar todos sus datos de campo (o la mayor parte de ellos) en sqlite como tablas. Únelos según sea necesario para investigar sus datos de campo.

PERO si necesitas editar las tablas mientras haces consultas espaciales, o seleccionas las características del shapefile en QGIS, tendrás que olvidar [shapefiles unidos a tablas sqlite] como opción, y en su lugar exportar todo a Spatialite. Aprenda a utilizar Qspatialite y Spatialite_GUI (ambos son complementarios entre sí con muchas características de las que carece el otro - necesitará y utilizará ambos si hace muchas cosas con SQLITE)

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

Answer 5

La solución temporal puede ser, guardar como archivo TAB, que puede tener nombres de columnas de hasta 31 caracteres.