Archivo de la categoría: gvSIG

Probando MapProxy


Durante bastante tiempo hemos tenido a TileCache como «el producto» (libre por supuesto) a usar cuando queríamos montar un servidor de teselas que acelerara nuestros clientes web, usando TMS o WMS-C como protocolos de acceso. Desde hace un tiempo GeoWebCache ha ido tomando forma, lo que empezó como una beca para un Google Summer of Code se ha ido convirtiendo en un producto funcional. Pero desde hace tiempo ha llegado un nuevo chico al barrio, se llama MapProxy y tiene algunas características bastante interesantes.

MapProxy tecnológicamente hablando es un desarrollo escrito en Python, que permite desplegarse en lo que se llama un “entorno virtual” que permite aislar tu entorno de desarrollo del resto de tu sistema. Igualmente trae un sencillo servidor web para desarrollo y para usarlo en producción debemos acudir a FastCGI o bien a WSGI, un estándar Python para desplegar aplicaciones web. El despliegue por tanto es más o menos similar al de TileCache.

MapProxy no sólo se expone como un servidor TMS o WMS-C, también y esta es su mayor diferencia, se expone como un servidor WMS normal. Es decir, a partir de los orígenes que definamos y que se irán almacenando cacheados en disco, además de como servicios de teselas MapProxy también podrá atender a peticiones que caigan fuera de los límites de dicha cuadrícula. Para ello compondrá y reproyectará si fuera necesario la imagen al tamaño y sistema de referencia requerido.

Esto abre escenarios muy interesantes, por ejemplo usar nuestras caches con clientes pesados como gvSIG y no sólo tirando de servicios WMS existentes sino también de otros que únicamente fueran servidos mediante TMS. Es decir, por decirlo de forma sencilla, podemos montar un WMS de OpenStreetMap. Claro que un origen como OSM no se verá muy bien en las zonas intermedias entre resoluciones de la caché porque las etiquetas y elementos lineales se distorsionarán bastante. Pongo un pequeño ejemplo a una escala bastante grande, de cómo se vería OSM en gvSIG.

Más usos: cachear OSM u otros orígenes muy frecuentados en nuestra organización (como por ejemplo el PNOA), permitiendo a nuestros técnicos no sólo consumir estos datos desde clientes ligeros de visores corporativos sino también desde clientes pesados claro. Podríamos limitar esas caches tanto en su extensión geográfica, como en su duración temporal así como en su espacio ocupado en disco porque  MapProxy también añade bastante «azúcar» en la parte de la generación y mantenimiento de sus caches, pero esto lo dejaré para otro día.

Desgraciadamente MapProxy aún no soporta el estándar WMTS aunque diría que esto se resolverá en poco tiempo y hace otras cosas interesantes como redirigir las peticiones getFeatureInfo y getLegendGraphic a las capas originales, cosa que TileCache (si no me equivoco) tampoco hace.

Instalar MapProxy en una distribución GNU/Linux moderna es bastante sencillo, la documentación es muy buena (usan mi querido sphinx) y su lista de correo es bastante activa como para ir salvando cualquier escollo que vayamos encontrando.

En este enlace a pastebin dejo una configuración básica bastante autoexplicativa en la que se sirven dos capas, la de OSM de la figura anterior y también el WMS-C del PNOA. Me hubiera gustado conectar al PNOA mediante el protocolo TMS pero no ha habido manera, al final he usado una capa WMS, teniendo que eliminar los metatiles porque MapProxy los usa por defecto en capas WMS. En cualquier caso el ejemplo funciona a la perfección.

A continuación dejo un pantallazo de gvSIG mostrando en dos vistas el PNOA en vivo y el cacheado, se puede ver que no hay diferencia apreciable entre ambos. Lo que se ve por cierto es el Gulliver de Valencia, un parque rompepantalones muy popular.

Como conclusión a este ¿primer? artículo sobre MapProxy simplemente recomendar su evaluación si se tiene que desplegar un servidor de teselas nuevos y el entorno tecnológico es el adecuado. Servir WMS a partir de caches añade una funcionalidad que en determinados escenarios puede ser más que interesante.

Máquinas esclavizadas


Acabo de llegar a un documento (PDF) elaborado por el Ayunamiento de Zaragoza, “Migración Escritorio Software Libre” y después de ver el índice (son 113 páginas, tiene muy buena pinta) me doy una vuelta buscando por el término CAD, directo a donde duele y leo (pág. 26):

En algunos casos especiales, ciertas máquinas han quedado esclavizadas con el sistema operativo Windows, hasta que se encuentre una solución de aplicativo libre compatible con las necesidades de los usuarios o alguna manera de que esta aplicación privativa funcione en el Escritorio libre (aplicaciones CAD – diseño asistido por ordenador – por ejemplo).

30/07/09 - Facepalm

