NOTA: en d:\java\reserva he dejado las pruebas de uso directo de las entidades JTS y LiteShape

ANÁLISIS STYLING (LEYENDAS)

1.- Objetivos (Requisitos)

Objetivo principal:

PERMITIR QUE EN gvSIG SE PUEDA UTILIZAR CUALQUIER TIPO DE SÍMBOLO

Haremos una implementación de los símbolos más habituales. Con "cualquier símbolo" me refiero a que dejaremos una puerta abierta para que un desarrollador implemente su propio símbolo especial.

Los símbolos más habituales:

  1. Para puntos
  2. Para Líneas
  3. Para Polígonos
  4. Para Etiquetas
Objetivos secundarios (algunos de ellos puede que los obviemos o postpongamos el desarrollo para cuando haya tiempo. Por ejemplo, la compatibilidad con SLD es discutible, ya que ahora mismo da la impresión de que ningún servidor soporta SLD con garantías => No se puede probar bien):

2.- Antecedentes.

En FMap existe un sistema de leyendas orientado a acceso aleatorio y (en principio) una serie de leyendas basadas en un campo.

En SLD, se puede utilizar una leyenda con acceso secuencial, fijar un símbolo en base a cualquier combinación de campos y/o relaciones geométricas (Filtros).

FMap se puede ir ampliando con leyendas de todo tipo, pero al estudiar cómo lo hace SLD, creo que podemos hacer algo parecido y mejorar algunas carencias.

A su vez, el SLD también tiene una serie de limitaciones. A saber:

- No está definida la posibilidad de fijar un tamaño de símbolo en coordenadas de mundo real. Esto es imprescindible para símbolos de tipo puntual y para etiquetas.

- La forma de aplicar los símbolos es lenta (se tiene que recorrer todos los símbolos, evaluando uno a uno sus condiciones para ver si se aplican o no.

- No permite la agrupación de símbolos para formar uno complejo. Se puede conseguir el efecto poniendo tantos símbolos como se quiera, pero entonces el usuario, para editar el símbolo tiene que editar cada uno de los símbolos que lo forman (tanto a nivel gráfico como sus filtros). Esto afecta a la hora de interactuar con el usuario.

3.- Aspectos a tener en cuenta (Funcionalidades):

Un directorio con símbolos predefinidos (para puntos, líneas, polígonos y textos).

Si no se encuentra la imágen que tenemos que emplear con el símbolo, lanzar una excepción de tipo "File not found", con el nombre del fichero que se busca.

Para evaluar si un símbolo se aplica o no, se puede emplear el mecanismo de Filtros definido en geoAPI. Un filtro toma una Feature (Geometría + atributos), la evalúa y si es cierta la condición, llama al dibujado, si no, no. Esto lo que permite es que podamos asignar un símbolo en base a criterios de todo tipo (basado en el valor de un campo, en los valores de 2 campos o más, en un criterio espacial (por ejemplo, poner un símbolo a todos los polígonos que contengan un punto, o que su perímetro sea mayor que X).

El interfaz con el usuario es importantísimo. Un usuario debe poder definir el símbolo con facilidad, tanto su parte gráfica como la parte de filtro, aquella que vamos a usar para definir si un símbolo se ha de aplicar a una feature o no.

El usuario ha de poder escoger entre los símbolos predefinidos por nosotros y los que pueda definir otro plugin. (Un símbolo se definirá por un archivo dentro del directorio de símbolos, o por una clase que implemente el interfaz IFSymbol. Estas clases se podrán registrar de forma parecida al mecanismo actual de drivers). Para que un usuario pueda especificar las características de estos nuevos símbolos, deberemos implementar un mecanismo que le permita al desarrollador especificar qué panel va asociado con qué símbolo.

Lo mismo pasa con los filtros. Nosotros implementaremos los más comunes, pero dejaremos la puerta abierta al resto.

Para mostrar los símbolos de una capa mixta, en lugar de mostrarlos todos en la misma línea (dibujar un rectángulo, línea, punto y texto), los vamos a dibujar cada uno con su línea, y solo si existen. Es decir, si hemos definido una leyenda sobre un tema de DXF, pondremos un icono en el tema que indica que es mixto, y unos símbolos por defecto para polígonos, líneas, puntos y texto, uno debajo del otro. Si definimos algún símbolo más a la leyenda, aparecerá encima de los que son por defecto. Si modificamos la leyenda por defecto quitando alguno de esos símbolos, ya no aparecerán en el TOC o la leyenda del Layout, o donde toque.

También daremos la posibilidad de "habilitar/deshabilitar" (o visíble/invisible) un símbolo pinchando sobre el símbolo en el TOC. Esto es muy útil porque cuando quieres ver solo un determinado tipo de entidades, las puedes poner invisibles sin tocar la leyenda, y puedes volver a la leyenda habitual fácilmente, sin tener que recargar una leyenda o fijar colores, tipos de línea, etc. La idea es, por ejemplo, mostar la descripción del símbolo en gris, o tachado en el TOC. O con un icono de ojo abierto/cerrrado, como lo hace Flash. En el Layout, ponerlo como si no estuviera. Esta funcionalidad no es prioritaria, desarrollarla al final, pero tenerla en cuenta en el diseño.

El usuario podrá tener una serie de símbolos "favoritos", o que use con más frecuencia. Tampoco es prioritario. Desarrollarlo al final, o guardar estas tareas para algún becario o colaborador que quiera empezar.