svn-gvsig-desktop / branches / Fmap_GisPlanet / libraries / libFMap / docs / Analisis_Styling.html @ 1841
History | View | Annotate | Download (7.93 KB)
1 |
<style type="text/css"> |
---|---|
2 |
<!--
|
3 |
.textoNormal {
|
4 |
font-family: Arial, Helvetica, sans-serif;
|
5 |
}
|
6 |
-->
|
7 |
</style>
|
8 |
<body class="textoNormal"> |
9 |
<h2><strong>ANÁLISIS STYLING (LEYENDAS)</strong></h2> |
10 |
<h3>1.- Objetivos (Requisitos)</h3> |
11 |
<p>Objetivo principal:</p> |
12 |
<p> <strong> PERMITIR QUE EN gvSIG SE PUEDA UTILIZAR CUALQUIER TIPO DE S?MBOLO</strong></strong></p> |
13 |
<p>Haremos una implementación de los símbolos más habituales. |
14 |
Con "cualquier símbolo" me refiero a que dejaremos una puerta |
15 |
abierta para que un desarrollador implemente su propio símbolo especial.</p> |
16 |
<p>Los símbolos más habituales:</p> |
17 |
<ol>
|
18 |
<li>Para puntos</li> |
19 |
<ul>
|
20 |
<li>Círculo, cuadrado, triángulo, cruz, icono + tamaños |
21 |
y colores</li>
|
22 |
</ul>
|
23 |
<li>Para L?neas</li> |
24 |
<ul>
|
25 |
<li>Contínua, raya-raya, raya-punto-raya, raya-punto-punto-raya, raya-cruz-raya |
26 |
+ grosores y colores.</li>
|
27 |
</ul>
|
28 |
<li>Para Polígonos</li> |
29 |
<ul>
|
30 |
<li>Relleno uniforme, sin relleno, tramado a 45º, a -45º, horizontal, |
31 |
vertical, tramado con fondo, gradiente, con bitmap + grosores aplicados |
32 |
al contorno y colores aplicados al tramado y al contorno.</li>
|
33 |
</ul>
|
34 |
<li>Para Etiquetas</li> |
35 |
<ul>
|
36 |
<li>Se podrá fijar la fuente, el tamaño de la fuente (en pixels |
37 |
o coordenadas de mapa), la posición relativa de la etiqueta, si lleva
|
38 |
halo o no, la inclinación, además de distinguir entre lo necesario |
39 |
para etiquetar un punto, línea o polígono (ver ArcMap).</li> |
40 |
</ul>
|
41 |
|
42 |
</ol>
|
43 |
|
44 |
Objetivos secundarios (algunos de ellos puede que los obviemos o postpongamos |
45 |
el desarrollo para cuando haya tiempo. Por ejemplo, la compatibilidad con SLD |
46 |
es discutible, ya que ahora mismo da la impresión de que ningún |
47 |
servidor soporta SLD con garantías => No se puede probar bien): |
48 |
<ul>
|
49 |
<li>Guardar un símbolo definido por el usuario.</li> |
50 |
<li>Definir símbolos compuestos de otros símbolos.</li> |
51 |
<li>Permitir que un desarrollador cree su propio símbolo, con comportamiento |
52 |
especial de dibujado (se trata de soportar lo que tiene MapObjects, de que |
53 |
te puedas hacer tú (como desarrollador) tus propios símbolos. |
54 |
Por ejemplo, para pintar una línea con una sinusoidal + cruces).</li> |
55 |
<li>Compatible con SLD => La leyenda de este tipo se tiene que poder escribir |
56 |
en SLD, y viceversa, un fichero SLD tiene que poder transformarse a esta leyenda.</li>
|
57 |
<li>Que sea aplicable a capas de acceso de tipo secuencial, por si hace falta
|
58 |
tener capas de este estilo.</li>
|
59 |
<li>Que se pueda guardar como leyenda, para poder ser recuperada con posterioridad,
|
60 |
tanto fuera como dentro del fichero de proyecto.</li>
|
61 |
</ul>
|
62 |
<h3>2.- Antecedentes.</h3> |
63 |
<p>En FMap existe un sistema de leyendas orientado a acceso aleatorio y (en principio)
|
64 |
una serie de leyendas basadas en un campo.</p>
|
65 |
<p>En SLD, se puede utilizar una leyenda con acceso secuencial, fijar un símbolo |
66 |
en base a cualquier combinación de campos y/o relaciones geométricas |
67 |
(Filtros).</p>
|
68 |
<p>FMap se puede ir ampliando con leyendas de todo tipo, pero al estudiar cómo |
69 |
lo hace SLD, creo que podemos hacer algo parecido y mejorar algunas carencias.</p>
|
70 |
<p>A su vez, el SLD también tiene una serie de limitaciones. A saber:</p> |
71 |
<p>- No está definida la posibilidad de fijar un tamaño de símbolo |
72 |
en coordenadas de mundo real. Esto es imprescindible para símbolos de
|
73 |
tipo puntual y para etiquetas.</p>
|
74 |
<p>- La forma de aplicar los símbolos es lenta (se tiene que recorrer todos |
75 |
los símbolos, evaluando uno a uno sus condiciones para ver si se aplican
|
76 |
o no.</p>
|
77 |
<p>- No permite la agrupación de símbolos para formar uno complejo. |
78 |
Se puede conseguir el efecto poniendo tantos símbolos como se quiera,
|
79 |
pero entonces el usuario, para editar el símbolo tiene que editar cada
|
80 |
uno de los símbolos que lo forman (tanto a nivel gráfico como |
81 |
sus filtros). Esto afecta a la hora de interactuar con el usuario.</p>
|
82 |
<h3>3.- Aspectos a tener en cuenta (Funcionalidades):</h3> |
83 |
<p> Un directorio con símbolos predefinidos (para puntos, líneas, |
84 |
polígonos y textos).</p> |
85 |
<p>Si no se encuentra la imágen que tenemos que emplear con el símbolo, |
86 |
lanzar una excepción de tipo "File not found", con el nombre |
87 |
del fichero que se busca.</p>
|
88 |
<p>Para evaluar si un símbolo se aplica o no, se puede emplear el mecanismo |
89 |
de Filtros definido en geoAPI. Un filtro toma una Feature (Geometría
|
90 |
+ atributos), la evalúa y si es cierta la condición, llama al |
91 |
dibujado, si no, no. Esto lo que permite es que podamos asignar un símbolo
|
92 |
en base a criterios de todo tipo (basado en el valor de un campo, en los valores |
93 |
de 2 campos o más, en un criterio espacial (por ejemplo, poner un símbolo |
94 |
a todos los polígonos que contengan un punto, o que su perímetro |
95 |
sea mayor que X).</p>
|
96 |
<p>El interfaz con el usuario es importantísimo. Un usuario debe poder |
97 |
definir el símbolo con facilidad, tanto su parte gráfica como |
98 |
la parte de filtro, aquella que vamos a usar para definir si un símbolo
|
99 |
se ha de aplicar a una feature o no.</p>
|
100 |
<p>El usuario ha de poder escoger entre los símbolos predefinidos por nosotros |
101 |
y los que pueda definir otro plugin. (Un símbolo se definirá por |
102 |
un archivo dentro del directorio de símbolos, o por una clase que implemente
|
103 |
el interfaz IFSymbol. Estas clases se podrán registrar de forma parecida
|
104 |
al mecanismo actual de drivers). Para que un usuario pueda especificar las características
|
105 |
de estos nuevos símbolos, deberemos implementar un mecanismo que le permita
|
106 |
al desarrollador especificar qué panel va asociado con qué símbolo.</p> |
107 |
<p>Lo mismo pasa con los filtros. Nosotros implementaremos los más comunes, |
108 |
pero dejaremos la puerta abierta al resto.</p>
|
109 |
<p>Para mostrar los símbolos de una capa mixta, en lugar de mostrarlos |
110 |
todos en la misma línea (dibujar un rectángulo, línea, |
111 |
punto y texto), los vamos a dibujar cada uno con su línea, y solo si
|
112 |
existen. Es decir, si hemos definido una leyenda sobre un tema de DXF, pondremos |
113 |
un icono en el tema que indica que es mixto, y unos símbolos por defecto
|
114 |
para polígonos, líneas, puntos y texto, uno debajo del otro. Si |
115 |
definimos algún símbolo más a la leyenda, aparecerá |
116 |
encima de los que son por defecto. Si modificamos la leyenda por defecto quitando |
117 |
alguno de esos símbolos, ya no aparecerán en el TOC o la leyenda |
118 |
del Layout, o donde toque.</p>
|
119 |
<p>También daremos la posibilidad de "habilitar/deshabilitar" |
120 |
(o visíble/invisible) un símbolo pinchando sobre el símbolo |
121 |
en el TOC. Esto es muy útil porque cuando quieres ver solo un determinado
|
122 |
tipo de entidades, las puedes poner invisibles sin tocar la leyenda, y puedes |
123 |
volver a la leyenda habitual fácilmente, sin tener que recargar una leyenda
|
124 |
o fijar colores, tipos de línea, etc. La idea es, por ejemplo, mostar
|
125 |
la descripción del símbolo en gris, o tachado en el TOC. O con |
126 |
un icono de ojo abierto/cerrrado, como lo hace Flash. En el Layout, ponerlo |
127 |
como si no estuviera. Esta funcionalidad no es prioritaria, desarrollarla al |
128 |
final, pero tenerla en cuenta en el diseño.</p> |
129 |
<p>El usuario podrá tener una serie de símbolos "favoritos", |
130 |
o que use con más frecuencia. Tampoco es prioritario. Desarrollarlo al
|
131 |
final, o guardar estas tareas para algún becario o colaborador que quiera
|
132 |
empezar. </p>
|
133 |
<p> </p> |
134 |
<p> </p> |