Archivo de la categoría: FOSS

Cómo instalar la toolbox de LAStools en QGIS


El conjunto de herramientas LAStools para procesar datos LiDAR están disponibles en el software propiertario ArcGIS desde abril de 2012, pero no ha sido hasta el FOSS4G13 de Nottingham que no han estado disponibles para QGIS. Las herramientas han sido testadas en QGIS 1.8.0-Lisboa y 2.0.1-Dufour. En esta entrada os enseñamos el modo de installar LAStools en QGIS y, básicamente, es la traducción y adaptación del manual de instalación que se encuentra en el blog de Martin Isenburg aka rapidlasso.

Nos centraremos en instalar las herramientas en la versión de QGIS 2.0.1-Dufour, por lo que lo primero que necesitamos es descargar e installar dicha versión. A partir de entonces, seguiremos las siguientes instrucciones:

  1. Si tienes abierto QGIS, ciérralo

  2. Borra la carpeta donde está contenido el plugin de LiDAR en sextante. La ruta para los usuarios de Windows es:

    "C:\Program Files\QGIS Dufour\apps\qgis\python\plugins\processing\lidar"

    La ruta para los usuarios de GNU/Linux es

    ~/.qgis/python/plugins/processing/lidar
  3. Copia la carpeta lidar que está en este archivo comprimido en el lugar de la carpeta borrada.

    Nota: Los usuarios de QGIS 1.8.0-Lisboa tienen que sustituir la carpeta lidar dentro de:

    "C:\Program Files\QGIS Dufour\apps\qgis\python\plugins\sextante\lidar"

    o si utilizas GNU/Linux, dentro de:

    ~/.qgis/python/plugins/sextante/lidar

    por la que se encuentra en este otro archivo comprimido.

  4. Descarga la versión más reciente de las LAStools que se encuentra en lastools.zip.

  5. Extrae la carpeta lastools. Si estás usando Windows, procura no estraerlo en ninguna ruta con espacios, si estás en GNU/Linux tendrás que compilar las herramientas.

  6. Inicia QGIS, y si encuentras algún error cuando se carge el script de Python, repite los pasos de 1 a 3 con más cuidado ;)

  7. Habilita el toolbox que se encuentra bajo el menú procesing como se muestra en la siguiente figura:

    images/qgis_2-0_menu_toolbox.png

  8. Cambia el toolbox de Simplified Interface a Advanced Interface, imágenes de la izquierda y derecha respectivamente:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_simplified.png?w=625   http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_advanced.png?w=625

  9. Abre el submenú Options and configurations de la pestaña Processing como se muestra a continuación:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_opts-config.png?w=625

  10. Activa la casilla Activate que se encuentra en Providers -> Tools for LiDAR data como se muestra en la siguiente figura, e introduce la ruta de la carpeta donde estén alojadas las LAStools en LAStools folder:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_activate.png?w=625

  11. Ahora deberías ver el conjunto de herramientas Tools for LiDAR data en el toolbox y todas las LAStools como en esta figura:

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_lasinfo.png?w=625

  12. Inicia cualquier comando mediante un doble click y rellena las opciones. En la siguiente figura se muestra la interfaz de lasinfo.

    http://geomaticblog.files.wordpress.com/2013/10/qgis_2-0_lasinfo_interface.png?w=625

Tened en cuenta que, al distrubuirse el código de manera libre sólo de unas pocas herramientas, los usuarios de GNU/Linux tendrán menos funcionalidades disponibles. No así los usuarios de Windows, cuyas herramientas se distribuyen como shareware.

Martin Isenburg agradece a Victor Olaya por crear todo el entorno de sextante para crear nuevos plugins y por los ejemplos de cómo crear módulos. Al igual que él, yo también agradezo a Victor todo el trabajo porque también estoy trasteando con la creación de módulos dentro de sextante :P

Herramientas Libres para trabajar con datos LiDAR


En los últimos años ha proliferado el uso del LiDAR como técnica topográfica. Básicamente, consiste en un telémetro láser que mide el tiempo que tarda una pulso láser en ir y volver después de haber rebotado en un objeto. De este modo consigue hallar la distancia entre el instrumento y el objeto. Es decir, es sencillamente un distanciómetro, pero con la particularidad de que puede llegar a medir unos 100000 puntos por segundo (100 MHz). Si, además, incorporamos a los equipos de medición un GPS que nos dé la posición y un sistema inercial que nos de la orientación si estamos en movimiento, podemos dar coordenadas globales, normalmente en el sistema WGS84, a todos los puntos medidos. Por tanto, tendremos lo que se denominan nubes de puntos de los cuales conoceremos su posición en un sistema de referencia global, además de otras características relativas al objeto, como la intensidad o diferentes ecos de retornos, o referentes a la medición como ángulo de emisión del pulso, tiempo o distancia relativa al sensor.

