[Gvsig_desarrolladores] Obtener tabla de atributos de shp

Jue Jul 21 13:24:48 CEST 2016

El 19 de julio de 2016, 11:35, Francisco Puga <fpuga en icarto.es> escribió:

> En el plugin de landregistryviewer [1] tienes un ejemplo de como hacer
> esto.
>
> Respecto a lo de la versión ten en cuenta donde estás desplegando el
> plugin que estás escribiendo. Por defecto al hacer un mvn install, se busca
> un fichero en el home del usuario llamado .gvsig-devel.properties. En este
> fichero hay una variable que indica la ruta en la que se desplegará el
> plugin. Modifica ese fichero para que el plugin se copie a la carpeta
> extensiones de la instalación de gvSIG que te interese.
>
> Que puede ser la que hayas compilado tu mismo desde el entorno de
> desarrollo, o una versión que te hayas descargado desde la web. Si no me
> equivoco al hacer el mvn install también tienes la opción de pasarle un
> parámetro para indicarle en que gvsig debe desplegarse.
>
>
> Te enlazo una clase que uso yo para cargar shapes desde disco por si te
> resulta más cómodo. Puedes copiarla y pegarla a tu proyecto aunque se
> agradece citación de autoría
>
> https://github.com/iCarto/es.icarto.gvsig.commons/blob/gvsig2/src/main/java/es/icarto/gvsig/commons/datasources/SHPFactory.java#L71
>
> La lista de atributos de una capa la puedes obtener con algo como
>
> FeatureStore fs = null;
> FeatureType featureType = fs.getFeatureSet().getDefaultFeatureType();
> FeatureAttributeDescriptor[] attDescs =
> featureType.getAttributeDescriptors();
>
> Iterando a través de attDescs y pidiéndoles el getName puedes obtener
> todos los nombres de los atributos.
>
> Fijate que dentro del attDescs estará también el campo de geometría, por
> tanto si quieres saltártelo a la hora de mostrar información al usuario:
>
> geomIdx = defaultFeatureType.getDefaultGeometryAttributeIndex();
>
> for (int i=0, max=attDescs.length; i<max;i++) {
>     if (i == geomIdx) {
>         continue;
>     }
>     String attName = attDescs[i].getName();
> }
>
>

Hola,
me voy a permitir algunos de comentarios al codigo de Fran.

para obtener el FeatureType si tienes un FeautureStore, no hace falta
pedir un FeatureSet, que no se sabe si puede o no tener un coste elevado
en recursos de obtener. Se le puede pedir directamente al FeatureStore.
Esto es en lugar de:

  FeatureType featureType = fs.getFeatureSet().getDefaultFeatureType();

Usar:

  FeatureType featureType = fs.getDefaultFeatureType();

Otro comentario es un error muy comun, y esta en el metodo createSHP
de la clase SHPFactory que ha enlazado Fran.

Para crear un nuevo store, por ejemplo un nuevo shape, hay que crear una
instancia de NewDataStoreParameters del proveedor que nos interese (el de
shape
en este caso). Para abrir un store ya existente se debe usar una instancia
de
OpenDataStoreParameters.

En el metodo createSHP se crea un NewDataStoreParameters y se usa tanto
para
crear de nuevo el shape como para abrirlo una vez creado.

Con el proveedor de shape, pasa algo extraño. La implementacion de
SHPNewStoreParameters extiende de SHPStoreParameters, pero eso es una
peculiaridad de
la implementacion del proveedor y es la causante de que pueda usarse un
NewDataStoreParameters como parametros para abrir un shape existente.

Para otros provedores esto no sucede. Si lo intentas fallara. Y nadie
garantiza que
para el shape eso siga funcionando asi en proximas versiones de gvSIG. El
que funciona
ahora mismo para shapes es fruto de un error, o mas bien de un atajo del
programador
que implemento ese proveedor. El dia que eso se corrija dejara de funcionar
que
se pueda abrir un shape usando como parametros un NewDataStoreParameters.

Un par de cosillas mas menos que no son muy importantes.

La primera tiene que ver con como funciona la edicion en los
FeatureStore-s.
Hay varios modos de edicion, el de por defecto es MODE_FULLEDIT. En este
metodo
todas las operaciones de escritura se van almacenando en memoria y cuando
se
termina la edicion se trasladan a la fuente de datos, por ejemplo a un
fichero
shape. Si no quieres actualizar, si no solo añadir datos a un shape, es mas
optimo
usar el metodo de edicion MODE_APPEND. Eso solo permite hacer insterts de
nuevas features, que se añadiran al final, y se van añadiendo en el momento
de hacer el insert. Este modo no permite hacer consultas, ni borrados, nada
que
no sean inserts. Pero biene muy bien cuando creamos un shape y simplemente
queremos añadir registros. Lo comento por el codigo al final del metodo
createSHP...

  store.edit();
  for (EditableFeature f : features) {
    store.insert(f);
  }
  store.finishEditing();

