Se comenta mucho el cambio entre las versiones 1.1.1 y 1.3.0 del protocolo WMS de la OGC en lo que se refiere al orden de las coordenadas (longitud y latitud) al usar el sistema de coordenadas EPSG:4326. Creo que la situación puede resumirse más o menos así:

• Tras detallar los parámetros del geoide y esas cosas, EPSG:4326 asocia una semántica para los ejes 2D (un eje corresponde a la latitud y el otro a la longitud) y además establece (aunque quizá de manera no muy explícita) que la primera coordenada debe ser la latitud y la segunda, la longitud. Según los expertos en geodesia, este orden se considera una "buena práctica" por motivos que desconozco (click para agrandar):

  

• En WMS 1.1.1 se estaba obviando el orden sugerido en el sistema de coordenadas EPSG:4326 y el rectángulo de interés pedido por el cliente era:

  ...BBOX=lon_min,lat_min,lon_max,lat_max...

• La OGC decidió, a partir de la versión 1.3.0 de WMS, acatar el orden establecido o sugerido en la definición de EPSG:4326 y desprenderse del prejuicio según el cual la coordenada asociada a los términos "X", "horizontal", "longitud" debe ir antes que la coordenada asociada a los términos "Y", "vertical", "latitud".

  Así pues, al usar EPSG:4326 en WMS 1.3.0, el área de interés se expresa así:

  ...BBOX=lat_min,lon_min,lat_max,lon_max...

• Siendo consciente de que esto puede ser un problema para muchos clientes WMS, la OGC sugiere en cierto modo el uso el código CRS:84, que es lo mismo que EPSG:4326, pero con el orden antiguo (longitud, latitud). Es decir, la OGC sugiere a los administradores de servidores WMS 1.3.0 que ofrezcan el sistema de coordenadas EPSG:4326 para ser usado con el orden riguroso (latitud, longitud) y además ofrezcan el sistema de coordenadas CRS:84, que es exactamente lo mismo, pero usando el orden antiguo (longitud, latitud). De esta manera, si tenemos una aplicación cliente que no contempla el cambio de orden, el usuario final debería elegir CRS:84 en la lista de sistemas de coordenadas disponibles cuando el servidor es WMS 1.3.0 para obtener el mismo comportamiento que obtenía eligiendo EPSG:4326 cuando el servidor era WMS 1.1.1. Lógicamente, esta opción sólo estará disponible si el servidor ofrece el sistema de coordenadas CRS:84.
• Hay que romper una lanza a favor de la OGC porque, a la larga, conviene desprenderse de convenciones injustificadas, elevar la flexibilidad y el nivel de abstracción de los protocolos y evitar la incoherencia de usar un orden de coordenadas distinto al que establece el propio sistema de coordenadas que estamos usando.

Xerial is a SQLite JDBC driver developed by Taro L. Saito. It includes the necessary native libraries to access SQLite databases from a Java application and it also provides a slower pure-Java version of it which extends the number of platforms where this can be used.

I have implemented an experimental vector driver in gvSIG Mobile 0.3 to read/write Spatialite-compatible SQLite databases. Xerial is not aware of the Spatialite requirements, but it's very easy to create the right tables and fields so that other applications can recognize the resulting SQLite file as a Spatialite DB.

This short video shows the result. The steps shown are:

1. Open a shapefile in gvSIG Mobile.
2. Export the layer to SQLite.
3. Open the resulting SQLite DB as a new layer.
4. Add a polygon to the layer and save it.
5. Use ogr2ogr to export the resulting SQLite DB to SHP. This proves that everything was OK and our file is recognized as a Spatialite DB.
6. Open the new shapefile in gvSIG Mobile to see the changes again.

Thanks to Tom Carden's javascript functions from his shapefile-js project and the new HTML5 local file access API, it is very easy to load and render any shapefile stored in the client's device.

You can test it here.

If you don't have a shapefile close at hand, get one of these: [China], [Europe], [South America], [United States].

Comments:

• I have only tested it on Windows 7 + Google Chrome v. 15.x and Mozilla Firefox 8. I'm curious to see if it works on smartphones.
• Choose a line or polygon SHP file (not a very big one).

