Introducción

gvSIG permite trabajar con múltiples y diferentes tipos de capas, de manera que cada una, según su naturaleza, tiene unas propiedades y comportamiento que no tienen porqué coincidir con las de otro tipo. En cambio, todas las capas, al menos teóricamente, pueden estar en un reducido número de estados simultáneos. A cada conjunto posible de estados simultáneos se les denomina estatus.

A nivel genérico, el estatus de una capa está definido en la clase FLayerStatus del proyecto libFMap, como se observa en el diagrama 1.

Así, se observa como la clase abstracta con la implementación común para todas las capas, FLyrDefault, contiene y utiliza una instancia de tipo FLayerStatus que representa el estatus actual en que puede estar cualquier tipo de capa.

En la práctica, una capa dada solo podrá estar en un subconjunto de los posibles estatus, teniendo en cuenta su naturaleza.

Diagrama de clases que muestra la relación de FLayerStatus con las capas de libFMap.

El estatus de una capa almacena la información de las excepciones que se puedan ir produciendo cuando se utiliza el driver asociado a ella, este tipo de excepción es DriverException.

Capturas

En este apartado se han colocado unos ejemplos visuales con los que un usuario podría conocer el estado de la capa/s con la que está trabajando en gvSIG:

El usuario tiene esta vista en gvSIG con las capas WFS "embalses" e "hidrografía" en el TOC, visibles ("checkboxs" seleccionados), disponibles (dado que sino no se habrían visualizado sus datos), y estando la capa "embalses" activa.

Igual a la imagen anterior, pero ahora ambas capas están activas (seleccionadas).

Ahora, el usuario ha deseleccionado los "checkbox's" de ambas capas, y, por tanto, no están visibles. Por otro lado, la capa "hidrografía" está activa, y ambas se mantienen disponibles dado que no se nos informa de lo contrario en el icono asociado.

Visible sólo la capa "embalses", y activa sólo "hidrografía".

El usuario ha creado una vista en gvSIG en la que sólo ha cargado una capa (1 capa en TOC), que está activa, pero no disponible (lo indica el aspa roja del icono de la izquierda asociado a la capa). Dado que la capa no está disponible, deja de estar visible.

Cuadro de diálogo que aparece cuando se intenta editar una capa que no tiene permiso de escritura.

El usuario ha intentado cargar una capa en una vista de gvSIG, pero se han producido errores y por tanto deja de estar disponible.

Capa cargada en TOC, disponible, visible, activa, con permiso de escritura, y en edición.

Introducción

Toda capa utilizada en gvSIG hereda de la clase FlyrDefault, que implementa la declaración genérica y común de capa: el interfaz FLayer .

FlyrDefault, es una clase abstracta, con métodos genéricos para trabajar con capas definidos en la interfaz FLayer, métodos genéricos para trabajar con drivers (para utilizar la capa), definidos en la interfaz Driver, y otros métodos propios.

FLayer, incluye los métodos necesarios para trabajar con proyecciones, definidos en la interfaz Projected, con otros para trabajar con capas.

Por otro lado, es posible tener una colección de capas como nodo de un árbol de capas, y así poder trabajar con distintos niveles. Para ello, se definió la clase FLayers, que hereda de FlyrDefault, e implementa la interfaz LayerCollection con los métodos para trabajar con un conjunto de capas.

Dado que las capas de un mismo nodo pueden ser de distinto tipo, FLayers implementa, por compatibilidad, las interfaces InfoByPoint y VectorialData. Así, es posible que algunas capas trabajen con datos vectoriales, por ello se implementa la interfaz VectorialData; y/o a la vez es posible que soporten la operación de obtención de información a partir de un punto, por ello se implementa la interfaz InfoByPoint.

El siguiente diagrama muestra gráficamente lo explicado, sin entrar en detalles acerca de métodos ni atributos, pero sí listeners que se pueden asociar a una capa, con los correspondientes eventos que pueden recibir, y los tipos de excepciones que se pueden llegar a lanzar en caso de producirse algún error trabajando con una capa:

Diagrama 1: relación entre las clases e interfaces del grupo Layers.

Descripción y funcionalidad

Enlaces relacionados

