Servicios de formación en la Asociación gvSIG

Posted on 21/06/2016 by Mario

Desde la Asociación gvSIG ofrecemos diversos cursos para usuarios y desarrolladores, tanto de la aplicación gvSIG como de geomática libre, y cuyos beneficios revierten en el proyecto gvSIG, con desarrollo de nuevas funcionalidades, corrección de errores…

Servicios_de_formacion

Dentro de las modalidades disponibles, aparte de la presencial (con desplazamiento de profesor) y online (a través de la plataforma gvsig-training.com), que se están llevando a cabo durante los últimos años, una novedad importante es que ahora se ha incluido la modalidad webinar, donde se imparte el curso en directo a través de una plataforma online de vídeo, y en el que hay interacción entre el tutor y los alumnos. De esa forma se evitan los costes de desplazamiento y manutención del profesor.

Dentro de los cursos de gvSIG disponibles existe por un lado uno genérico para usuarios, y por otro lado diversos cursos aplicados a distintas temáticas como Medio Ambiente, Fauna, Espacios Naturales Protegidos, Gestión de Pavimentos y Vialidad, y también sobre Gestión Municipal. Todos ellos de matrícula abierta, por lo que el alumno puede matricularse cuando desee.

Con el curso de usuario genérico, así como con los de Medio Ambiente, Fauna y Espacios Naturales, se obtiene el Certificado gvSIG Usuario Básico. Con los otros dos cursos el alumno obtiene créditos que le permiten obtener el Certificado gvSIG Usuario Experto (completando un total de 100 créditos de los cursos que convalidan para dicho certificado).