Cambiado la llamada a "edit()" por "edit(MODE_APPEND)", las inserts irian
directamente al shape en lugar de guardarse en memoria y volcarse al shape
en el momento de llamar a finishEditing.

No creo que en este contexto se importante, ya que estamos trabajando con un
array de features que no deberia ser muy grande; pero cuando estamos
ejecutando
un proceso sobre una fuente de datos para generar otro store (shape por
ejemplo),
en donde no sabemos si va a ver 10 registros o 10.000.000 de registros si
que
puede ser interesante tenerlo en mente.

A ver... la otra cosa... tampoco parece muy importante cuando estemos
trabajando con shape, pero no estaria mal acostumbrarse a ello ya que
cuando estemos usando BBDD puede llegar a ser critico.
Hay muchos metodos relacionados con objetos de DAL que implementan el
interface
Disposable, vamos que tienen un metodo dispose. Como por ejemplo el
DataStore.
Tenemos que acostumbrarnos a llamar siempre al metodo dispose de esos
objetos ya que si no lo hacemos pueden quedar recursos por liberar. En el
metodo createSHP se le llama...pero solo si todo va bien. Si se produce
algun
error ya no se llama al dispose y los recursos pueden quedar pillados.
Mi consejo es que se usen construcciones del tipo:

  FeatureStore store = null;
  try {

    ...

  } finally {
    DisposeUtils.disposeQuietly(store);
  }

Asi nos aseguramos que siempre se liberen los recursos. (Con BBDD pueden
llegar a
quedarse conexiones al servidor cogidas y que no se liberarian hasta que se
cerrase gvSIG lo que puede ser muy grave).

Un saludo
Joaquin

>
> [1]
> http://devel.gvsig.org/svn/gvsig-plugintemplates/org.gvsig.landregistryviewer/trunk/org.gvsig.landregistryviewer/
>
> El 18 de julio de 2016, 16:09, maru.cristiani <maru.cristiani en gmail.com>
> escribió:
>
>> Hola, como estan?
>>
>> Estamos desarrollando una extension, y necesitariamos poder levantar desde
>> la extension un SHP y listar todas sus columnas e informacion.
>>
>> Estamos en la version de gvSIG desktop
>>     <version>2.0.106-SNAPSHOT</version>
>>
>> Sin embargo cuando levantamos la aplicacion nos dice que es la version:
>> 2.3.0.2403
>>
>> Tienen algun pseudocodigo, o codigo ya en Java, para levantar un .shp e
>> interpretarlo?
>>
>> Gracias!
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Obtener-tabla-de-atributos-de-shp-tp5276903.html
>> Sent from the gvSIG desarrolladores mailing list archive at Nabble.com.
>> _______________________________________________
>> gvSIG_desarrolladores mailing list
>> gvSIG_desarrolladores en listserv.gva.es
>> Para ver histórico de mensajes, editar sus preferencias de usuario o
>> darse de baja en esta lista, acuda a la siguiente dirección:
>> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>>
>
>
>
> --
> Francisco Puga
> iCarto | Innovación, Cooperación, Cartografía y Territorio S.L.
> http://www.icarto.es/
>
> c/ Rafael Alberti nº 13 – 1º D
> 15008 A Coruña
> Galicia (Spain)
> +34 881927808
>
> Este correo electrónico contiene información estrictamente confidencial y
> es de uso exclusivo del destinatario, quedando prohibida a cualquier otra
> persona su revelación, copia, distribución, o el ejercicio de cualquier
> acción relativa a su contenido. Si ha recibido este mensaje por error, por
> favor conteste a su remitente mediante correo electrónico y proceda a
> borrarlo de su sistema.
>
> Sus datos personales serán tratados de forma confidencial y no serán
> cedidos a terceros ajenos a ICARTO. En cualquier caso, podrá ejercer los
> derecho de oposición, acceso, rectificación y cancelación de acuerdo con lo
> establecido en la Ley Orgánica 15/99, de 13 de diciembre, de Protección de
> Datos de Carácter Personal dirigiéndose a Innovación, Cooperación,
> Cartografía e Territorio, SL. (ICARTO) en la dirección postal a C/ Rafael
> Alberti, nº 13, 1ºD, 15.008 – (A Coruña).
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse
> de baja en esta lista, acuda a la siguiente dirección:
> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>

-- 
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
jjdelcerro en gvsig.com
jjdelcerro en gvsig.org
gvSIG Association
www.gvsig.com
www.gvsig.org
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20160721/b9e643c8/attachment.html>