• En este enlace se muestran unas capturas de gvSIG con las que un usuario puede conocer el estatus de una capa.
• Este otro enlace es una recopilación de los tipos de capas que se utilizan en gvSIG, o en proyectos relacionados, con una explicación de cada una.
• Visitor: información de este tipo de patrón software.

Pintado

gvSIG pinta usando el patrón "SingleWorketThread".

Las peticiones de dibujado se encolan y se envían a un único thread que lanza el dibujado con un objeto de tipo Cancellable para permitir interrumpir ese dibujado.

El thread de pintado va recibiendo comandos de pintado e inmediatamente se pone a pintar en segundo plano sobre una imagen en memoria. Frecuentemente, y para observar el progreso (porque puede llegar a tardar varios segundos en terminarlo) MapContext renderiza esa imagen y se muestra en pantalla. Esto es cada 400 milisegundos (y a partir de v1.2 será configurable de manera que se puede ver el progreso en tiempo real) y en el momento en que el thread ha terminado de pintar.

El dibujado de las capas lo hace MapContext. MapContext puede pintar sobre un Graphics2D que provenga de una imagen (caso de las peticiones del MapControl) o sobre un Graphics2D que venga de otro sitio (por ejemplo al imprimir). MapContext tiene una colección FLayers, y cada capa tiene un método draw. Para terminar, existe un "StrategyManager" que, en función del tipo de capa, escoge una estrategia de pintado u otra (patrón "Strategy"). Las estrategias de pintado están en el paquete "operations", dentro de libFMap, y las más interesantes son ShpStrategy y DBStrategy.

Por otra parte, si se observa el interfaz de las capas (FLayers) se verá que el método draw (que dibuja cada capa) tiene un argumento Cancellable que tiene un método isCanceled(). Cuando se ha cancelado el pintado (sea por un zoom, un pan o cualquier otro evento que comporte que lo que hay actualmente ya no es válido y debe de recalcularse) entonces isCanceled() devuelve true. En cualquier otro caso devuelve false.

La agilización de la cancelación se realiza dentro de cada una de las iteraciones que se hace en el método draw y posteriores llamadas internas, comprobando que isCanceled() es true, y si lo es, se aborta todo el proceso y entonces se sale del método del draw, si no lo es, se continua con el renderizando. Si se cancela el pintado de todas las capas de manera encadenada, la petición de draw del MapContext se termina, haciendo que se atienda a la siguiente (la que ha provocado que Mapcontext se invalide y que cancel.isCanceled() devuelva true).

Que el cancelado sea inmediato o no, depende del tipo de capas y de la implementación del método draw de ellas. La mayor parte de las capas tienen en cuenta el Cancelable, pero hay algunas que no lo pueden comprobar e inevitablemente ejecutan su método draw íntegro aunque el resultado no se llegue a mostrar en pantalla.

Escritura de una capa

El método isWritable() de una capa devuelve true si el driver en el que se apoya la capa devuelve true:

• Para el caso vectorial:

public boolean isWritable() {
  VectorialDriver drv = getSource().getDriver();

  if (!drv.isWritable())
    return false;

  // VectorialEditableAdapter vea = (VectorialEditableAdapter) lyrVect
  // .getSource();
  if (drv instanceof IWriteable)
  {
    IWriter writer = ((IWriteable)drv).getWriter();
    if (writer != null)
    {
      if (writer instanceof ISpatialWriter)
        return true;
    }
  }
  return false;
}

• Para el caso de los shape: devuelve true si el fichero tiene permiso de escritura. El resto (instanceof IWriteable) es por si tenemos solo capas con driver de lectura. Si el driver implementa la escritura, se podrá editar y guardar la capa en ese formato. Si no, la capa se puede poner en edición, pero no se puede salvar a ese formato, solo se puede guardar como .

Enlaces relacionados

• Strategy : explicación detallada en inglés acerca de este patrón sofware.
• WorkerThreadPattern : código Java con un ejemplo donde se implementa este patrón software.
• Painting in AWT and Swing : descripción detallada en inglés de los mecanismos y filosofía de pintado de la biblioteca Swing y el kit de herramientas AWT en Java.
• Pintando en AWT : descripción detallada en castellano de los mecanismos y filosofía de pintado en Java con la biblioteca AWT.
• Pintando en Swing : descripción detallada en castellano de los mecanismos y filosofía de pintado en Java con la biblioteca Swing.