Por nuestra parte tuvimos tres ponencias bastante variadas que intentamos hacer lo más accesibles e interesantes posible. En primer lugar Víctor presentó los últimos avances de GGL2 [1][2], un tema siempre difícil de transmitir, aun a pesar de que hemos conseguido muy buenos resultados el último año.

Después, Óscar nos enseñó [3][4] que Geoserver tiene una cantidad enorme de funcionalidad que conocemos poco o nada. Nos mostró como simplemente modificando algunos parámetros podíamos obtener una gran variedad de resultados, o como podíamos filtrar mediante el uso de CQL, el uso de WPS dentro de GeoServer… fue una ponencia muy interesante que da para un post entero sobre el tema.

Para acabar, ya en la recta final de las jornadas, Fernando explicó cuál es nuestra propuesta para conseguir que gvSIG funcione con Geotools [5] y solucionar muchos de los problemas del desarrollo, siempre desde un punto de vista muy personal y basado en nuestra experiencia. Creemos que es una apuesta tan atrevida como prometedora y que el éxito depende en gran medida del apoyo de más desarrolladores que coincidan con nosotros en gran parte de la visión del problema. También, en relación con el tema de las IDEs, Micho dio una entrevista en la que contestaba a muchas de las preguntas que surgen alrededor y que podréis ver en breve.

En otro orden de cosas, es digno de mención el encuentro nacional de Geoinquietos. Por un lado tuvo ese factor común que une a todos los grupos locales: el caos ordenado. Pero también, al hacerlo en la sala de conferencias y con un formato más de ponencia que de reunión o mesa redonda, resultó ser un “acontecimiento” un tanto atípico en el que Micho fue el encargado de presentar Geoinquietos Norte y Fernando ganó la votación del diseño del logo para Geoinquietos Valencia. O eso cree él, está por ver. Es verdad que para los propios Geoinquietos fue menos productivo de lo que esperábamos, pero confiamos en que por otro lado sirviera para que la gente se formara una idea más clara de lo que es Geoinquietos y se anime a unirse.

En resumen, una vez más fueron unas jornadas bastante productivas que tenemos que agradecer a Lluís, Núria, Gemma, todo el equipo del Sigte y la Universitat de Girona. Nos volvemos cansados pero muy contentos de haber vuelto a ver a muchos compañeros y amigos, con las pilas cargadas para seguir trabajando y con muchas ganas de volver el año que viene. A ver si de una vez conseguimos solucionar todos los geoproblemas del mundo y nos hacemos millonarios en el camino.

[1] Avances en la integración de GGL2 con gvSIG y Quantum GIS (Slides)
[2] Avances en la integración de GGL2 con gvSIG y Quantum GIS (Paper)
[3] Geoserver, más allá de un servidor WMS (Slides)
[4] Geoserver, más allá de un servidor WMS (Paper)
[5] Integración de GeoTools en gvSIG CE (Paper)

P.D: En el aspecto culinario también queremos destacar que este año descubrimos la deliciosa botifarra de paté d’ànec (longaniza de paté de pato). Muy recomendable. También descubrimos el restaurante “La Placeta”. Nunca habíamos visto tanto empeño y buena voluntad para conseguir un servicio que, dicho en palabras de Micho, “no compilara”.

Although we couldn’t devote as much time as we wanted on the Geotools integration, some progress was done on the technical side and lots of things were discussed. The most important conclusions I took during the week are:

• We need to investigate further on the cost of making the integration. We produced a TODO list that must be explored further before having an accurate idea of the cost. It can be seen at the end of this post.
• Creating an adapter layer from current gvSIG API to new Geotools based one would reduce the incompatibilities with existing extensions. However, creating and maintaining such adapter is quite expensive and was one of the things that slowed me most during the codesprint. As Fran suggested, it would be cool to have a migration guide from old API to new one, but backwards compatibility at the development level is not considered from now on.
• There is the will to collaborate between people from the two forks. From the next CE version, we’ll share NavTable and OpenCADTools will also be integrated. Hopefully, the collaboration around these projects will be only the beginning of a more tight collaboration.