Las compañías que desarrollan instrumentación LiDAR, ya sean telémetros aerotransportados, dando lugar a lo que se denomina en inglés Airborne Laser Scanning (ALS), o telémetros terrestes, Terrestrial Laser Scanning (TLS), también desarrollan su propio software destinado a:

  1. Extraer los datos del equipo de medida y ofrecer los datos en algún
    formato propio o, al menos, conocido.
  2. En algunos casos, hacer post-proceso de dichos datos y obtener productos
    cartográficos finales.

Sin embargo, como en el ecosistema de los GIS, existe un software privativo que monopoliza casi todo el mercado del software para realizar los trabajos de post-proceso. No voy a dar el nombre de ninguno de estos paquetes porque el objetivo de esta entrada es justamente la contraria, exponer las posibilidades existentes para utilizar software libre a la hora de trabajar con datos LiDAR.

Lamentablemente, para extraer los datos de la mayoría de los equipos actuales no hay alternativas y necesitamos utilizar obligatoriamente software privativo. Comprar la licencia no es el verdadero problema, porque si tenemos dinero para comprar un equipo que cuesta varias decenas de miles de euros es que también podemos comprar al menos una licencia por un par de miles. Lo peor es lo que verdaderamente implica el software privativo, es decir, que no eres libre de hacer lo que quieras con producto adquirido. Sin embargo, si alguien quiere hacerse un telémetro láser, puede utilizar el módulo para la captura de datos de las librerías PCL, ya que soporta algunos dispositivos conocidos. Pero sobre la librería PCL y otras más hablaremos más datelladamente en otra entrada. Además, en la mayoría de los casos, cuando podamos acceder a datos LiDAR, estos estarán ya en un fomato conocido. Lo lógico es que obtengamos los datos en el formato LAS que es el formato estándar que define la ASPRS (American Society for Photogrammetry and Remote Sensing).

Hay varias librerías libres para la lectura y escritura de archivos en este formato LAS. La decana de ellas es LASlib. Está desarrollada y mantenida por Martin Isenburg y está escrita en C++. Está licenciada bajo LGPL, por lo que se puede utilizar en otros paquetes, aunque sean privativos. Al descargar estas librerías y compilarlas genera unas herramientas llamadas LAStools que sirven para la gestión de archivos LAS (las2las, lasmerge), para creación de LAS a partir de archivos de texto (txt2las) o archivos de texto a partir de LAS (las2txt), para dar información sobre archivos (lasinfo, lasprecision, lasdiff) o para crear un índice espacial de los puntos dentro de los archivos (lasindex). En las últimas versiones, también se crea la herramienta laszip que sirve para comprimir archivo LAS. El formato de salida es LAZ y el archivo de comprimido ocupa SOLO entre el 7% y 20% del tamaño del archivo original. A todo esto hay que añadir que con la librería LASlib también se distribuye otra librería para leer y escribir formatos LAZ, también en C++ y también con licencia LGPL. Para los usuarios de windows, además, están disponibles otras herramientas precompiladas, de las cuales no voy a dar detalles porque no son libres, sino que son shareware.

De la librería LASlib se hizo un fork y nació la librería libLAS, que está bajo el auspicio de OSGeo. También escrita en C++ pero incorporan bindings para una gran cantidad de lenguajes de programación. También incorpora herramientas para la gestión de archivos en formato LAS y texto, que se llaman de igual manera que las LAStools, aunque la utilización de los comandos pueda variar. Las diferencias que existen actualmente entre ambas librerías se pueden encontrar aquí.