Bimba! Era esperable, los usuarios de CAD son siempre los más “resistentes” a las migraciones porque no hay una alternativa real a las necesidades que tienen (o creen que tienen). Hay soluciones parciales, como algunos CAD libres o incluso ya más cerca del mundo GIS como gvSIG, pero Autodesk lo ha hecho bien estos últimos años y su vendor lock-in va a ser duro de romper. Lo único ahora mismo cercano a romperlo sigue siendo un CAD privativo, Bricscad ya que tiene versión para Linux. Pero da lo mismo, seguro que no gustará a delineantes, topógrafos, arquitectos y demás técnicos porque le falta la última chorradita del susodicho AutoCAD y por tanto seguirán llevándo de cráneo a los responsables de las migraciones de sus organizaciones.

La foto la pongo porque esa es seguro la expresión del administrador de sistemas cuando lee un correo de un técnico diciendo que su CAD favorito es irreemplazable :-)

Consideraciones sobre el SIG libre en España


Vía un twitt de Álvaro Anguix rescato este artículo de Víctor Olaya en Consideraciones sobre el SIG libre en España (PDF),  editorial del número 10 de la revista Geofocus:

Y si algo me parece claro tras este tiempo es que la intensidad de todo ese movimiento, del que he sido testigo y partícipe, así como la constante sensación de actividad que transmite, hacen augurar un buen futuro. El tren de los SIG libres en el que estamos subidos parece ser una buena opción y, de seguir así, le queda aún mucho por recorrer.

En un conciso resumen de Víctor del estado del SIG libre en España rescato esta frase final porque me siento identificado, como partícipe también de aquellas primeras jornadas de SIG Libre y en general del movimiento de software libre para la geomática a través de mi participación en Prodevelop, gvSIG,  OSGeo y OSGeo-es. ¡Y lo que nos queda!

OSGeo anniversary, 5 years of freedom


These days OSGeo celebrates it’s 5th birthday, so I’ll try to answer some of the Tyler’s questions about where I was five years ago and more ore less what I’ve been doing on OSGeo for this time. It’s funny because it’s also my 5th anniversary at Prodevelop and working actively on the gvSIG project so it’s not just a matter of OSGeo in the end.

Five years ago I was working with an scholarship at the Polytechnic University of Valencia doing some research on GIS for Public Local Administrations and giving postgraduate courses on MapServer as a result of my final degree work. But the scholarship ended how to say… abruptly, thus I found myself out of the university I was studying and working since 1997.

Anyway, just two weeks later I started working at Prodevelop. I was really lucky because Prodevelop was looking for a cartographer well biased on computer science (my predecessor was impossible to be compared of but, well, they gave me a chance) so I started to work on a project to build the ArcIMS driver of gvSIG with Miguel Montesinos, Juan Lucas and Javier. Those days Prodevelop was a 25 people company, today we are more than 70, with a GIS team of 15 people more or less.

I started soon to take part on OSGeo, mainly at my free time translating the website into Spanish. Miguel and me attended FOSS4G in Lausanne and was a great experience, the Spanish Local Chapter started next year with the first FOSS4G meeting in Girona thanks to Lorenzo Becchi and Luis Sevilla who coordinated the kick off for the Local Chapter.

Afterwards gvSIG joined OSGeo and my relationship with OSGeo grew from only on my free time to being part of my daily tasks, like participating on the OSGeo Live DVD project, presenting OSGeo and OSGeo-ES anywhere (from Valencia to Caracas) or participating as a gvSIG lecturer on last year FOSS4G workshops.

On those years I’ve made so many friends that I can only say I’m very proud to take part of this big community. I’m a not-so-good developer and most of my time at gvSIG project is doing coordination and helping others to develop new cool things but anyway, OSGeo and gvSIG are big efforts that need help of very different roles so I don’t find myself out-of-place. On the contrary, I enjoy a lot participating at OSGeo and OSGeo-ES, even when there are some not good aspects (like having to see privative software companies sponsoring FOSS4G) the general balance is without any doubt positive.

Happy birthday OSGeo community!!

 

Hackeando el diseño


Hay un hilo en la lista de usuarios con unas interesantes instrucciones de Enrique Lorenzo sobre cómo cambiar el aspecto de gvSIG: el splash, iconos, etc. Esto que a él le soprende y a muchos otros les puede parecer una soberana tontuna a mí me parece de lo más lógico. Los splashes que desde hace tiempo va proponiendo Woflgang Qual, los nuevos de OA…, todos llevamos un (más o menos frustrado) diseñador dentro y, si el software nos deja, nos gusta cambiar el aspecto de las herramientas que estamos viendo a diario. Sería algo parecido a cambiar el fondo de escritorio del sistema operativo, pero llevado a las aplicaciones, como los skins en los navegadores, etc.

Propuesta de splash "a la caza del bug"

Tal vez sería una buena idea para la próxima gran revisión de gvSIG convocar un concurso de pantallas de inicio, para darle un poco de vidilla a la comunidad y aprovechar esos enormes talentos que hay por ahí sueltos…

Arrancando la consola de fondo en gvSIG


Un pequeñó truco de gvSIG,  rápido y sucio ;)

Si tenéis la instalación de Windows de gvSIG veréis que haciendo doble click en el .exe este arranca sin la conocida consola de comandos de fondo.

A veces, sin embargo, es preferible tenerla, para poder ver determinados mensajes, por ejemplo si estás conectando a un WMS que falla, poder ver el porque.

Sigue leyendo