In the same branch we worked on the Geotools integration we did some other tasks that also improve the development experience, which we consider very important.

One of these tasks is the Maven management: we are adding Maven support to all gvSIG projects. With this improvement it is not necessary to care about transitive dependencies anymore and, since these dependencies are automatically managed by Maven, and it is neither necessary to keep them in the repository. Thus, not only we obtain a much cleaner way of managing the dependencies and the configuration of the Eclipse projects but also we remove one of the most heavy set of files in the repository. However, the Maven management is not completely done: it is still necessary to configure Maven in order to generate the plugins and artifacts necessary to build a complete gvSIG distribution.

Another important task is the cleanup work: we removed a lot of unused features, dead code, extensions and more. Also, we formatted the code and organized imports of all Java files in order to have a much more readable source code with less warnings (indeed, I get confused whenever I have more than 15.000 warnings, I know, I get older). What we obtain with these improvements is, on one hand, to remove useless code that cannot realistically be maintained by the gvSIG CE team and, on the other hand, to obtain a much clearer source code. In order to quantify the weight lost with these changes, we have checked the number of source code lines in .xml and .java files, as well as the total MB size in the applications, extensions, frameworks and libraries folders:

Before Code Sprint

• 153.113 lines in .xml files.
• 1.313.508 lines in .java files.
• 543MB in all files.

After the Code Sprint

• 149.179 lines in .xml files.
• 1.181.750 lines in .java files.
• 303MB in all files.

So, in percentages, we managed to reduce the following amounts:

• 2.57% in .xml files.
• 10.03% in .java files.
• 44.20% in total MB.

Next steps will be to go on estimating the cost of GeoTools integration. I plan to dedicate two or three days before the end of the month to the TODO list to gain a greater visibility on what’s to be done. Then, hopefully we’ll have enough information to take some decisions.

As for the aforementioned TODO list, we’ve identified the following tasks:

1.- Replace the adapter layer for DataStores.
This involves removing the adapters completely. We thought about creating an adapter layer to adapt the calls to old gvSIG adapter layer to the new GeoTools based one but we found some problems:

• The layer is very big, it should involve reading as well as writing operations.
• The layer has random access to the features while geotools has only sequential access.

We have decided that investing in this layer it is not worth. We prefer to remove completely old API and adapt the extensions. This will lead to incompatibility with extensions maintained for Association gvSIG but in the case of NavTable and OpenCADTools it seems like there is some interest in decoupling the data access layer so that 95% of the code is compatible.

