Jornadas SIG Libre Girona 2013

Publicado el por
Responder

Un año más, las jornadas de SIG Libre de Girona acaban y volvemos cada uno a nuestra rutina (el que la tenga). Como en cada edición, nos traemos de vuelta muchas cosas interesantes que acabar de digerir. Una de las cosas que más tiempo ha ocupado en nuestras conversaciones tal vez haya sido la crítica a las IDEs y los estándares OGC. También, siempre desde nuestro punto de vista, nos ha parecido muy interesante y a la vez debatible la ponencia de CartoDB. Nos llevamos también la impresión de que Quantum GIS se nos acerca cada vez más y puede ser una gran oportunidad. Por último, gvSIG sigue siendo un caso muy particular de muchas cosas, como expuso Jesús M. González Barahona en la ponencia de clausura.

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”.

Integrating Geotools into gvSIG CE (II)

Publicado el por
2

The gvSIG CE codesprint took place last week in Munich. Víctor and I had a great time working with all the people there, specially with Ben and Fran, the other developers.

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: Sigue leyendo →

Integrating Geotools into gvSIG CE

Publicado el por
2

After some work, we have managed to replace the gvSIG CRS module for Geotools. Here we are going to discuss what we have done, the cost of the task in hours, what we have achieved and some issues that have arisen.

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

Internacionalizando con jQuery.i18n e Internet Explorer

Publicado el por
Responder

Imagino que con un título de entrada así uno ya se imagina por donde van a ir los tiros del post.

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.

@geomati_co in GeoTools

Publicado el por
Responder

On these days the geomati.cos are a bit scattered. They had to stop in Velp (Holland) to talk about some projects at the MapWindow Conference. After this, one of them has gone to Salzburg (Austria) to continue with talks in the AGIT Conference, and others are already on their new temporary destination, Rome (Italy), working for FAO.
In between we have learned about OpenGeoGroep, a GIS freelancers cooperative, more or less what we’d want to become one day. Meanwhile we continue to work on our projects and are preparing others.
Just one more thing. Recently one of the geomaticos, Oscar Fonts, contributed to GeoServer and GeoTools a new transformation method using NADCON and NTv2 grids (see here in Spanish). Today people from GeoTools has posted on their blog that its source code has moved to GitHub, and int the image that appears…

Sorry, I’m a sentimentalist.

Ciao.

@ikiMap y la edición vectorial en Android

Publicado el por
Responder

ikiMap, comparte tus mapas, es un portal desarrollado para el intercambio de información geográfica. Es algo similar a lo que hace Youtube pero con nuestra información geográfica. Si no lo conoces te recomiendo que lo visites. Sixtema, la empresa que desarrolla ikiMap nos planteó la creación de la versión para Android de la plataforma, y eso hicimos. Una vez tuvimos los requisitos en mano, comenzamos a valorar las diferentes posibilidades que existían ya desarrolladas en las que apoyarnos. Dentro de todas las necesidades del proyecto, respecto a la parte geográfica estaban:

  • 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,

http://a.tile.cloudmade.com/8bafab36916b5ce6b4395ede3cb9ddea/8/256/>

http://b.tile.cloudmade.com/8bafab36916b5ce6b4395ede3cb9ddea/8/256/>

http://c.tile.cloudmade.com/8bafab36916b5ce6b4395ede3cb9ddea/8/256/,

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.

Nuevos métodos de transformación en GeoServer y GeoTools

Publicado el por
16

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.

Distorsión entre ED50 y ETRS89 en la España peninsularLa 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.

Distancia media entre los puntos en una hoja transformada por GeoServer y la misma hoja descargada del ICC

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.

Consola de reproyección en GeoServer 2.2

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.