svn-gvsig-desktop / branches / Fmap_GisPlanet / libraries / libFMap / docs / Analisis_Styling.html @ 1841
History | View | Annotate | Download (7.93 KB)
1 | 1815 | fjp | <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 | 1825 | fjp | 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 | 1815 | fjp | <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> |