La librería SPDLib es bastante reciente. Tanto es así que empezó a desarrollarse en el verano de 2011. El formato estándar que utiliza para trabajar con datos LiDAR se denomina precisamente SPD (Sorted Pulse Data) y está basado en el formato HDF. Es un formato de datos ordenados e indexado que está optimizado para el acceso rápido a los datos y en el que es posible trabajar con toda la señal del pulso de retorno, en inglés full waveform, no sólo con ecos discretos, como hace las librerías anteriores. Y precisamente ésta es una de sus grandes virtudes. Por lo demás, está en consonancia con las librerías ya vistas. Está desarrollada en C++, con bindings para python e IDL, y con licencia GPL. Al compilar se crean una serie de herramientas para la gestión, manipulación e información de archivos SPD, así como una herramienta imprescindible para transformar entre formatos LAS y SPD. Otra de las ventajas que presenta es que incorpora utilidades para generar modelos digitales en cualquier formato soportado por gdal, y para aplicaciones forestales. ¡Todas ellas libres! Sin embargo, al ser desarrollada principalmente por una sola persona y ser tan reciente, uno de los problemas que presenta es la escasa y, en algunos casos, inexacta documentación.

Sin duda, existen más librerías capaces de trabajar con datos LiDAR pero con otros propósitos distintos a los que hemos cubierto aquí. Las intentaremos tratar en otras entradas. Manteneos atentos.

PD: Mientras escribo estas líneas me llega un tuit en el que hablan de otra libreria
en python para leer y escribir datos LiDAR en formatos LAS. Se llaman laspy :)

OpenLayers Cookbook


OpenLayers CookBook

I’ve been honoured to help Antonio to produce this book as a technical reviewer so I owe him at least a short note here (well in fact I promised him to do it!). Having the opportunity to review the book itself has been a great pleasure and an enriching experience, always with the help (and patience) of the Packt people over eight weeks of work. There are some good reviews of the book here and here so I won’t repeat what’s so well described there, take a look on them to see the contents covered and their (good) feedback on the book.

If you know some HTML and JavaScript and really want to get introduced on how to build geospatial web applications, I vividly encourage you to get this book and go beyond the basics with meaningful recipes that step by step, showcase the most important parts of the OpenLayers API.

In my experience, one can start from scratch with the examples but there are many concepts that is better to understand well, like the difference between formats, protocols and strategies (that I finally understood back in 2009, thanks to this great presentation by Tim Schaub). That and more is well covered through examples, really easy to follow and reproduce. Thus I think it’s a good investment to take a book and let someone to tell you how the thing works, isn’t it?

Ah, and as Alper has written on his review:

Please buy the book to support writer instead of downloading the illegal copies. This will courage more people to write this kind of books to support Open Source projects like OpenLayers.

Instalando MapProxy en windows, paso a paso


La semana pasada tuve el placer de formar parte de los formadores de los voluntarios de EUROSHA, un grupo de 25 jóvenes destinados a levantar cartografía en diversos países de África, como parte de las actividades del HOT. Uno de los problemas a los que se enfrentan estos voluntarios es una conexión a internet no muy fiable.

Es perfectamente posible editar datos de OSM offline (guardando los datos a fichero, editando, y resolviendo conflictos de versiones a posteriori), pero lo que no se puede hacer es consultar cartografía de fondo para comparar. Había que hacer algo al respecto. Y la solución fue instalar MapProxy, que permite tomar imágenes ráster de varias fuentes y servirlas como WMS, en local. En un portátil con linux (y python, python-pil y python-pip), instalarlo y probar la configuración por defecto fue una cuestión de minutos.

Ahora bien, los ordenadores que el HOT va a desplegar en África van con windows, principalmente por no disponer del tiempo suficiente para hacer una instalación completa con las herramientas adecuadas para la situación. Improvisemos pues, e instalemos MapProxy tal y como sugiere el manual

We advise you to install MapProxy into a virtual Python environment.

Bueno, pues no hagáis esto. Al instalar python desde cero, lo más probable es que os encontréis con problemas a la hora de instalar las librerías necesarias, en concreto PIL (Python Imaging Library). La manera sencilla de instalar Python para hacer funcionar MapProxy encima es OSGeo4W. Así que descargamos el instalador, elegimos una instalación avanzada, y nos aseguramos de que al menos los paquetes para python y python-pil se van a instalar:

El siguiente paso es descargarse distribute-setup.py y ejecutarlo dentro de una shell de OSGeo4W como administrador:

En esa misma consola, ejecutamos un easy_install mapproxy, y justo después un easy_install pyproj:

En este punto, los ejecutables de MapProxy ya están instalados. Lo podemos comprobar ejecutando mapproxy-util:

Ahora bien, MapProxy es inútil sin un fichero de configuración que le diga qué servicios tiene que cachear. Así que hacemos copia-pega de una configuración de MapProxy para OpenStreetMap, guardamos el fichero resultante como (por ejemplo) C:\OSGeo4W\mapproxy.yaml, y lanzamos mapproxy-util:

¡Et voilà! Nuestro MapProxy está funcionando y respondiendo a peticiones desde localhost:8080, cacheando tiles de OSM para convertirlas en un servicio WMS:

El resto de opciones se pueden consultar en el manual de MapProxy, pero hay unas cuantas cosas a tener en cuenta:

  • MapProxy siempre debe ejecutarse dentro del entorno de OSGeo4W.
  • … lo que quiere decir que si queremos que se ejecute automáticamente, se puede hacer un .bat haciendo copia-pega de C:\OSGeo4W\osgeo4w.bat, y modificando el comando que se lanza en la última línea de ese script.
  • La utilidad para inicializar o refrescar la caché, mapproxy-seed.exe, ha de ejecutarse también dentro del entorno de OSGeo4W.
  • Los datos cacheados se almacenan en el directorio que se especifique en el fichero de configuración, y es relativo a la ruta donde se lanza mapproxy.

¡Hazme un mapa de España! … ¡y bien rápido!


Ostras como se ponen los jefes de vez en cuando y claro, cuando vas y estiras del hilo te enteras que sobre el supuesto mapa de España van a pintar con chorricientos colores y necesitan que se vea bien a cualquier escala y que tenga el entramado de las calles, pero también salgan las provincias y puedan hacer zoom y pintar sobre las provincias… ¿no os suena?, jopé que suerte, a mi me pasa a menudo…

Así que en esta entrada vamos a intentar dar una solución planteando un mapa desaturado para poder pintar en colorines sobre él, el mapa tendrá orígenes de datos fáciles de conseguir – y libres – y utilizará un stack de software libre para construirlo… así que tendréis un mapa rápido [ish], fácil y bonito [ish]…

Sigue leyendo

VI Jornadas de SIG Libre de Girona, Marzo 2012


Siempre supone un motivo de ALEGRÍA -así, en mayúsculas- lanzar el anuncio de la celebración de las Jornadas de SIG Libre de Girona. Y resulta un motivo de alegría y de felicidad por dos motivos básicos el primero de los cuales, es porqué se trata de un evento, el de las jornadas de SIG Libre, que nos apetece organizar, un proyecto al que queremos sin condición alguna. En segundo lugar, porqué significa que continuamos en la brecha, muy a pesar de la crisis que amenaza y atenaza al sector en los últimos tiempos. Así que es natural que nos sintamos doblemente orgullosos de las jornadas de Girona que, como ya viene siendo costumbre, continúan ejerciendo su función de escaparate y de altavoz de las soluciones libres para SIG.

Como en cada nueva edición, os presentamos un programa de ponencias plenarias que esperamos sinceramente que os resulten de interés. Las charlas plenarias de las Jornadas, intentan abarcar temas y aspectos que si bien, en ocasiones no son meramente geográficos, sí pueden conectar con la naturaleza de los SIG y de los datos geográficos de un modo u otro. Se trata de ampliar puntos de vista, de desplazar ligeramente el foco sobre temas que van más allá de los SIG, que son tangenciales o extrapolables a nuestro sector o campo de aplicación, con el ánimo de ampliar el abanico de visiones acerca de todo aquello que sea libre.

Así pues, es tiempo de reencontrarse, de compartir y de continuar aprendiendo, de reconocer viejos gestos y caras conocidas, y descubrir nuevas experiencias, proyectos, y oportunidades de colaboración y de negocio. Y es que las Jornadas, en esencia, son esto, un escenario en el cual mostrar el “cómo” y compartir el “qué”. Son tiempos complicados, y es tiempo para la innovación y la inversión en las soluciones libres, tiempo para realizar la apuesta definitiva.

Un año más, una edición más, os emplazamos a que visitéis Girona y que participéis de forma activa en la mejora constante de este evento. Estáis en casa, y os esperamos:

www.sigte.udg.edu/jornadassiglibre

Comité Organizador Local.

OSM + ImpOSM + TileMill


Hacía tiempo que no le dedicaba un ratillo a los temas geofrikis, no por falta de ganas, sino porque soy disperso, muy muy muy disperso, pero se cruzó la posibilidad de mezclar cartografía y juegos de rol y …

Allí que medio liando a otro, que no hace falta que le líe nadie, llamado @RealIvanSanchez, preparamos una versión online del mapa de Cunia, la ciudad sin alma del juego de rol Rol Negro de la editorial Ediciones Sombra.

Y por aquí os voy a comentar el stack que usamos para la hazaña…

Sigue leyendo