Otro tipo de cursos ofrecidos por la Asociación gvSIG son los relativos a Geoprocesamiento y Análisis Espacial. Dentro de estos se encuentra el curso “Geoprocesamiento Avanzado sobre gvSIG”, con una temática diversa sobre análisis ráster y vectorial, modelos digitales de terreno, perfiles, visibilidad…, y aparte cursos más pequeños sobre algunos de los temas del curso anterior en caso de que el usuario esté interesado en una temática concreta (Análisis del Terreno e Hidrológico, Análisis de Visibilidad e iluminación, Análisis de Perfiles y Secciones transversales, o Análisis de Costes y Rutas óptimas.

Todos estos cursos tienen edición en español y en portugués, y dan una serie de créditos para obtener el Certificado gvSIG Usuario Experto.

Dentro de las extensiones de gvSIG, existen varios cursos como son el de Análisis de Redes con gvSIG Desktop, Navtable y Normalización de Tablas, Publicación de Servicios OGC, Análisis Geoestadístico con gvSIG y Sextante, Uso, creación y gestión de metadatos de información geográfica, y gvSIG 3D y animación. Todos ellos convalidan para el Certificado gvSIG Usuario Experto.

Respecto a los cursos relativos a geomática libre, se ofrece uno sobre ”Bases de Datos Geoespaciales: PostgreSQL – PostGIS”, el cual tiene dos niveles disponibles (básico y avanzado).

Finalmente, se ofrecen cursos personalizados conforme a las necesidades de los solicitantes. Por ejemplo, se han llevado a cabo cursos sobre gvSIG aplicado a Oceanografía, a Protección Civil, a Topografía…, o incluso cursos más cortos sobre unas funcionalidades concretas como puede ser el cambio de sistemas de referencia y conversión de ficheros a KML para cargar en Google Earth, incluyendo descarga de datos de servidores públicos de cartografía.

Para la modalidad online de los cursos, puedes hacer directamente el pedido en el portal gvsig-training.com. Entrando en el curso deseado verás un enlace para hacer el pedido, donde te indicará las instrucciones a seguir para realizar el pago. Así mismo, la mayoría de cursos disponen de ciertos descuentos, así como de subvenciones del 100%. Puedes ver dicha información dentro de cada curso.

Si deseas formación presencial o en modalidad webinar, o para cualquier otra duda relacionada con formación, puedes contactar con nosotros directamente escribiéndonos a info@gvsig.com.

Realizando estos cursos a través de la Asociación gvSIG estarías contribuyendo al crecimiento de este proyecto.

Posted in community, gvSIG Desktop, portuguese, spanish, training | Tagged | Leave a comment

Towards gvSIG 2.3: LiDAR data

Posted on 20/06/2016 by Giuliano Ramat

In gvSIG 2.3 users will be able to access a new source of data that has been using more and more, the LiDAR data. gvSIG 2.3 drivers provide to read and write LiDAR in gvSIG according to LAS specification. A cropping tool will be also provided to export a subset of LIDAR data.

Drivers

User will have two options for working with LAS files, based on gvSIG implementation of two different libraries, each one with its advantages:

  • JGrasstools based provider that is read / write.

  • Whitebox based that is read-only provider, but currently offers better performance than the one based on Jgrasstools.

Clarified/simplification

Both drivers include two parameters “clarified” (simplification), which let you read a subset of the total points available in the LAS file. Simplification allows quickly draw huge files at small scales (where a level of detail as high as that provides the file is not required):

  • ThinningDivisor: reads 1 point out of n items (1 / n), for example when thinningDivisor = 10 it loads 10% of the total available points

  • ThinningResolution: load approximately n dots per square unit of the layer; for example, if thinningResolution = 0.0001 means that it loads 0.0001 points / m2 (assuming that in this case layer projection units are meters), or that is the same, 100 points / km²

Attributes

LAS files have a set of mandatory fields (fixed) and other optional depending on point data format as specified in the LAS file header.

Mandatory fields are:

  • CLASSIFICATION (land cover) 
  • POINTX (x coordinate of the point)
  • POINTY (coordinate of the point)
  • POINTZ (z coordinate of the point, useful to symbolize elevations)
  • INTENSITY (intensity)
  • RETURNNUM (point return number)
  • NUMBEROFRETURNS (number of returns for this laser pulse) 

Optional fields are:

  • COLOR (color point, expressed as a whole “long” Java containing the RGB value)
  • TIME (absolute time capture, expressed as generated by Data.getTime ())
  • WEEKTIME (relative time capture, expressed as a weekly GPS time) 

Export tool

Cropping tool allows you to choose a data subset to be exported to a new LAS file.

The tool lets you choose a geographic extension to filter the data (only points that fall within the selected geographic extension will be exported). The possible options are:

  • No filter by geometric extension

  • Filter data using extension visible in the active view.

  • Filter using a geometric extension specified by the user.

It is important to note that if users load the layer in the view using data options “clarified” (simplification), the export tool will act according to these options, exporting only the simplified version of the data.

To make this topic easier to understand, you can watch a couple of videos related to the LiDAR data management in gvSIG.

Posted in english, gvSIG Desktop | Tagged , , | 1 Comment

Camino a gvSIG 2.3: Soporte vectorial en Vistas 3D y extrusión

Posted on 20/06/2016 by Alvaro

gvSIG es uno de los pocos SIG en software libre que puede presumir de disponer de Vistas 3D, gracias a la integración de gvSIG con el software NASA World Wind. En gvSIG 2.3 vamos a tener una serie de mejoras que van a dar a los usuarios nuevas herramientas para trabajar con información geográfica en 3D.

Entre estas mejoras se encuentra la extrusión y para ello era necesario desarrollar el soporte de datos vectoriales en 3D (hasta ahora las capas vectoriales se mostraban rasterizadas en Vistas 3D). Veamos en detalle estas mejoras…

Datos vectoriales

En gvSIG 2.3 podremos seleccionar el modo de visualización de los datos vectoriales en Vistas 3D. Se mostrarán tres modos diferentes de cargar una capa vectorial:

  • Rasterizado: la capa vectorial de la Vista 2D será rasterizada como una imagen que se mostrará en la Vista 3D (como ocurría en gvSIG 2.2).
  • Vector: los elementos de las capas vectoriales de la Vista 2D serán transformados en vectores 3D y cargados en la Vista 3D.
  • Extrusión: los elementos de la capa vectorial de la Vista 2D serán transformados en vectores 3D y cargados en la Vista 3D, aplicando una extrusión para obtener un efecto de volumen.

Modo Vector

En el modo vector podremos seleccionar la altitud de los elementos por dos factores (o la suma de ambos): La tercera dimensión de la geometría, en caso de que sea una capa 3D (por ejemplo un shapefile 3D) o un parámetro o constante de altura.

Se podrán aplicar 3 modos de elevación, cada uno de los cuales aplicará la altitud de un modo diferente:

  • Clamp to ground (Fijado al terreno): los elementos se superpondrán al modelo digital del terreno existente en la Vista 3D.
  • Absolute (Absoluto): la elevación de los elementos vectoriales estará dada por la altitud, definida como la altura sobre el nivel del mar.
  • Relative to ground (Relativo al terreno): la altitud de los elementos vectoriales estará dada por la altura, definida como la altura relativa sobre el terreno.

3D_vector_gvsig_02Un ejemplo de como se muestra la opción clamp to ground:

3D_vector_gvsig_03En este caso se puede observar que en varias partes el modelo digital del terreno recubre a la capa vectorial, debido a la diferencia de alturas. Cuando ocurra esto podríamos poner el modo relative to ground y aplicar una altura constante para visualizar los datos sin solapes:

3D_vector_gvsig_04

Extrusión

Se denomina extrusión al proceso de expansión vertical de un elemento 2D para generar un objeto 3D. Permite generar una representación tridimensional a partir de entidades bidimensionales. Un ejemplo típico de extrusión es su aplicación a polígonos de edificios a partir de un atributo de altura, obteniendo formas realistas de edificios. Los tres tipos de geometría básicos -puntos, líneas y polígonos- admiten extrusión.

La interfaz que encontrará el usuario es similar a la siguiente:

xxxLa altitud de los elementos podrá ser definida por cuatro factores: La tercera dimensión o coordenada Z de la geometría. Un campo altura seleccionado de la tabla de atributos. Un parámetro de altura constante. O, por último, un factor de exageración vectorial, el cual es una multiplicación de un determinado factor multiplicado por la altura.

Habrá disponibles 2 modos de elevación, los cuales considerarán la altitud de manera diferente:

  • Absolute: la elevación de los elementos vectoriales estará dada por la altitud, definida como la altura sobre el nivel del mar.
  • Relative to ground: la altitud de los elementos vectoriales estará dada por la altura, definida como la altura relativa sobre el terreno.

Por ejemplo, aplicando la modalidad relative to ground option y seleccionando un campo de la tabla de atributos que se correspondiera a la altura de los edificios, obtendríamos algo así:

3D_vector_gvsig_06

Otros ejemplos

Capa de lineas de curvas de nivel con geometrías 3D, utilizando el modo de extrusión y aplicado una altura adicional de 50 metros:

3D_vector_gvsig_08La misma capa sin extrusión se mostraría del siguiente modo:

3D_vector_gvsig_09Capa de puntos:

3D_vector_gvsig_10Y para acabar un pequeño vídeo:

Posted in gvSIG Desktop, spanish | Tagged , , , , | 1 Comment

Towards gvSIG 2.3: Reproject 2D View into a 3D View

Posted on 20/06/2016 by Giuliano Ramat

In the next coming release of gvSIG 2.3, several improvements (and very striking) related to 3D views will be provided. One of the most important one will be the possibility to reproject a 2D view 3D view.

In gvSIG 2.2 3D Views can be applied only to 2D Views in EPSG: 4326. This constraint will disappear in the next version, and user can work on any projection without limitation in the use of 3D Views.

Here it is the video where this new function is shown:

Posted in english, gvSIG Desktop, testing | Tagged , , | 7 Comments

Counter for identical registers in a field, using Scripting in gvSIG

Posted on 17/06/2016 by Mario

If we have an attribute table in gvSIG we can obtain the number of registers for each different value of a field, how many times they are repeated.

For that we will have to create a new script in gvSIG, from the Tools->Scripting->Scripting Composer menu.

Once it is created, naming it as we want, we copy this source code on it:

from gvsig import *
import commonsdialog
from org.gvsig.andami import Utilities
import os, time

from gvsig import *

from org.gvsig.app.project.documents.table import TableManager

def loadTable(format, **parameters): 

    try:
        application = ApplicationLocator.getManager()
        datamanager =  application.getDataManager()
       
        # Loding the data store
        store_parameters = datamanager.createStoreParameters(format)
        copyToDynObject(parameters, store_parameters)
        store = datamanager.openStore(format, store_parameters)       

        # Creating a Table document and initialize with the data store
        project = currentProject()
        table = project().createDocument(TableManager.TYPENAME)
        table.setStore(store)
        table.setName(store.getName())

        # Add the Table document to the project
        project().addDocument(table)
       
    except Throwable, ex:
        raise RuntimeException("Can't load table, "+ str(ex)) 
 
    return table

def loadDBF(dbffile):
  table = loadTable(format="DBF",DbfFile=dbffile)
  return table

      
def getTempFile(name, ext):
    tempdir = Utilities.TEMPDIRECTORYPATH
    if not os.path.isdir(tempdir):
      os.makedirs(tempdir)
    t = time.time()
    f = os.path.join(
      tempdir,
      "%s-%x%x%s" % (name,t,(t-int(t)) * 10000,ext)
    )
    return f
    
def main(*args):
    print "Count values"
    table = currentTable()
    field = str(commonsdialog.inputbox("Name of the field"))
    try:
        features = table.features()
    except:
        commonsdialog.msgbox("Table not opened")
    count = dict()
    for f in features:
        ff = str(f.get(field))
        if ff in count.keys():
            count[ff] += 1
        else:
            count[ff] = 1
    print count
    sch = createSchema()
    sch.append('ID','STRING',15)
    sch.append('COUNT','INTEGER',20)
    dbf = createDBF(sch, getTempFile("count"+field,".dbf"))
    print type(dbf())
    print "full name: ", dbf.getFullName()
    #Insert table data

    dbf.edit()
    for k,v in count.iteritems():
      f = dbf.createNewFeature()
      f.set('ID',k)
      f.set('COUNT',v)
      dbf.insert(f)

    dbf.commit()

    d = loadDBF( dbf.getFullName())
    print dbf.getFullName()
    return

Finally we save the script.

Then from the View in gvSIG we put the layer that we want to use for the calculation active, and we open its attribute table. After that, we open the Scripting Launcher (Tools->Scripting->Scripting Launcher menu).

Double-clicking on the script that we had created, a new window will be opened, where we have to write the name of the field over which we can apply the counter. After accepting a new table will be created with the results. We will open the Project Manager (from Show menu), and we will have the new table at the “Table” document.

Counter_eng

That table is a temporary element, so we will have to export it to a dbf file in order to have it on disk (Table->Export to menu).

 

 

Posted in development, english, gvSIG Desktop, scripting | Leave a comment

Contar registros iguales en un campo con Scripting en gvSIG

Posted on 17/06/2016 by Mario

Si disponemos de una tabla en gvSIG podemos obtener el número de registros que hay por cada uno de los distintos valores de un campo, la cantidad de veces que se repite cada valor.

Para ello tendremos que crear un nuevo script en gvSIG, desde el menú Herramientas->Scripting->Editor de Scripts (este menú se llama “Scripting Composer” hasta la versión 2.2).

Una vez creado, con el nombre que deseemos, copiamos el siguiente código en él:

from gvsig import *
import commonsdialog
from org.gvsig.andami import Utilities
import os, time

from gvsig import *

from org.gvsig.app.project.documents.table import TableManager

def loadTable(format, **parameters): 

    try:
        application = ApplicationLocator.getManager()
        datamanager =  application.getDataManager()
       
        # Loding the data store
        store_parameters = datamanager.createStoreParameters(format)
        copyToDynObject(parameters, store_parameters)
        store = datamanager.openStore(format, store_parameters)       

        # Creating a Table document and initialize with the data store
        project = currentProject()
        table = project().createDocument(TableManager.TYPENAME)
        table.setStore(store)
        table.setName(store.getName())

        # Add the Table document to the project
        project().addDocument(table)
       
    except Throwable, ex:
        raise RuntimeException("Can't load table, "+ str(ex)) 
 
    return table

def loadDBF(dbffile):
  table = loadTable(format="DBF",DbfFile=dbffile)
  return table

      
def getTempFile(name, ext):
    tempdir = Utilities.TEMPDIRECTORYPATH
    if not os.path.isdir(tempdir):
      os.makedirs(tempdir)
    t = time.time()
    f = os.path.join(
      tempdir,
      "%s-%x%x%s" % (name,t,(t-int(t)) * 10000,ext)
    )
    return f
    
def main(*args):
    print "Count values"
    table = currentTable()
    field = str(commonsdialog.inputbox("Name of the field"))
    try:
        features = table.features()
    except:
        commonsdialog.msgbox("Table not opened")
    count = dict()
    for f in features:
        ff = str(f.get(field))
        if ff in count.keys():
            count[ff] += 1
        else:
            count[ff] = 1
    print count
    sch = createSchema()
    sch.append('ID','STRING',15)
    sch.append('COUNT','INTEGER',20)
    dbf = createDBF(sch, getTempFile("count"+field,".dbf"))
    print type(dbf())
    print "full name: ", dbf.getFullName()
    #Insert table data

    dbf.edit()
    for k,v in count.iteritems():
      f = dbf.createNewFeature()
      f.set('ID',k)
      f.set('COUNT',v)
      dbf.insert(f)

    dbf.commit()

    d = loadDBF( dbf.getFullName())
    print dbf.getFullName()
    return

Después guardamos dicho script.

Ahora ya sobre la Vista de gvSIG, ponemos la capa sobre la que queramos realizar el cálculo activa y abrimos su tabla de atributos. Después abrimos el lanzador de scripts (menú Herramientas->Scripting->Lanzador de Scripts; este menú se llama “Scripting Launcher” hasta la versión 2.2).

Con doble-click sobre el Script que habíamos creado se abrirá una ventana donde podremos escribir el nombre del campo sobre el que queramos realizar el cálculo. Tras aceptar se habrá creado una nueva tabla con los resultados. Iremos al Gestor de proyectos (en el menú Mostrar), y en el documento “Tabla” tendremos la nueva tabla creada.

Counter_esp

Dicha tabla es temporal, por lo que si la queremos mantener podremos exportarla a una tabla dbf en disco (menú Tabla->Exportar a).

 

Posted in development, gvSIG Desktop, scripting, spanish | 1 Comment

Camino a gvSIG 2.3: Datos LiDAR

Posted on 16/06/2016 by Alvaro

En gvSIG 2.3 tendremos acceso a una nueva fuente de datos que cada vez es más utilizada, los datos LiDAR. gvSIG 2.3 proporcionará drivers para leer y escribir LiDAR en gvSIG siguiendo la especificación de LAS. También se proporcionará una herramienta de recorte de datos para exportar un subconjunto de datos LIDAR.

Drivers

El usuario tendrá 2 opciones para trabajar con ficheros LAS, basadas en la implementación en gvSIG de 2 librerías diferentes, cada una de ellas con sus ventajas:

  • El proveedor basado en JGrasstools que es de lectura/escritura.

  • El proveedor basado en Whitebox que es de sólo lectura, pero actualmente ofrece mejor rendimiento que el basado en Jgrasstools.

Lidar_gvSIG_01

Aclarado/simplificación

Ambos drivers incluyen dos parámetros de “aclarado” (simplificación), que permiten leer un subconjunto del total de puntos disponibles en el fichero LAS. El aclarado permite dibujar rápidamente ficheros enormes a pequeñas escalas (en las que no se requiere un nivel de detalle tan elevado como el que provee el fichero):

  • ThinningDivisor: lee 1 de cada n puntos (1/n), por ejemplo thinningDivisor=10 carga el 10% del total de puntos disponibles

  • ThinningResolution: Carga aproximadamente n puntos por unidad cuadrada de la capa; por ejemplo, thinningResolution=0.0001 carga 0.0001 puntos/m2 (asumiendo que las unidades de la proyección de la capa de ejemplo son metros), o lo que es lo mismo, 100 puntos/km²

Atributos

Los ficheros LAS poseen un conjunto de campos obligatorios (fijos) y otros opcionales que dependen de formato de datos de punto que se especifique en la cabecera del fichero LAS.

Los campos obligatorios son:

  • CLASSIFICATION (clasificación de coberturas del suelo)
  • POINTX (coordenada x del punto)
  • POINTY (coordenada y del punto)
  • POINTZ (coordenada z del punto, útil para simbolizar elevaciones del terreno)
  • INTENSITY (intensidad)
  • RETURNNUM (número de retorno del punto)
  • NUMBEROFRETURNS (número de retornos para este pulso láser)

Los campos opcionales son:

  • COLOR (color del punto, expresado como un entero “long” de Java que contiene el valor RGB)
  • TIME (tiempo absoluto de captura, expresado tal como genera Data.getTime())
  • WEEKTIME (tiempo relativo de captura, expresado como tiempo GPS semanal)

Lidar_gvSIG_02

Herramienta de exportación

La herramienta de recorte permite elegir un subconjunto de los datos para exportarlo a un nuevo fichero LAS.

Lidar_gvSIG_03

La herramienta permite elegir una extensión geométrica para filtrar los datos (sólo se exportarán los puntos que estén comprendidos en la extensión geométrica seleccionada). Las opciones posibles son:

  • No realizar un filtrado por extensión geométrica.

  • Filtrar los datos usando la extensión visible en la vista activa.

  • Filtrar usando una extensión geométrica especificada por el usuario.

LiDAR_gvSIG_04

Es importante remarcar que si hemos cargado la capa en la vista usando las opciones de “aclarado” (simplificación) de datos, la herramienta de exportación respetará estas opciones, con lo cual se exportará la versión simplificada de los datos.

Y para acabar os dejamos con un par de vídeos relacionados con la carga de datos LiDAR en gvSIG:

Posted in gvSIG Desktop, spanish | Tagged , , | 3 Comments

Camino a gvSIG 2.3: Reproyectar Vistas 2D a Vistas 3D

Posted on 10/06/2016 by Alvaro

En la próxima versión de gvSIG 2.3 vamos a tener varias mejoras (y muy llamativas) relacionadas con las Vistas 3D. Una de las fundamentales es la capacidad de reproyectar una Vista 2D a una Vista 3D.

En gvSIG 2.2 sólo podemos aplicar Vistas 3D a Vistas 2D con EPSG: 4326. Esto cambiará en la próxima versión, y el usuario podrá trabajar en cualquier proyección sin que eso impida poder utilizar las Vistas 3D.

Os dejamos con un vídeo en que mostramos esta nueva funcionalidad:

Posted in gvSIG Desktop, spanish | Tagged , , , | 4 Comments

From Aaron Swartz to the access to the free scientific knowledge

Posted on 07/06/2016 by mjlobato76

001

In Europe we are very grateful because the ministers of Competitiveness of the European Union (EU)gave recently their support to all European articles, publicly funded or public-private are accessible free of charge for 2020. Thus, the member states of the European Union want to ensure that the knowledge generated by our scientists can be reused. It is proposed that European scientists should not be judged by the number of produced publications but by the social impact of their work. .

The first thing that came up when we read the new, it is the potential great economic profit linked to the scientific progress.

If citizens invest a portion of our taxes to train technicians, scientists and intellectuals, it would be stupid that the fruit of their labor, it was not available for their financial supporters, for the society. Anyone would not conceal the knowledge generated by our scientists to the rest of our scientists and this way, slowing the natural progress of science itself, based on the sum of efforts. Something that perfectly sums up the famous quote of Isaac Newton ” If I have seen further it is by standing on the shoulders of Giants.”

We congratulate ourselves and , on the other hand, we should think about the long road that we still have to walk in. Let´s think in the amount of money (millions and millions of euros) spent by our administrations in privative software. Knowledge not accessible for us. Let´s imagine the technological growth that would cause a measure announced such as the one applied to the software´s world. Hopefully, the time will come when we can finally announce that the European Union definitely commits to free software, and it will stop spending on licenses to invest in knowledge. Scientific knowledge, also at the level of software, can be reused.

It is a great moment to remember the sadly deceased Aaron Swartz. If we can congratulate ourselves today for this new is thanks to people like Aaron, who decided to face the perverse logic that knowledge should not be freely accessible.

Source: http://english.eu2016.nl/latest/news/2016/05/27/all-european-scientific-articles-to-be-freely-accessible-by-2020

Posted in english, opinion | Leave a comment

Accediendo a un Feature por posición en gvSIG desktop 2.3.0.

Posted on 04/06/2016 by Joaquin del Cerro

Hola a todos.
Una pregunta que suelen hacer los desarrolladores que habiendo desarrollado aplicaciones para gvSIG 1 pasan a desarrollar con gvSIG 2 es…

¿ como puedo  obtener una feature concreta por posición ?

Es una operación que se realizaba habitualmente en gvSIG 1.
La respuesta rápida es que no se puede. Dicho esto comentaré algunas opciones para rodearlo.

El API de acceso a datos de gvSIG 2 esta pensado para que se acceda de forma óptima tanto a fuentes de datos locales, como pueda ser un shape, como a remotas, entre las que hemos dedicado una especial atención el acceso a BBDD relacionales. Acceder por posición a una feature de un shape es relativamente simple y eficiente. De hecho, es posiblemente el acceso natural al shape. Apenas tiene coste. Sin embargo, cuando estamos accediendo a una tabla de una BBDD relacional, el acceso por posición, además de no ser nada eficiente, puede que no nos dé los resultados que deseamos. Cuando intentemos recuperar features de una BBDD, suponiendo que está correctamente configurado el servidor, el coste más alto solemos encontrarlo en la latencia de la red, pudiendo estar incluso alrededor del segundo el coste de recuperar una feature, y costando lo mismo recuperar una que mil. Como el API de acceso a datos de gvSIG es el mismo independientemente de la fuente de datos a la que se este accediendo, la decisión que se tomó en su diseño fue ofrecer un API que pudiese usarse tanto para fuentes de datos locales, como el shape, como remotas, como una BBDD, eliminándose la funcionalidad de acceso aleatorio de este.

Dicho así, tan rotundamente, no es del todo cierto. El API incluye una forma de acceso aleatorio, que no por posición. Podemos obtener de una Feature su FeatureReference para más tarde poder volver a recuperar la Feature entera. Esta recuperación posterior de la Feature provocará un acceso a la fuente de datos para hacerlo, así que deberíamos tener cuidado con el uso de esta funcionalidad. Además, la FeatureReference implementa el interface Persistent, lo que nos permite almacenar referencias a features en la persistencia del proyecto o del plugin de forma transparente.

Otra forma de acceso aleatorio sobre una fuente de datos es indicando el parámetro posición al método fastiterator, pero tenemos que tener en cuenta que si la fuente de datos no soporta esa operación se iteraría desde el principio de esta saltando las features previas hasta llegar a la posición indicada. Por suerte, el proveedor de datos de PostgreSQL funcione correctamente a la hora de realizar esta operación.

De todos modos, estas dos operaciones no son lo mas adecuado para acceder por posición a una Feature.

Incluido en el API de acceso a datos se encuentra otra una utilidad que nos permite paginar los datos y acceder a ellos por posición de forma transparente. Dependiendo del tamaño de página que indiquemos y el tipo de explotación que queramos hacer de los datos puede ser una opción aceptable. Evidentemente, para recuperar una sola feature por posición, no es lo aconsejable. Se trata del FeaturePagingHelper. para crear uno de ellos a partir de un FeatureStore se haría con:

...
DataManager manager = DALLocator.getDataManager();
FeaturePagingHelper featurePager = manager.createFeaturePagingHelper(featureStore, query, pageSize);
...

Donde le indicaríamos el FeatureStore sobre el que queremos crear el FeaturePagingHelper, un FetureQuery, que puede ser null si queremos recuperar todas las features sin filtrado, y el tamaño de página que queremos usar.

El FeaturePagingHelper tiene métodos como:

Feature getFeatureAt(long index)

Que nos permite recuperar una Feature por posición, o un:

long getTotalSize()

Que nos permite obtener el número de features totales.
De todos modos el método mas interesante probablemente sea:

List<Feature> asList()

Que nos devuelve un adaptador a List de features basado en el FeaturePagingHelper. Eso nos permite acceder a las features de un FeatureStore como si se tratase de una lista standard de java, funcionando de forma transparente no importa de cual sea la fuente de datos. En gvSIG esto es usando en el documento Tabla y tiene unos rendimientos aceptable.

Bueno, he comentado como podéis rodear el problema del acceso por posición a las Features de un FeatureStore, ahora toca la recomendación. Siempre que sea posible utilizar los iteradores o visitors sobre los FeatureSet. En gvSIG, usar iteradores y visitors es lo más eficiente. Si estáis migrando código a gvSIG y os encontráis algoritmos que se basan en el acceso aleatorio a la fuente de datos, en lugar de intentar migrar el código tal cual, intentad sustituir el algoritmo basado en acceso aleatorio por otro basado en iterar sobre los datos.

Como siempre, espero que os sea de utilidad.

Un saludo a todos.
Joaquin

Posted in gvSIG Desktop | Leave a comment