- There are many points were the instance of the adapter is checked. This can be implemented by methods at the FLayer level (isFile, isDB, etc.). The layer gets the information from the DataStore or at construction time.
- Remove the adapters and see how many compile errors we get. We can compare it with the many errors we got with the CRS replacing where we got hundreds of errors and it only took 30 hours to compile it back (there is pending effort there).
- Adapt selection to DataStores (http://docs.geotools.org/latest/userguide/library/main/filter.html#handling-selection)
- Edition. Good point. Research on GT necessary here.
- Intelligent usage of DataStores. They are heavy objects. They should be cached, shared between layers and closed when not used anymore (or when not used for some time). SourceManager in libFMap is a very primitive implementation of this.
- FLyrWFS could be just a FLyrVect with a WFS DataStore on it.

2.- Remove libDriverManager, remove writers, remove GDBMS.
We should remove all these projects and see how many compile errors we get. We can compare it with the many errors we got with the CRS replacing where we got hundreds of errors and it only took 30 hours to compile it back (there is pending effort there).

- It is still necessary to show the user a list of available DB connectors, file formats with writing capabilities, etc. So in place of the drivers a “Source” abstraction must be built.
- To connect to databases it is necessary to create connections, to query all the available tables, etc. Not sure if this can be done with GT. It is necessary to check. If it is not possible maybe a specialization of Source called DBSouce should be built to manage that.

3.- Remove all raster stuff under FLyrRaster.
- Analogous to the adapter layer removal.

4.- Make layers become structured data object holders.
They don’t hold any functionality related with data. They will just provide a DataStore, a GridCoverage, a Geotools WMS client, etc. and the name of the layer, the relation with the other layers (parent, sibling, etc.)

- There is no need for most of FLyrVect subclasses since the difference between file and db is at the DataStore level. As holders of DataStore, a file based layer is exactly equal to a holder of a database. So VectorialDBLayer, VectorialFileLayer, etc. should be removed.
- Some subclases just add some functionality, like VoronoiAndTinInputLyr. This can be implemented like an adapter system in Eclipse EMF generated classes and can be easier for persistence than subclassing.

5.- Include OGR DataStores: OGR providers available as GT DataStores.

6.- Include image-io-ext providers: GDAL providers available as GT GridCoverages.

7.- Mavenization of build.
- We can take advantage of the efforts done in 2.0
- It will allow to run tests easily, produce coverage reports, sonar reports, keep
dependencies out of the SVN repository (faster checkouts and commits), put in place
an integration server, etc.

8.- Tests (lots of)
- Even if it is not the perfect indicator, we should produce a coverage report in order to motivate people to add tests.
- We could allow any refactoring (in the strict meaning of the word) that extracts some functionality and covers it with tests. Even if something breaks, it’s better in the long term.

9.- Persistence through extensible schemas.
- Create a extensible schema.
- Keep the methods that reads old projects and adapt to the new changes. Add an option “Import old project” that calls these methods.

10.- Recover WMS Dimension support (lost after Fran’s WMS refactoring)

11.- Data access abstraction layer for OpenCADTools and NavTable

12.- Andami simplification
- Make all plugins work under the same classloader -> Faster startup time.

First of all, we have to say that the result is quite satisfactory. Except for a couple of cases that we will discuss later, all the functionality has been migrated successfully. Basically, we have done a two-step task: first, replace the existing references to previous versions of Geotools with the current version (Geotools 8.0) and then replace the gvSIG projection library with Geotools.

The first step involves the replacement of existing code that uses previous versions of Geotools with new code that uses the 8.0 version. Thus, we have replaced not only old jars but also classes in the repository that were copies of the Geotools code. An example of the latter is the org.geotools.referencefork package on libTopology. These changes can be reviewed in the SVN repository [1][2].

Then, the tricky part is to replace the gvSIG projection API with the Geotools one. This can be better viewed in the following diagrams that show the before and after status. Note that the red gvSIG element stands for every place in the gvSIG code that uses projections:

gvSIG projections before Geotools integration

gvSIG projections after Geotools integration

Basically, we replace the following interfaces:

• IProjection (gvSIG) -> CoordinateReferenceSystem (Geotools)
• ICoordTrans (gvSIG) -> MathTransform (Geotools)

and we get rid of all the custom CRS, CRS factories and everything related with implementations since Geotools already provides us that. Also, in order
to make the change as smooth as possible, a ProjectionUtils class has been created to delegate some tasks on Geotools and perform some other tasks that were responsibility of gvSIG CRS related interfaces but don’t exist in Geotools replacements. It’s a kind of adapter from the previous gvSIG API to the new Geotools one. In some cases
this adaptation is direct and ProjectionUtils simply manages an exception (for example, the getCRS method), but in other cases it performs a bit more complicated task (for example, the transform method). In any case, it is desirable that this class will eventually disappear for a full adaptation of the gvSIG code to the Geotools API. Finally, the libJCRS and extJCRS projects are excluded from build since we don’t need them anymore. These changes can be reviewed in the SVN repository [3][4].

After all this work, we have obtained a gvSIG version that performs projections using Geotools and we have removed almost three projects (extJCRS and libJCRS completely and most of libProjection classes), so the gvSIG team has less code to mantain. However, while replacing the projection support, some functionaly has been lost. As a result, some topology processes related with referencing and the Voronoi diagram may not work properly. Also, specifying the map scale manually may not work as expected. Lastly, by excluding the extJCRS extension, the panel for projection selection has been replaced with a previous version, less intuitive. These are the main issues that have arisen, but there are more little technical details that can be reviewed in the gvSIG CE code sprint wiki [5].

Regarding the cost of the task, it is important to notice that some tasks are still to be done, as explained previously. Also, by performing these changes, it is expected that some bugs would have been introduced, so the cost we present here does not take the technical debt into account and it will not be surprising that it doubles the cost of the already done work. Having considered all that aspects, the cost of the task performed so far is around 30 hours.

Finally, it is important to consider what the future tasks should be: what remains to be done and how to do it. In our case, the first task is to identify introduced bugs with unit tests, solve them and, if possible, remove the ProjectionUtils class to have a full adaptation to the Geotools API. Then, we should introduce Geotools in the data access layer of gvSIG and get rid of the drivers/adapters system, one of the most obscure parts in gvSIG. In order to do so, we should use directly the Geotools data stores from the layer classes (FLayer, FLyrVect, …). Thus, we can transform the current gvSIG data access layer:

gvSIG data access

into a much more simple layer:

gvSIG data access with Geotools

A rough test has been made in this direction and the result can be seen in the following video. We use a toolbar button to add a new layer that uses Geotools in order to read a shapefile (specified by code, just for test purposes):

gvSIG vector layer with Geotools

However, this new FlyrVect with Geotools does not have a ReadableVectorial implementation since it uses a Geotools data store directly. A solution is to remove the getSource method from FLyrVect, but then all the extensions that implement custom drivers or use the ReadableVectorial directly will be broken. Thus, the backward compatible option consists in implementing an adapter for ReadableVectorial (and every other interface that gets obsolete in the layer classes API) that delegates in Geotools directly.

Moreover, there are a few tasks that, despite not being strictly necessary, are very interesting and should be considered. First, it is also possible to replace the gvSIG implementation for rendering and symbology. The advantages of this change is that all symbology code will be replaced with Geotools. Another feasible option for Geotools integration is the query syntax. gvSIG provides several different syntaxes to query data so it could be possible to replace all these syntaxes with the Geotools implementation. Regarding the processing framework, it could be also interesting to analyze the current status of gvSIG and determine the benefits of using the Geotools framework. Finally, there are OGR data stores available in Geotools that can be used in order to get access to a great amount of formats [6].

In conclusion, we hope that the work we have done gives a better perspective of the Geotools integration in gvSIG, how it can be performed, what we can and cannot do in the next gvSIG CE code sprint in Munich [7] as well as some hints on what will be the cost of the full integration.

[1] SVN revision 701
[2] SVN revision 702
[3] SVN revision 703
[4] SVN revision 704
[5] Geotools in gvSIG CE
[6] OGR Vector Formats
[7] gvSIG CE Code Sprint in Munich

Actualmente estamos envueltos en la vorágine de cierre de proyecto, acercándonos a ese primer “ultimo commit”, con un proyecto en el que estamos desarrollando un visor para explotar recursos turísticos. Una de los requisitos es que la interfaz estuviese en dos idiomas: inglés y español. Como siempre, antes de empezar a reinventar la rueda, miramos que era lo que podíamos reutilizar y encontramos jQuery.i18n un plugin de jQuery que nos permite trabajar con archivos .properties al modo de Java, algo a lo que estamos acostumbrados. Después de revisar el plugin y leer las posibles “Known Issues” vemos que puede encajar en nuestra aplicación.

La instalación es sencilla, el uso es muy dinámico, nos permite cambiar el idioma de la aplicación mediante llamadas Ajax que no necesitan recargar el sitio web y el manejo de los idiomas y ficheros es ágil y no implica tener que tocar nada de nuestros objetos, así que, Voila!!, funcionando en Google Chrome, en Firefox y… oh wait!!, ¡no va en Internet Explorer(IE)!, maldita sea, ¡traigan a Bill Gates!.

Buceando en la red no veo que haya dado problemas con IE. En principio con no poner los IDes de los objetos HTML con el mismo valor que las claves en los archivos .properties parece que no haya nada más detectado. El depurador de IE me lanza el error en la linea:

eval(parsed);

Sin embargo la función eval si está en las especificaciones del navegador. Por lo que tiene pinta de ser algo que le pasamos en parsed. Depurando esta llamada veo que el problema viene de una de las claves que estoy usando en los archivos .properties:

close = Cerrar

IE al ejecutar eval entiende close como la función y es hay donde genera el error, tan fácil de solucionar como:

s_close = Cerrar

Así que recordad, no uséis como claves en los archivos .properties palabras reservadas, que hay mucho navegador quisquilloso por ahí.

Saludos.

This API allows developers to execute GGL2 processes from their programs with a single call, passing the GGL2 code as a parameter. Thus, Java and Python developers can now run GGL2 algorithms using their own language easily.

In order to use this API, GGL2 must be installed and the installation directory specified before executing GGL2 code. Then, the execute call will run the GGL2 code and will return normally if the process finishes successfully or will throw an exception if anything fails. Different exceptions will be thrown depending on whether the error has been a GGL2 compilation error, a GGL2 execution error or any other unexpected error.

For Java developers, the GGL2 API is available with and without Maven. In the end, the necessary jars must be included in the classpath and then a simple program like this example can be executed:

import org.gearscape.ggl.GGL2;

public class Main {

    public static void main(String[] args) throws Exception {

        GGL2 ggl2 = new GGL2("/home/victorzinho/bin/ggl");

        ggl2.execute("show 'Hello World!';");

    }

}

For Python developers the module containing the GGL2 API must be imported. The previous example can be executed as follows:

import GGL2

GGL2.location = '/home/user/bin/ggl'
GGL2.execute("show 'Hello World!';")

There is a complete tutorial on how to configure and use the API with both Java and Python in [1].

—–

[1] http://www.gearscape.org/html/ggl2/ref/apis.html

Sorry, I’m a sentimentalist.

Ciao.

In order to use Qgis layers, simply use the qgis_ prefix followed by the name of the layer in Qgis. In GGL2, this will show the number of roads of the Qgis layer roads:

show qgis_roads/@length;

On the other hand, it is possible to export the results into Qgis selecting it as the default GIS in the GGL2 environment and using the show in gis instruction. For example, we can show the buffer of the roads layer using GGL2 with the following program:

import ggl.geom;

import ggl.shp;

show qgis_roads select(r | ST_Buffer(r/the_geom, 10)) in gis as SHP ‘buffer’;

There is more information on how to configure the default GIS and how the GIS interaction works on the documentation site.

Regarding the user interface and the configuration of the plugin, the behavior is very similar to the already available plugin in gvSIG. It is possible to connect/disconnect the plugin from a toolbar button and there is a menu in Plugins -> GGL2 to configure the port used to connect to GGL2.

One of the most important advantages of this plugin is that Qgis is now added to the set of available GIS applications from GGL2, together with gvSIG. Thus, users can share data betweeen applications easily. For example, it is possible to segment roads from a gvSIG layer with regions from a Qgis layer and show the results in our default GIS application:

import ggl.shp;

import ggl.geom;

roads_region = gvsig_roads join qgis_regions(o, e |

on ST_Intersects(e/the_geom, o/the_geom)

include geom_region=e/the_geom, municipio=e/nombre);

segments = roads_region select (r | the_geom=ST_Intersection(r/geom_region, r/the_geom),

all except r/geom_region, r/the_geom);

show segments in gis as SHP ‘segments’;

This plugin opens the Qgis world to all the GGL2 users and also brings GGL2 closer to the Qgis users. However, the Qgis plugin is still an ongoing development and may suffer some bug corrections as well as some improvements such as a GGL2 console in order to execute GGL2 code directly from Qgis.

• Manejo de diferentes proveedores de cartografía
• Manejo de formato KML con simbología propia
• Desarrollo de procesos de edición

Valoramos los diferentes proyectos de software libre que existían en ese momento tales como osmdroid, mapsforge o gvSIG Mini. Todos son proyectos muy interesantes que permiten el desarrollo de aplicaciones con mapas para Android. Nosotros nos decidimos por gvSIG Mini. Este último nos permitía:

• Manejo de diferentes proveedores de cartografía mediante la librería TileRaster, mediante la cual podemos incorporar sencillamente los nuevos proveedores de datos
• Capacidades de manejo de información vectorial mediante las librerías GPE
• Gracias a una refactorización que llevamos a cabo preparabamos gvSIG Mini para la incorporación de controles de edición vectorial

Además, el tener relación con los desarrolladores de gvSIG Mini, en principio nos daba un apoyo, que a lo largo del proyecto se demostró de mucha utilidad.
Así que decidido que apoyaríamos nuestro desarrollo en el proyecto gvSIG Mini nos metimos en harina.

La primera fase del proyecto estuvo orientada a implementar la parte más social de la plataforma. Desarrollada completamente utilizando las librerías proporcionadas por la plataforma Android, tuvimos que enfrentarnos a la gestión de Intents, creación de Parcelables para el manejo de información entre actividades, peculiaridad del sistema Android, y el control de Broadcast para la detección de cambios en el estado del sistema. Sin muchos problemas, conseguimos sacar adelante esta fase.

En una segunda fase nos adentramos en el desarrollo de las capacidades geográficas de la aplicación. Las tareas a las que nos enfrentamos fueron:

• Integración de la vista de gvSIG Mini en nuestro desarrollo
• Gestión de las diferentes capas base requeridas
• Manejo de la posición actual del terminal
• Gestión de la diferente simbología de la plataforma ikiMap
• Procesos de creación y edición de geometrías en el terminal

Así que lo primero fue extraer la vista principal, el MapView, e incorporarla a nuestra aplicación. Tras el proceso de refactorización la MapView estaba preparada para poder ser utilizada como un componente dentro del desarrollo. En principio no debía ser algo que generase muchos problemas aunque a lo largo del desarrollo surgieron algunos que comentaremos más adelante.
Para la incorporación de las diferentes capas base, encontramos que parte de las que necesitábamos no se encontraban dentro de las aportadas por la librería TileRaster. Esta librería se configura mediante la edición de un archivo de texto donde se incluyen los parametros necesarios para la capa. Por ejemplo la inserción de la capa de CloudMade Red Alert quedaría de la siguiente manera:

102|Cloudmade Red Alert;0,

png,18,0,256,
-2.0037508342789244E7,-2.0037508342789244E7,-2.0037508342789244E7,
-2.0037508342789244E7,2.0037508342789244E7,2.0037508342789244E7,
EPSG:900913,
156543.03392804096153584694438047:78271.516964020480767923472190235:
39135.758482010240383961736095118:19567.879241005120191980868047559:
9783.9396205025600959904340237794:4891.9698102512800479952170118897:
2445.9849051256400239976085059448:1222.9924525628200119988042529724:
611.49622628141000599940212648621:305.74811314070500299970106324311:
152.87405657035250149985053162155:76.437028285176250749925265810776:
38.218514142588125374962632905388:19.109257071294062687481316452694:
9.5546285356470313437406582263471:4.7773142678235156718703291131735:
2.3886571339117578359351645565868:1.1943285669558789179675822782934:
0.59716428347793945898379113914669:0.29858214173896972949189556957335:
0.14929107086948486474594778478667:0.074645535434742432372973892393336:
0.037322767717371216186486946196668:0.018661383858685608093243473098334:
0.009330691929342804046621736549167

Una vez que hemos insertado las diferentes capas en la librería podremos utilizarlas desde nuestra aplicación simplemente creando un renderer de la capa que necesitamos y pasandosela como parámetro a la TileOverlay que queremos crear:

renderer = Layers.getInstance().getRenderer(Nombre_de_la_capa);
baseLayer = new TileOverlay(getApplicationContext(), mapView,
Nombre_de_la_capa, renderer, CompatManager.getInstance()
.getRegisteredContext(), true);


Para el manejo de la posición actual del dispositivo se utilizó las funciones de la API de Android que gestionan el GPS de los terminales. La implementación dentro del proyecto realiza la búsqueda del mejor proveedor de localización teniendo en cuenta la precisión de la medida (Criteria.ACCURACY_FINE) y actualiza la posición cuando esta cambia. Permite así la realización de búsquedas por posición consumiendo las funciones que ofrece la API de ikiMap para este propósito.

La creación de mapas de ikiMap permite la asignación de diferente simbología a las geometrías. Desde el entorno web de la aplicación, esto no representa ningún problema. La mayoría de las librerías que se utilizan para webmapping permiten la asignación de símbolos personalizados mediante llamadas a una imagen que se encuentre publicada en la web. Para el caso de Android, el estado de las librerías en el momento del desarrollo, no disponía de esta funcionalidad. Para solucionar esto, se creó una clase SymbolizedJTSFeature que hereda de una JTSFeature. Para el manejo de símbolos se crearon clases propias como IkiMapCollectionSymbol. Resumiendo, lo que se hace es asignar a la geometría, cuando esta es tipo punto, un bitmap con el símbolo. Para ello se implementan servicios que descargan estás imágenes de la web y las sitúa sobre el mapa en la posición de la geometría asociándola a esta mediante el uso de las clases anteriores. Aquí es donde se nos han presentado algunos problemas con la gestión de la memoria. En la gestión de las imágenes dentro de la aplicación hay que tener control sobre los flujos de descarga de estas y el manejo de las mismas dentro de los diferentes estados de las actividades para evitar leaks de memoria y los errores ANR (Aplication Not Responding). Tras un exhaustivo estudio de la gestión de la memoria apoyándonos en herramientas como el Memory Analizer (MAT) se consiguió detectar las fuentes de los errores y optimizar el proceso de gestión de las imágenes.

Diagrama de clases para dibujado

Por último, la parte más importante de todo el desarrollo, la edición vectorial en dispositivos móviles. Esta parte era la que, a priori, más dudas planteaba. Necesitábamos poder crear geometrías dibujando en nuestro terminal. Tras la refactorización de la MapView de gvSIG Mini, esta quedó preparada para la inserción de controles de manera sencilla. Así que apoyandonos en la clase de gvSIG AbstractMapControl y la interfaz IMapControl, se generaron los controles de dibujado. Estos se apoyan en una capa de dibujado DrawingOverlay donde van creando las geometrías. El modo edición dispone de las funcionalidades comunes, como añadir punto y eliminar último punto. Una vez terminada la edición, se pueden incluir los datos alfanuméricos asociados a la geometría y seguidamente un parser de KML crea un fichero KML que es enviado a los servidores de la aplicación.

De momento la aplicación no ha visto la luz, esperemos que lo haga en breve y que se ponga a disposición el código con estas funcionalidades. Mientras os dejamos el vídeo con la presentación de las Jornadas de Sig Libre de Girona del 2012.

ikiMap, la plataforma social de la cartografía from SIGTE – Universitat de Girona on Vimeo.

Saludos.

First, the interaction with the students has been very pleasant. They were quite different, coming from different professional areas, so it was not easy to give a course that would fit everyone. There were some students that did not have any previous programming experience and needed to learn the basics of programming as well as the GGL2 specifics, so they had to work very hard. There were also some students that did have previous programming experience and did a lot of optional exercises, so they worked very hard too. As a result, almost all the students got their gvSIG certification. Only a couple of them could not pass the course due to unforeseen circumstances.

On the other hand, the evaluation of the course by the students has been also satisfactory. According to the satisfaction survey, they found it very interesting and seems like the exposition of the contents has been very clear. However, the duration of the course has not been exactly adequate to the contents.

As far as the language and tools are concerned, there have been a lot of improvements and corrections before and during the course. Before the course, and specifically for that matter, we prepared a new set of command line tools. These command-line utilities provide two commands in order to compile (gglc) and execute (ggl) GGL2 code. Thus, it is now possible to use a lightweight tool in order to compile and execute GGL2 and it won’t be necessary any graphical user interface anymore. However, the graphical user interface still is pretty cool and we recommend you to use it as well. Moreover, new documentation has been added to the GearScape site. There’s a tutorial on how to compile and execute programs with the command-line tools [1] as well as some reference documentation [2].

Furthermore, the students worked on different environments and they found some bugs related to the different platforms. They also tried a lot of different things in order to solve the exercises and they found also a few hidden bugs. All these issues are resolved now. As a result, we have published a new milestone GGLM5.

Finally, regarding documentation, the course has been published[3] using a Attribution-ShareAlike CC license. Also, the solution to all the exercises are available in the GGL2 repository[4]. Thus, it is possible to download the course documentation and correct your exercises against the provided solutions. If any question pops up, simply address it to the mailing lists [5].

We want to thank the students for their interest and enthusiasm and the gvSIG association for their help in making the course a reality.

Aprovechando que desde geosolutions se han currado un buen post sobre el tema, abusamos de su confianza para plagiarlo y adaptarlo al ámbito hispano.

Presentamos aquí los nuevos métodos de transformación de coordenadas que hemos incorporado a GeoServer y GeoTools, así como las nuevas herramientas que permitirán controlar mejor qué transformaciones de coordenadas debe aplicar GeoServer en cada caso.

A partir de la versión 2.2-beta2, GeoServer puede utilizar rejillas de transformación en formatos NTv2 y NADCON. Gracias a estos nuevos métodos se amplían las posibilidades de transformación con métodos que permiten modelar mejor las distorsiones entre los sistemas de referencia tradicionales y los de nueva implantación.

La razón de esta diferencia es simple: la transformación 7 parámetros es un cambio de base en el espacio 3D, lo cual no permite modelar ciertas distorsiones, mientras que una transformación de rejilla establece un mapeo punto a punto entre las posiciones en ambos sistemas de referencia.

Por defecto, GeoServer soporta las rejillas incluídas en la base de datos EPSG, listadas en su manual de usuario. Bastará con descargar los ficheros de rejilla y copiarlos en el directorio de datos de GeoServer.

Pero esta no es la única novedad. GeoServer hasta ahora ha dependido de la base de datos EPSG para determinar la mejor transformación entre dos sistemas de referencia. Esto no siempre es la mejor solución. Puesto que las transformaciones de datum se determinan de forma empírica (midiendo y comparando puntos sobre el terreno), en ocasiones se dispone de métodos y observaciones más precisas para un caso determinado, aunque no se incluyan oficialmente en EPSG. Por ejemplo, el Instituto Geográfico Nacional publica una rejilla NTv2 que cubre todo el territorio peninsular español, con un error asociado que puede llegar hasta el metro en algunos casos, mientras que el Institut Cartogràfic de Catalunya publica una rejilla específica para Catalunya, que acota el error residual a 5 cm. En el caso del ICC, la rejilla no modela la distorsión, sino que equivale a aplicar la transformación oficial (de semejanza bidimensional).

Así pues, definiendo una transformación personalizada se pueden conseguir resultados óptimos para situaciones específicas. Estas definiciones no sólo se limitan a las transformaciones de rejilla: véase de nuevo el manual de GeoServer sobre cómo definir transformaciones personalizadas.

Entonces, ¿cómo comprobar qué transformación se aplica en cada caso, y si está bien definida? GeoServer 2.2 viene con una nueva herramienta en el apartado “demo”, la consola de transformación, que permite efectuar manualmente transformaciones entre cualquier par de sistemas de coordenadas, y comprobar los detalles de la transformación que se está aplicando en cada caso.

La mayor parte de este trabajo ha sido financiada por el Institut Cartogràfic de Catalunya y desarrollada por quien escribe, pero también ha contado con el imprescindible apoyo de Andrea Aime, que ha revisado las contribuciones de código y ha aportado herramientas muy útiles, como la misma consola de reproyección.

Para los más entusiastas, teneis a vuestra disposición un informe detallado con el “making of” del desarrollo.