Pequeñas conclusiones y trabajo futuro para las 1as jornadas Sudamericanas FOSS4G


Me permito postear por aquí un mensaje de Mauricio Miranda (XoomCode, y miembro de OSGeo-es) sobre cómo han ido las 1as Jornadas Sudamericanas FOSS4G que ha enviado esta mañana a la lista Spanish (las negritas y enlaces son cosa mía).

Hola amigos,

Escribo para contarles un poco de las jornadas que vivimos el viernes pasado (08/04/2011).

Primero que nada me gustaría decir que mis expectativas fueron completamente superadas.

La organización fue impecable, los tiempos se respetaron muy bien, el auditorio de la Universidad Mayor está realmente bueno y las charlas en general fueron muy interesantes.

La convocatoria también creo que estuvo dentro de los parámetros esperados, habían alrededor de unas 100 personas de muy diversos ámbitos y que mostraron mucho interés por entrar al mundo geolibre y/o afianzarse dentro de él. Creo que quedó demostrado que existe una comunidad detrás de esto y que tenemos que hacer más esfuerzo por ir juntando los intereses individuales y convertirlos en una fuerza común que sea la base para seguir creciendo.

Es muy importante felicitar a César Medina y al resto del comité organizador porque han hecho un trabajo muy muy bueno y que definitivamente es fuente de inspiración para que otros nos animemos a organizar las 2das Jornadas Sudamericanas.

Hay algunos puntos que son importantes tener en cuenta para la próxima versión:

  • Las mejores presentaciones fueron las que contaron un caso de éxito usando software y/o datos libres. Las charlas teóricas no son muy bien asimiladas cuando el público es tan heterogéneo.
  • Hay que trabajar más en la convocatoria para que gente de otros países se sienta interesada en viajar y participar.
  • Para generar más interés creo que podríamos:
    • Incorporar talleres prácticos de las herramientas más comunes.
    • Estirar las jornadas a 2 días (nadie quiere viajar 1000km o más para sólo 5 horas de charlas).
    • Invitar a gente más conocida mundialmente que siempre ayuda a que la conferencia sea más atractiva.
  • Hay empresas y organizaciones dispuestas a colaborar como sponsor, deberíamos aprovecharlas.
  • Sería interesante recibir más apoyo de las organizaciones internacionales que ya tienen una estructura armada y mucha más experiencia en esto (OSGeo, gvSIG, OSM, etc).
  • Expandir las jornadas y hacerlas Latinoamericanas?

Nuestra idea, ambición, deseo o como quieran llamarle, es convertir estas jornadas en la versión, para este otro lado del charco, de lo que son las Jornadas SIG Libre de Girona para los de allá. Obviamente sabemos que tendremos que ir de a poco, creciendo, aprendiendo y mejorando año a año.

Por esto, y porque creemos que si hacemos fuerza entre todos las cosas van a salir mejor y más rápido, les pedimos a todos aquellos interesados en participar, ya sea exponiendo, sponsoreando (si tal palabra existiera), ayudando a organizar, publicando, aportando ideas o alguna otra forma que se les venga a la mente; que se comuniquen con nosotros para que vayamos pensando y diagramando la próxima versión de estas Jornadas Sudamericanas o Latinoamericanas FOSS4G.

Bueno, creo que eso ha sido todo por ahora. Espero ver a muchos más de ustedes en la próxima y que esta haya sido sólo la primera de muchas exitosas conferencias que vamos a organizar por estos lados.

Muchas felicitaciones y gracias a los que pusieron tanto esfuerzo para que estas 1ras jornadas sean posibles.

Saludos para todos!

Solo me resta añadir que espero que este sea el comienzo de lo que España supusieron las jornadas de Girona, algo así como una «fiesta» de la comunidad alrededor del a geomática libre donde mostrar proyectos y casos de éxito. Es importante buscar el modo de que no se convierta en un esfuerzo casi personal y conseguir encontrar a un grupo de organizadores tan motivados como pueda ser en España el SIGTE por coordinar un evento de mayores dimensiones que pueda dar respuesta a las seguro latentes necesidades de este tipo de eventos por aquellas longitudes. Como dice Mauricio lo ideal sería conseguir organizar un evento de al menos dos días, buscando esponsorización para poder hacer frente a los gastos que implican un evento más complejo que el de la semana pasada, no sé si tal vez al amparo de otro evento del ramo como Latinoware, lo importante es buscar los puntos de unión y ser humildes pero con unos criterios y un objetivo claro del tipo de evento que se quiere conseguir.

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