En este ejemplo en desarrollo se trata de una tabla Oracle Spatial en la que hemos filtrado el área de interés señalada "a mano alzada" por el usuario:

Hace relativamente poco vi por primera vez este mensaje en gvSIG, al intentar poner en edición una capa vectorial reproyectada al vuelo:



Si uno lo piensa, se da cuenta de que nunca o casi nunca puede tener sentido poner en edición una capa cuyo SRS en origen es diferente al de la vista. La edición es algo parecido a la cirugía. No tiene sentido afinar a mano la posición de los vértices para después reproyectar a otro SRS, cuando sabemos que esta reproyección va a introducir errores casi con toda seguridad. Por otro lado, el implementar la edición y la reproyección simultáneas, aunque pueda parecer sencillo, nos lleva a dificultades inesperadas: ¿qué pasa si se trata de una reproyección con parámetros especiales o con rejilla? ¿sabremos siempre calcular esa reproyección inversa? ¿es posible que la reproyección inversa sea más imprecisa que la reproyección directa original? etc. Al final, estamos dedicando recursos a intentar resolver un problema al cual no deberíamos haber llegado. Como dice el diálogo, lo razonable es reproyectar primero la capa y editarla después, o viceversa.

Edición de capas gigantes

Otro caso quizá no tan claro es el permitir que se ponga en edición una capa con varios cientos de miles de geometrías. Hay dos casos mucho más comunes que el resto: editar un shapefile gigante (que es relativamente factible, salvo casos verdaderamente extremos) o bien editar una capa GeoBD gigante (generalmente PostGIS u Oracle Spatial).

Este segundo caso sí da problemas graves en un número no pequeño de casos, puesto que no es raro tener una base de datos geométrica en la que hay tablas con cientos de miles o incluso millones de registros.

Afortunadamente, el diálogo de creación de capas GeoBD prevé la inserción de restricciones geométricas o alfanuméricas en el momento de añadirlas a nuestra vista, de modo que la capa creada es relativamente ligera en comparación con la tabla enorme en la que se apoya. Esa es, en mi opinión, la vía correcta para editar tablas geométricas gigantes, y hacia ahí hay que procurar reconducir al usuario. Llegado el caso, habría que mostrar al usuario un mensaje que dijera por ejemplo: "No es posible iniciar la edición de esta capa GeoBD porque tiene más de 300.000 registros". El umbral no permitido podría calcularse en el momento, dependiendo por ejemplo de la potencia del PC, o se le podría preguntar a la capa (es decir, al driver) si en la actual situación (número de registros y vértices, velocidad estimada de la red) se considera capaz de aceptar el modo de edición.

¿Una negativa es siempre mala?

Si permitimos que el usuario use opciones en condiciones que nos llevan a procesos larguísimos o muy complejos, nos arriesgamos a que el comportamiento de la aplicación sea substandard, como diría Steve Jobs, es decir, no usable, de modo que el usuario se frustra porque no se da cuenta de que lo que ha pedido implica una cantidad de cálculos inimaginable, y además hay otras vías mucho más adecuadas para conseguir lo mismo. A partir de ese momento, ese usuario va a difundir la idea de que la aplicación no funciona bien, y si por casualidad tiene un blog con unas cuantas visitas al mes, el daño puede ser tremendo.

En cambio, si denegamos la petición (o al menos informamos de que lo que va a hacer es poco recomendable y le ofrecemos una alternativa explicada en un diálogo informativo), estamos evitando esa situación de la que no saldremos bien parados.

Por decirlo (quizá) exageradamente: en el 98% de los casos, el usuario no necesita editar una capa reproyectada al vuelo ni poner en edición un millón de geometrías, y se le puede y debe reconducir a la opción razonable. En el 1% de los casos, se trata de un usuario curioso que prueba casos extremos para ver cómo se las arregla la aplicación, y sólo en el 1% restante se trata de usuarios que realmente necesitan poner en marcha esos procesos tan exigentes, y además han sido capaces de hacerlo antes con algún otro software. En este último caso, se trata objetivamente de una derrota nuestra, pero casi siempre habrá otro motivo por el cual gvSIG es preferible: su licencia GPL, sus muchas otras funcionalidades, el tamaño de la comunidad, etc.

