- No se debe hacer un QueryByPoint con visitor, sería mejor pornerlo
  en FLyrVect, con un interfaz como el que tiene la capa de WMS (InfoByPoint)
  De esta forma, además de ser más claro, las capas "inteligentes"
  como las de base de datos, podrán hacer la consulta por SQL, y
  no hará falta recuperar todas las entidades. El mecanismo que 
  hay ahora de visitors recorre todos los registros de una capa, y
  eso no es aceptable para las capas que tienen que leer sus 
  geometries de manera remota.

- v03: Para los símbolos. Cada símbolo sigue el patrón Composite,
  y habrá un ComplexSymbol que tendrá un símbolo para cada
  tipo de entidad: Un símbolo para puntos, otro para líneas, 
  otro para polígonos y otro para textos.

- v03: Revisar el sistema de Reproyección al vuelo. Demasiado lento,
  se puede mejorar, pero es posible que sea mejor no hacerlo y 
  crear un shape reprojectado cada vez => ¿Y si es un DGN, qué escribimos?
  => Nuestro formato shp modificado es una opción => Definir nuestro
  shp modificado. (Que admita textos, mezcla de tipos de entidades, etc)

- Cuando se abre el cuadro de diálogo de leyenda, cargar bien
  los datos del símbolo actual.

- Internacionalizar los strings.

- Corregir la pantalla de inicio, y hacer un cuadro de diálogo "About"

- Habilitar el fileChooser que usa la aplicación mdi para que permita
  devolver un array de Files (File[]), y abrirlo para que pueda seleccionar
  varios ficheros a la vez.

- Algunos arcos no se dibujan bien en los dgn. Meter lo del libro de java.

- Hay que completar el soporte de shape file. Ahora mismo no acepta multipunto, ni shapes 3D
  ni escritura.

- Página 75, último párrafo del libro de software libre:
"Las condiciones y/o restricciones que imponen las licencias sólo pueden
ser precisadas por los propios autores, que según la normativa de propiedad
intelectual son los propietarios de la obra. En cualquier caso, la
propiedad de la obra será de los autores, ya que la licencia no supone
transferencia de propiedad, sino solamente derecho de uso y, en algunos
casos, de distribución."
"...también es necesario saber
que cada nueva versión de un programa es considerada como una nueva
obra. El autor tiene, otra vez, plena potestad para hacer con su obra
lo que le apetezca, incluso distribuirla con términos y condiciones totalmente
diferentes (o sea, una licencia diferente a la anterior). Así, si el lector
es autor único de un programa podrá publicar una versión bajo una
licencia de software libre y, si le apeteciere, otra posterior bajo una licencia
propietaria. En caso de existir más autores, y que la nueva versión
contenga código cuya autoría les corresponda y que se vaya a publicar
bajo otras condiciones, todos ellos han de dar el visto bueno al cambio
de licencia." 

- Consideraciones sobre modelo de negocio para el software libre:
	· En realidad hacemos lo mismo que ahora, solo que la licencia de MapObjects y ArcView ya
	no existe. En lugar de que se la lleve Esri, no se la lleva nadie. A nosotros no nos deja
	en peor lugar que ahora, en todo caso mejor: Se puede dar formación sobre nuestra herramienta
	a otros desarrolladores, e incluso cobrarles por una Certificación en el uso de nuestras
	librerías.
	· Los servicios se dividen en 2: Soporte técnico para usuarios del programa básico y/o 
	funcionalidades nuevas que se hayan desarrollado para un cliente y Proyectos en los que
	se necesite programar nuevas funcionalidades o integrar el programa con otras aplicaciones
	del cliente final.
	· Con el CIT se debería firmar un contrato de mantenimiento especial (que se vean favorecidos
	respecto al resto de clientes, pero que no deje de ser una entrada fija de dinero a IVER).
	· Es posible que exista financiación de Europa para proyectos de este tipo. Ya no solo en
	el desarrollo, que no creo que sea mucho lo que se pueda sacar, sino en proyectos de 
	implantación y soporte a gran escala (a partir de la Comunidad Valenciana, por ejemplo).

- Sugerencia de Felipe: Ojo con copiar demasiado al ArcView, porque nos pueden meter puros
  legales los de ESRI (aunque no los ganen, nos pueden putear). (Diseño de los formularios).

- Pasar los cuadros de diálogo más usuados (leyendas y abrir capas al FMap, y utilizar unos
  derivados dentro de GVSIG.

- ¿Se puede utilizar los datasources de GT2?. Derivar de ellos para que entreguen entidades
  de las nuestras además de las de JTS.

- La ventana de asignación de leyendas no debe depender del TOC. Se debe abrir con un layer
  para inicializar como máximo, y fuera de la ventana que se asigne su leyenda a los temas
  activos.
  
- Sería una buena idea eliminar la dependencia de las capas con el FMap que las contiene. De
  esta forma, una misma capa podría estar en 2 MapControls a la vez, y supongo que nos
  evitaríamos problemas cuando tengamos un "pool" de capas abierta.

- Cambiar el sistema de símbolos por los Style2D de Geotools.

- Revisar el FLyrVect. Puede no estar basado en un fichero (capa en memoria, FLyrWFS, etc),
  así que habrá que quitar el m_Path. Y si permitimos capas mixtas, quitar el
  m_shapeType.

- Cambiar el bitmap (boolean []) por una clase BitSet.

- Quitar m_legendValues y m_labelValues de FLyrVect como Object [] y String []
  y ponerlos como ArrayList para que FLyrMem no tenga que pedir un Object[] cada
  vez que le hacen un addShape.

- ¿Merece la pena poner el dgn y el dxf como un grupo de layers?
	· Se podría permitir capas mixtas, con textos, puntos, lineas y polígonos.
	  (Distinguir LAYER_TYPE de SHAPE_TYPE). Y en lugar de funcionar con tipos, es
	  probable que sea mejor funcionar con clases distintas y jerarquía, usando
	  "instanceof"
	 
	· En el TOC aparecerían con un símbolo compuesto.
	· El FLegendManagerWindow no mostraría solo la posibilidad de cambiar un símbolo
	  de líneas sino algo como ArcView (puedes fijar un símbolo de polígono para una 
	  capa e líneas, aunque no se pinte.
	  
- En lugar de meter el DGN y el DXF en memoria, hacer una librería que permita ir
  cargando del disco duro.
  
- Mantener un "pool" con las capas abiertas, de forma que si trabajamos en memoria, 
  no haga falta consumir memoria para 2 capas iguales. Las 2 capas deben apuntar a 
  los mismos datos en memoria.
  
- Sustituir FRecordset por el interfaz TableModel. Es más simple, y es nativo de Java.

- Capa DWG.

- Implementar el resto de tipo de Shape en nuestro lector de shapes. ¿Usar otro (GT2)?

- Mejorar la velocidad del lector de DBF.

- Meter en FLyrMemory un DefaultTableModel y guardar ahí los atributos que deseemos.

- Atributos de DGN que vamos a mostrar por ahora:
	· Entity => Line String, Shape, Cell, Point
	· Layer (= Level)
	· Color
	· Elevation
	· LineTypeId
	· LineWidth
	· Text
	
- Atributos de DXF que vamos a mostrar por ahora:
	· Entity => Line, Polyline, Insert, Point
	· Layer
	· Color
	· Elevation
	· LineTypeId
	· LineWidth
	· Text