Revision 1815
branches/FMap_SLD/libraries/libFMap/docs/Analisis_Styling.html | ||
---|---|---|
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).</p> |
|
105 |
<p>Lo mismo pasa con los filtros. Nosotros implementaremos los más comunes, |
|
106 |
pero dejaremos la puerta abierta al resto.</p> |
|
107 |
<p>Para mostrar los símbolos de una capa mixta, en lugar de mostrarlos |
|
108 |
todos en la misma línea (dibujar un rectángulo, línea, |
|
109 |
punto y texto), los vamos a dibujar cada uno con su línea, y solo si |
|
110 |
existen. Es decir, si hemos definido una leyenda sobre un tema de DXF, pondremos |
|
111 |
un icono en el tema que indica que es mixto, y unos símbolos por defecto |
|
112 |
para polígonos, líneas, puntos y texto, uno debajo del otro. Si |
|
113 |
definimos algún símbolo más a la leyenda, aparecerá |
|
114 |
encima de los que son por defecto. Si modificamos la leyenda por defecto quitando |
|
115 |
alguno de esos símbolos, ya no aparecerán en el TOC o la leyenda |
|
116 |
del Layout, o donde toque.</p> |
|
117 |
<p>También daremos la posibilidad de "habilitar/deshabilitar" |
|
118 |
(o visíble/invisible) un símbolo pinchando sobre el símbolo |
|
119 |
en el TOC. Esto es muy útil porque cuando quieres ver solo un determinado |
|
120 |
tipo de entidades, las puedes poner invisibles sin tocar la leyenda, y puedes |
|
121 |
volver a la leyenda habitual fácilmente, sin tener que recargar una leyenda |
|
122 |
o fijar colores, tipos de línea, etc. La idea es, por ejemplo, mostar |
|
123 |
la descripción del símbolo en gris, o tachado en el TOC. O con |
|
124 |
un icono de ojo abierto/cerrrado, como lo hace Flash. En el Layout, ponerlo |
|
125 |
como si no estuviera. Esta funcionalidad no es prioritaria, desarrollarla al |
|
126 |
final, pero tenerla en cuenta en el diseño.</p> |
|
127 |
<p>El usuario podrá tener una serie de símbolos "favoritos", |
|
128 |
o que use con más frecuencia. Tampoco es prioritario. Desarrollarlo al |
|
129 |
final, o guardar estas tareas para algún becario o colaborador que quiera |
|
130 |
empezar. </p> |
|
131 |
<p> </p> |
|
132 |
<p> </p> |
|
0 | 133 |
Also available in: Unified diff