root / branches / FMap_piloto_CAD_Layout_version / libraries / libFMap / docs / Edición vectorial en FMap.html @ 1762
History | View | Annotate | Download (7.01 KB)
1 | 1762 | vcaballero | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
---|---|---|---|
2 | <HTML>
|
||
3 | <HEAD>
|
||
4 | <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"> |
||
5 | <TITLE>Edición vectorial en FMap</TITLE> |
||
6 | <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.1 (Linux)"> |
||
7 | <META NAME="CREATED" CONTENT="20050315;16132800"> |
||
8 | <META NAME="CHANGED" CONTENT="20050316;11344600"> |
||
9 | </HEAD>
|
||
10 | <BODY LANG="es-ES" DIR="LTR"> |
||
11 | <P><FONT SIZE=5><FONT SIZE=6>Edición vectorial en FMap<BR></FONT><FONT SIZE=3>La |
||
12 | edición vectorial en FMap se realiza sobre fuentes de datos
|
||
13 | vectoriales mediante el uso de ficheros auxiliares, en los cuales se |
||
14 | va introduciendo las geometrías modificadas y añadidas. |
||
15 | Para esto, FMap proporciona la interfaz EditableFeatureSource, la |
||
16 | cual tiene los métodos adecuados para añadir geometrías |
||
17 | y modificar o eliminar las ya existentes.<BR><BR>La edición se |
||
18 | efectuará de manera transaccional, sólo realizandose la |
||
19 | escritura en la fuente de datos cuando el usuario determine el fin de |
||
20 | la edición. Llegado este momento, se obtendrá una |
||
21 | fuente de datos resultado de la edición que contendrá |
||
22 | al menos el mismo número de geometrías que al principio |
||
23 | de ésta. Esto es así porque las geometrías |
||
24 | eliminadas se identificarán porque serán null, es |
||
25 | decir, si se tiene una fuente de datos con 10 geometrías y en
|
||
26 | edición se eliminan las 5 últimas, la fuente resultante |
||
27 | de la edición tendrá 10 geometrías y las 5 |
||
28 | últimas serán null. Las geometrías que se añadan |
||
29 | se situarán al final de la fuente de datos ( a partir de la
|
||
30 | posición 11 del ejemplo).</FONT></FONT></P> |
||
31 | <P><FONT SIZE=3>Por otro lado se mantiene un histórico de los |
||
32 | comandos de edición que se van ejecutando, de manera que se
|
||
33 | puede deshacer cualquier comando desde que se comenzó a editar
|
||
34 | la fuente de datos. Esta misma pila de comandos sirve para realizar |
||
35 | un modo de recuperación en caso de terminaciones abruptas de
|
||
36 | la edición (apagones, etc) de forma que se recupera el estado
|
||
37 | exacto del fichero en edición en el momento del percance. Como
|
||
38 | la edición se realiza de manera transaccional, cualquier fallo
|
||
39 | de este tipo resultará en una pérdida total de los |
||
40 | datos editados hasta el momento por lo que esta característica
|
||
41 | es muy útil en esos casos.</FONT></P> |
||
42 | <P><FONT SIZE=3>Internamente, toda modificación y adición |
||
43 | de geometrías implicará un crecimiento en el fichero de |
||
44 | expansión, de forma que al rato de estar en edición el |
||
45 | fichero puede haber crecido mucho. Por otro lado tenemos el fichero |
||
46 | de comandos de edición comentado anteriormente que crece con
|
||
47 | cada acción. Durante una edición muy larga puede ser |
||
48 | excesivo el espacio que se está ocupando con estas dos
|
||
49 | estructuras de datos y es por esto que se proporciona un mecanismo de |
||
50 | compactación que reduce estos ficheros al mínimo |
||
51 | necesario. El problema de realizar una compactación es que se
|
||
52 | pierde el histórico de comandos.</FONT></P> |
||
53 | <P>Se identifican fuentes de datos editables de dos naturalezas. Al
|
||
54 | 1242 | fernando | comenzar y terminar la edición, las operaciones a realizar son
|
55 | 1762 | vcaballero | distintas en función de dicha naturaleza:</P> |
56 | <UL>
|
||
57 | <LI><P>Los ficheros vectoriales. |
||
58 | </P>
|
||
59 | </UL>
|
||
60 | <P STYLE="margin-left: 1.06cm">Al terminar la edición se |
||
61 | deberá procesar las geometrías en orden y escribirlas |
||
62 | en el fichero que estuviese en edición, machacando el
|
||
63 | contenido que hubiese anteriormente.</P>
|
||
64 | <UL>
|
||
65 | <LI><P>Las fuentes de datos remotas con identificador para las |
||
66 | geometrías.
|
||
67 | </P>
|
||
68 | </UL>
|
||
69 | <P STYLE="margin-left: 1.06cm; margin-bottom: 0cm">Al comenzar la |
||
70 | edición, protocolos como WFS permiten realizar un "lock" |
||
71 | sobre las geometrías que se van a editar, de forma que se
|
||
72 | puede preguntar al servidor si las geometrías que se van a
|
||
73 | poner en edición están disponibles o no y permitiendo |
||
74 | editar el subconjunto de éstas que no tienen un "lock". |
||
75 | Otros protocolos pueden no permitir la edición si alguien está |
||
76 | editando, etc.</P>
|
||
77 | <P STYLE="margin-left: 1.06cm; margin-bottom: 0cm">Al terminar la |
||
78 | edición se deberán procesar las instrucciones |
||
79 | necesarias para modificar sólo las geometrías |
||
80 | afectadas, es decir, eliminar las geometrías que hayan sido
|
||
81 | eliminadas durante la edición, y modificar las geometrías |
||
82 | que fueron modificadas durante la edición. Esto último |
||
83 | requiere algo de complejidad ya que una geometría puede ser
|
||
84 | modificada múltiples veces durante la edición pero sólo |
||
85 | debe realizarse una instrucción de modificación en el |
||
86 | servidor (esto no es estrictamente necesario pero sí
|
||
87 | conveniente para evitar trabajo a un servidor compartido por un |
||
88 | número indefinido de clientes). Por otro lado si se modifica
|
||
89 | una geometría y luego se deshace la modificación, ésta |
||
90 | no ha de modificarse en el servidor, ni si quiera para dejarla como |
||
91 | está ya que ello puede suponer problemas de sincronismo cuando
|
||
92 | varios clientes están editando simultaneamente los datos.</P> |
||
93 | <P><BR><BR><FONT SIZE=5>Operaciones<BR></FONT> Las |
||
94 | operaciones que se deben poder realizar sobre un |
||
95 | EditableFeatureSource son:</P>
|
||
96 | <UL>
|
||
97 | <LI><P STYLE="margin-bottom: 0cm">Obtención de la geometría |
||
98 | i-ésima. Cabe destacar que esta geometría puede ser: |
||
99 | </P>
|
||
100 | <UL>
|
||
101 | <LI><P STYLE="margin-bottom: 0cm">Original de la capa |
||
102 | </P>
|
||
103 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
104 | geometría original de la capa
|
||
105 | </P>
|
||
106 | <LI><P STYLE="margin-bottom: 0cm">Una geometría nueva |
||
107 | </P>
|
||
108 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
109 | geometría nueva</P> |
||
110 | </UL>
|
||
111 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
112 | geometría. Igual que en el caso anterior puede ser:</P> |
||
113 | <UL>
|
||
114 | <LI><P STYLE="margin-bottom: 0cm">Original de la capa |
||
115 | </P>
|
||
116 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
117 | geometría original de la capa
|
||
118 | </P>
|
||
119 | <LI><P STYLE="margin-bottom: 0cm">Una geometría nueva |
||
120 | </P>
|
||
121 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
122 | geometría nueva</P> |
||
123 | </UL>
|
||
124 | <LI><P STYLE="margin-bottom: 0cm">Eliminación de una |
||
125 | geometría.
|
||
126 | </P>
|
||
127 | <UL>
|
||
128 | <LI><P STYLE="margin-bottom: 0cm">Original de la capa |
||
129 | </P>
|
||
130 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
131 | geometría original de la capa
|
||
132 | </P>
|
||
133 | <LI><P STYLE="margin-bottom: 0cm">Una geometría nueva |
||
134 | </P>
|
||
135 | <LI><P STYLE="margin-bottom: 0cm">Modificación de una |
||
136 | geometría nueva</P> |
||
137 | </UL>
|
||
138 | <LI><P STYLE="margin-bottom: 0cm">Adición de una geometría. |
||
139 | </P>
|
||
140 | <LI><P STYLE="margin-bottom: 0cm">Deshacer acción |
||
141 | </P>
|
||
142 | <LI><P>Rehacer acción |
||
143 | </P>
|
||
144 | </UL>
|
||
145 | </BODY>
|
||
146 | </HTML> |