gvSIG Association has developed for the Deputación Provincial de Pontevedra a new gvSIG extension for generating printable map series in a professional way.

In coordination with Cartolab (*), Prodevelop SL has developed this new gvSIG extension that lets you automatically create series of maps. These are either sent directly to an available printer or stored as PDF files.

After choosing some simple creation options, a new special layer (or grid) is added to your view, where each rectangle represents the extent of the map which will be printed in each single map sheet. This grid can be modified with an ad-hoc fast-editing tool to add, remove and drag the grid's frames:



Then you can tune the map layout in the traditional way, while you preview each sheet with the help of a floating dialog:



Finally, you can choose to send all the sheets to your printer or store them as PDF files in your hard drive:



This extension will work with the upcoming gvSIG 1.12. Visit its web page here for full documentation and downloads.

————

(*) The gvSIG Map Sheets extension (gvSIG EIEL printing module) has been funded by the Deputación de Pontevedra in association with Dirección Xeral de Sostibilidade e Paisaxe de la Consellería de Medio Ambiente, Transporte e Infraestruturas de la Xunta de Galicia to the gvSIG Association.

After georeferencing with gvSIG this image from Las Provincias newspaper archives website, and using the transparency options, we can see the areas affected by the historical 1957 flood which triggered the development of the new riverbed which bypasses the city to the south.

(Click on image to enlarge)

I thought that tweeting "I'm having lunch @ somewhere" was as narcissist as one can get, but I was totally wrong:

El diario El País ha publicado los resultados de las elecciones municipales y autonómicas del 22 de mayo de 2011 en formato XML, de modo que la URL de cada archivo XML utiliza los códigos INE de cada municipio. Por ejemplo, el código INE de Sevilla es 41091, por tanto la URL del XML con los resultados de Sevilla es:

http://resultados.elpais.com/elecciones/2011/municipales/01/41/91.xml2

El 01 es el código asociado a Andalucía. Este es el aspecto del archivo XML:

Por otro lado en la web del IGN se puede descargar un shapefile de centroides o polígonos de cada municipio y una de los atributos de cada elemento es precisamente el código INE.

A lot of info about the recent 4th Italian gvSIG conference (Quarte Giornate italiane di gvSIG) held in Udine can be found here, here and here.

I'm going to add a couple notes about things that came up during this event regarding gvSIG Mobile.

Field-oriented features

I had the pleasure of meeting Giuliano Gallerini who works for Leica Geosystems in Italy. According to him, gvSIG Mobile looks too much like a simplified version of gvSIG desktop and does not include some very interesting features that make sense only when you are doing some field work with a hand-held device. These are the two examples he seemed to be especially interested in, which obviously need the help of some additional hardware, for example, this one.

Shifted acquisition of points

The acquired points are shifted by a certain value (entered by the user when the operation starts) in order to overcome some physical obstacle:

Simple triangulation

In this case, the user has to measure the three sides of a triangle, where one of the vertices is unreachable. There are two possible values for the third vertex. The good one is the one that lies behind the obstacle:

SQLite and Spatialite

Alessandro Furieri presented Spatialite and asked when gvSIG will support it. I mentioned a funny pure Java version of SQLite and he replied he knew it but it was very slow and did not recommend it at all. I have just found a second pure Java version of it.

I still believe these pure Java libraries can be useful in a mobile application for a number of resons:

• We are currently seeing a boom in the mobile industry. Every few months we have new platforms (new hardware, new operating systems or both). Java applications need in the first place a JVM. If a third-party library has a native component which needs to be compiled for each platform, we're losing portability, which is Java's advantage.
• This pure Java library is probably slower than the one with the native component, but I think the future in mobile mapping applications is not about handling huge amounts of geopraphical data, but smartly handling a relatively small amount of data, which should be feasible also with a relatively slow version of SQLite.
• I still have not seen a pure Java version of Spatialite, but I think the spatial metadata needed in a Spatialite database file can be created by using SQLite after studying a bit the Spatualite documentation.