Blog

gvSIG 2.0.0 - Cómo usar el plugin WFS (BN 2078) - WFS plugin usage hints

Tras las mejoras introducidas en el plugin WFS de gvSIG 2.0.0, ya es posible elegir el CRS en el que se realizan las peticiones así como la versión del protocolo WFS a utilizar (de entre los que ofrece el servidor). De este modo, casi siempre podremos evitar usar la versión 1.1.0 de WFS con un CRS en el que el orden de los ejes se haya invertido. Se realiza reproyección al vuelo para ajustarse al CRS de la vista. En este vídeo pueden verse varios ejemplos (disponible en alta defición): After the recent improvements in the WFS plugin of gvSIG 2.0.0, it is now possible to choose both the CRS used in our requests and the version of the WFS protocol to use (among the ones provided by the server). Therefore, we can in most cases avoid the combination of WFS 1.1.0 and a CRS with the new (inverted) axis order. On-the-fly reprojection happens automatically to match the CRS of our view. Some examples can be seen in this video (high definition available):

Uno de los servidores WFS de la IDEE funciona de modo extraño


En esta URL hay un servidor WFS de la IDEE:

http://www.idee.es/IGN-WFS-SIGLIM/ogcwebservice?

Haciendo tests para depurar el plugin WFS de gvSIG 2.0.0, veo que este servidor WFS tiene al menos dos errores aunque no muy importantes:

  1. El servidor dice ser de versión 1.1.0, sin embargo las geometrías se entregan con el orden de los ejes tradicional aunque el CRS sea geodético (longitud, latitud):

    -2.90101792242301,41.3255642175087
    -2.9028336707309,41.3259350724949
    -2.90666700724418,41.3276316778423
    ...

  2. Al hacer una petición con filtro geométrico con BBOX, no se devuelven las que intersectan con el rectángulo sino las que intersectan con el perímetro del rectángulo. Aquí deberían aparecer todas las provincias del SE de España, no solo las que tocan el borde del rectángulo:

Mejoras en el plugin WFS de gvSIG 2.0.0

Se están realizando mejoras en el plugin WFS de gvSIG 2.0.0 para que sea posible la reproyección al vuelo de capas WFS y próximamente la elección del SRS en el que se realizan las peticiones. Como anécdota, he encontrado este curioso servidor que proporciona sin contraseñas la planta de los ochenta y pico mil edificios de la provincia de Guipúzcoa. Esto es la iglesia neogótica de San Sebastián:

La tabla de atributos sólo muestra un ID y un NAME que es el nombre público del edificio, por tanto está casi siempre vacío:

Sistemas de referencia disponibles en el WMS 1.3.0 de CartoCiudad

La configuración de CRS del servidor WMS (versión 1.3.0) de IGN - CartoCiudad está bastante bien:

  • Se mantienen EPSG:23028-EPSG:23031 para compatibilidad con cartografía tradicional (ED50 + UTM).
  • Se incluyen los EPSG:25828-EPSG:25831 puesto que son los CRS proyectados oficiales para península y Baleares (ETRS89 + UTM).
  • Se incluye CRS:84 (además de EPSG:4326) para facilitar la vida a los clientes WMS que no soporten el cambio en el orden de las coordenadas.
  • Se incluye EPSG:900913 (aunque su nombre más oficial es EPSG:3857, creo) para permitir la integración inmediata con visores al estilo de Google Maps, OpenStreetMap, etc.
  • Sólo pueden echarse de menos los CRS canarios EPSG:4082 y EPSG:4083 (REGCAN95 + UTM) pero estos se consideran equivalentes a EPSG:32627 y EPSG:32628 (WGS84 + UTM) respectivamente, que sí están disponibles.

Las coordenadas EPSG:4326 en WMS 1.3.0: hay que romper una lanza a favor de la OGC

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.

Experimental SQLite/Spatialite layer in gvSIG Mobile

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.

Rendering local shapefiles with HTML5

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

Esta es la idea: establecer área de interés arbitraria sin perder velocidad

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:

Contra el vicio de pedir, la virtud de no dar

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.
Distribuir contenido