svn-gvsig-desktop / tags / tmp_build / docs / FMap / Edición vectorial en FMap.html @ 43562
History | View | Annotate | Download (7.13 KB)
1 | 1935 | vcaballero | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
---|---|---|---|
2 | <html>
|
||
3 | <head>
|
||
4 | <meta content="text/html; charset=ISO-8859-1" |
||
5 | http-equiv="content-type"> |
||
6 | <title>Edición vectorial en FMap</title> |
||
7 | </head>
|
||
8 | <body>
|
||
9 | <big><big><big>Edición vectorial en FMap<br> |
||
10 | </big><small><small> La edición vectorial en |
||
11 | FMap se realiza sobre fuentes de datos vectoriales mediante el uso de |
||
12 | ficheros auxiliares, en los cuales se va introduciendo las |
||
13 | geometrías modificadas y añadidas. Para esto, FMap |
||
14 | proporciona la interfaz EditableFeatureSource, la cual proporciona los |
||
15 | métodos adecuados para añadir geometrías y |
||
16 | modificar o eliminar las ya existentes.<br>
|
||
17 | <br>
|
||
18 | La edición se efectuará de manera |
||
19 | transaccional, sólo realizandose la escritura en la fuente de
|
||
20 | datos en edición cuando el usuario determine el fin de la
|
||
21 | edición. Llegado este momento, se deberá poder |
||
22 | identificar qué ha pasado con cada geometría. |
||
23 | Inicialmente, cada geometría se identifica por su
|
||
24 | posición ordinal dentro de la capa que se edita y si durante la
|
||
25 | edición, se modifica la geometría i-ésima, se |
||
26 | deberá de situar al geometría modificada en un fichero |
||
27 | auxiliar, manteniendo la información que asocia la
|
||
28 | geometría i-ésima con la geometría insertada en el |
||
29 | fichero auxiliar. Para ello habrá que mantener una
|
||
30 | colección de correspondencias entre las geometrías y su |
||
31 | ubicación física tras la edición. En el caso de la |
||
32 | eliminación de una geometría se deberá de mantener |
||
33 | la información que indica que dicha geometría ha sido |
||
34 | eliminada. Esto último nos lleva a que durante la
|
||
35 | edición, la geometría i-ésima no puede dejar de |
||
36 | existir, puede ser marcada como geometría nula, pero si se
|
||
37 | elimina la geometría i-ésima, las siguientes llamadas a |
||
38 | getGeometry(i) del EditableFeatureSource deben devolver una |
||
39 | NullGeometry y en ningún caso la geometría |
||
40 | (i+1)-ésima.<br> |
||
41 | <br>
|
||
42 | </small></small></big></big><big><big><small><small> |
||
43 | De todo lo anterior se deduce que los ficheros auxiliares irán
|
||
44 | creciendo de forma contínua aunque se eliminen
|
||
45 | geometrías, por lo
|
||
46 | que será necesario crear un mecanismo de compactación. En |
||
47 | dicho mecanismo, lo único que se compacta son los ficheros
|
||
48 | auxiliares que estén en uso, creando un fichero sólo con |
||
49 | las geometrías que actualmente estén en uso.</small></small></big></big><br> |
||
50 | <big><big><small><small><br> |
||
51 | Se identifican fuentes de datos editables de dos |
||
52 | naturalezas. </small></small></big></big><big><big><small><small>Al |
||
53 | comenzar y terminar la edición, las operaciones a realizar son
|
||
54 | distintas en función de dicha naturaleza:<br> |
||
55 | </small></small></big></big> |
||
56 | <ul>
|
||
57 | <li><big><big><small><small>Los ficheros vectoriales.</small></small></big></big></li> |
||
58 | </ul>
|
||
59 | <div style="margin-left: 40px;">Al terminar la edición se |
||
60 | deberá procesar las geometrías en orden y escribirlas en |
||
61 | el fichero que estuviese en edición, machacando el contenido que
|
||
62 | hubiese anteriormente.<br>
|
||
63 | </div>
|
||
64 | <big><big></big></big> |
||
65 | <ul>
|
||
66 | <li><big><big><small><small>Las fuentes de datos remotas con |
||
67 | identificador para las geometrías.</small></small></big></big></li> |
||
68 | </ul>
|
||
69 | <div style="margin-left: 40px;">Al comenzar la edición, |
||
70 | protocolos como WFS permiten realizar un "lock" sobre las |
||
71 | geometrías que se van a editar, de forma que se puede preguntar
|
||
72 | al servidor si las geometrías que se van a poner en
|
||
73 | edición están disponibles o no y permitiendo editar el |
||
74 | subconjunto de éstas que no tienen un "lock". Otros protocolos
|
||
75 | pueden no permitir la edición si alguien está editando, |
||
76 | etc.<br>
|
||
77 | </div>
|
||
78 | <div style="margin-left: 40px;">Al terminar la edición se |
||
79 | deberán procesar las instrucciones necesarias para modificar
|
||
80 | sólo las geometrías afectadas, es decir, eliminar las |
||
81 | geometrías que hayan sido eliminadas durante la edición, |
||
82 | y modificar las geometrías que fueron modificadas durante la
|
||
83 | edición. Esto último requiere algo de complejidad ya que |
||
84 | una geometría puede ser modificada múltiples veces |
||
85 | durante la edición pero sólo debe realizarse una |
||
86 | instrucción de modificación en el servidor (esto no es |
||
87 | estrictamente necesario pero sí conveniente para evitar trabajo
|
||
88 | a un servidor compartido por un número indefinido de clientes).
|
||
89 | Por otro lado si se modifica una geometría y luego se deshace la
|
||
90 | modificación, ésta no ha de modificarse en el servidor, |
||
91 | ni si quiera para dejarla como está ya que ello puede suponer
|
||
92 | problemas de sincronismo cuando varios clientes están editando
|
||
93 | simultaneamente los datos.<br>
|
||
94 | </div>
|
||
95 | <br>
|
||
96 | <big><big><small><small><br> |
||
97 | <big><big>Operaciones<br> |
||
98 | </big></big></small></small></big></big> Las |
||
99 | operaciones que se deben poder realizar sobre un EditableFeatureSource |
||
100 | son:<br>
|
||
101 | <ul>
|
||
102 | <li>Obtención de la geometría i-ésima. Cabe |
||
103 | destacar que esta geometría puede ser:</li> |
||
104 | <ul>
|
||
105 | <li>Original de la capa</li> |
||
106 | <li>Modificación de una geometría original de la capa</li> |
||
107 | <li>Una geometría nueva</li> |
||
108 | <li>Modificación de una geometría nueva<br> |
||
109 | </li>
|
||
110 | </ul>
|
||
111 | <li>Modificación de una geometría. Igual que en el caso |
||
112 | anterior puede ser:<br>
|
||
113 | </li>
|
||
114 | <ul>
|
||
115 | <li>Original de la capa</li> |
||
116 | <li>Modificación de una geometría original de la capa</li> |
||
117 | <li>Una geometría nueva</li> |
||
118 | <li>Modificación de una geometría nueva<br> |
||
119 | </li>
|
||
120 | </ul>
|
||
121 | <li>Eliminación de una geometría.</li> |
||
122 | <ul>
|
||
123 | <li>Original de la capa</li> |
||
124 | <li>Modificación de una geometría original de la capa</li> |
||
125 | <li>Una geometría nueva</li> |
||
126 | <li>Modificación de una geometría nueva<br> |
||
127 | </li>
|
||
128 | </ul>
|
||
129 | <li>Adición de una geometría.</li> |
||
130 | <li>Deshacer acción</li> |
||
131 | <li>Rehacer acción</li> |
||
132 | </ul>
|
||
133 | <big><big>Pila de comandos<br> |
||
134 | </big></big> Durante la edición pueden suceder |
||
135 | imprevistos como que se vaya la luz, se cierre el programa por |
||
136 | algún error, etc. Como la edición se realiza de manera |
||
137 | transaccional, cualquier fallo de este tipo resultará en una
|
||
138 | pérdida total de los datos editados hasta el momento. Este
|
||
139 | problema, se puede enlazar con el mecanismo de deshacer/rehacer |
||
140 | comandos y darle solución de una manera única, |
||
141 | manteniendo en disco un fichero dietario en el que se van apilando los |
||
142 | comandos que van siendo realizados. Este fichero tendrá en la
|
||
143 | cabecera información relativa a qué fuente de datos |
||
144 | estaba siendo editada y la lista de comandos realizados con la |
||
145 | finalidad de que se pueda volver al estado en el que estaba cuando se |
||
146 | finalizó la edición de forma abrupta.<br> |
||
147 | </body>
|
||
148 | </html> |