Archivo de la categoría: OGC

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.

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.

WMS Inspector


Me permito difundir el mensaje que Adriâ Mercader ha enviado esta mañana a la lista OSGeo Spanish (y supongo algunas más)

Este es un mensaje para anunciar la primera versió pública de WMS Inspector, un complemento para Firefox de código abierto con herramientas para trabajar con Web Map Services (WMS). Puede resultar especialmente útil si se trabaja con librerias Javascript como OpenLayers o MapBender o se configuran servicios WMS

Sus características principales incluyen:

  • Cargar todas las solicitudes WMS de la página actual y sus parámetros
  • Ordenar las solicitudes por servicio o tipo
  • Visualización de solicitudes (imágenes o errores) individuales
  • Copiar servicios, solicitudes o parámetros al portapapeles
  • Edición directa de los parámetros de las solicitudes
  • Salida de la respuesta GetCapabilities en forma de informe HTML o del
    archivo original

WMS Inspector se puede descargar del repositorio oficial de Mozilla: https://addons.mozilla.org/firefox/addon/91406

Para más información, por favor visitad http://wiki.github.com/amercader/WMS-Inspector/

Si queréis contribuir como desarrollador, tester o traductor o solo dar vuestra opinión, no dudéis en subscribiros o enviar un mensaje a la lista de discusión: wmsinspector at freelists.org

Gracias,
Adrià Mercader

¡¡Enhorabuena Adrià por contribuir este trabajo!!

Ahora la verdad es que no tengo mucho tiempo para probarlo, pero en cuanto me tenga que pelear con algo de webmapping seguro que le echaré un vistazo, y si hay algo de interés que contar por aquí ya os lo hago saber….

Actualizando la extensión para geoRSS de gvSIG


Hace ya más deun año desde la última vez que le dediqué algo de tiempo a laextensión y tenía algunos errores y cosas que quería tocar. Por un ladohace ya algún tiempo salióen las listas de gvSIG el tema del bloqueo activo que Googlerealiza en Cuba cumpliendo las leyes del embargo. Esto fue bastantecriticado y en ese momento, como SEXTANTE, ya meplateé que el servicio era bueno pero no se justificaba si había otrasopciones.

Un compañero de gvSIG me comentó que JavaHispanotenía una forja,así que me puse manos a la obra y efectivamente, aunque con algunosproblemas al principio, pude migrar el código a un nuevoproyecto en la forja de JavaHispano y ahí quedó la cosa.Durante ese tiempo salió OSOR,una forja también de proyectos libres que creo que se queda grande paralo que yo tengo entre manos, aunque me comentaron que si seguía con elproyecto podría usar sus infraestructuras. No creo que cambie, si todova bien, JavaHispano funciona, no muy rápido pero suficiente y tienemucho más de lo que necesito.

En fin, nada que ayer le dediqué unas horas a conseguir que laextensión funcione correctamente sobre gvSIG 1.1.2 (dejo para másadelante la adaptación a gvSIG 2.0) y ya la tenéis disponible en el catálogode extensiones de gvSIG y en la páginade la forja.

Por otro lado he intentado sin éxito integrar la ventana deinformación de geoRSS en la herramienta y el diálogo de gvSIG. La razónprincipal es que me obliga a llevar al ámbito de gvSIG (a su carpeta com.iver.cit.gvsig/lib)partes de la extensión que no deberían estar ahí. Esto es por un temabastante peliagudo y que se está resolviendo. SEXTANTE también losufre, a ver si se soluciona (con un trabajo duro, no sale porgeneración espontánea, creedme que lo sé) y tenemos un gvSIG aún másmodular y extensible.

Otra cosa que he hecho y que me tenía un poco mosqueado desdehace tiempo es el tema de la documentación. Está hecha con DocBook pero noconseguía organizarlo de forma sencilla para que cualquiera pudieracompilarla (aunque dudo mucho que nadie vaya a hacerlo). Finalmente ygracias a un trabajo del equipo de Apache Velocityllamado DocBookFramework, he conseguido que sólo haya que descargar el frameworky si lo pones en el mismo workspace que tuproyecto funciona a la primera ya que tiene todos los componentes. La documentaciónes la misma, pero la forma de montarla es muchísimo más sencilla.

Cosas por mejorar: pues las mismas de antes, mejores javadocs,la documentación técnica del bicho (tampo esto es una obra de laingeniería del software francamente, cualquiera que le pegue un poco agvSIG lo comprenderá fácilmente) y tal vez un poco más de cariñoen las Interfaces de Usuario.

Dejo unas capturas de pantalla: una de la extensiónfuncionando con el RSSinternacional del periódico ElPaís (previo paso por geonames, la extensión se encarga, tusabes) y del geoRSSde las fotos con la etiqueta colorful de flickr (el geoRSS se puede ver abajo del todo de la página, junto alKML) y otras dos con ejemplos de información de una noticia de cadauno, pinchando en la imagen se puede ir a la noticia real. He dereconocer que la sección Internacional del País es para no leerla, quelo más suave que haya encontrado (sin muertos y esas cosas)sea de Sarah Palin…

gvSIG con dos orígenes geoRSS

Noticia geoRSS del País

Noticia geoRSS de flickr colorful

Obteniendo KML de PostGIS en el SRS correcto


Hace poco que hemos empezado a hacer unas cuantas cosas con PostGIS en la oficina, y una de las que me ha llamado la atención es la posibilidad de generar KMLs directamente empleando la función askml().

Cuando manejas una base de datos geolocalizados, la posibilidad de exportar con facilidad la información a un formato como KML se agradece… ahora bien que se pueda hacer como Dios manda es la leche, me explico.

La culpa, claro, es mía porque he consentido en que sigamos usando un SRS obsoleto como el EPSG:23030 cuando deberíamos usar EPSG:25830, pero el caso es que nuestras coordenadas están en el viejuno ED50 UTM30N y la función askml() realiza una transformación estandar a EPSG:4326, que como todos los que nos hemos visto en la tesitura de transformar datos sabrán, no garantiza precisión en el ámbito de la península ibérica. De hecho las “cosas” salían desplazadas nuestros conocidos 200m. (palmo arriba, palmo abajo).

Lo primero que se me ha ocurrido es que seguro que PostGIS, que utiliza proj4, puede hacer una transformación por parámetros. De hecho, si miramos la definición de la función askml() te conduce a la función st_askml() que te conduce a la función _st_askml() en la que utilizan la función transform() para transformar automáticamente a EPSG:4326, pero en este “estudio” preliminar no he visto dónde meterle parámetros a la transformación.

Cuando he ido a consultar la función transform() he visto a su prima de zumosol la función transform_geometry() cuyos parámetros (geometry, text, text, integer) me han parecido muy prometedores, y googleando un poco he llegado hasta un correo donde daban una idea de cual es su uso y hasta otro donde se han confirmado mis sospechas, se puede usar proj4 para hacer transformaciones al vuelo dentro de PostGIS…

Ahora solo quedaba pegarse un poco con las cadenas de configuración de proj4, cuidando de no dejarse ningún parámetro, hasta conseguir hacer la mágia de la transformación, palmo arriba palmo abajo, correcta.

La solución os la pongo a continuación:

select gid,
       _ST_AsKML(2,
                 transform_geometry(geom,
                                    ' +proj=utm
                                      +ellps=intl
                                      +zone=30
                                      +units=m
                                      +towgs84=-131,-100.3,-163.4,-1.244,-0.02,-1.144,9.39
                                      +no_defs
                                    '::text,
                                    ' +proj=longlat
                                      +ellps=WGS84
                                      +datum=WGS84
                                      +no_defs
                                    '::text,
                                    4326),
                 15)
from tabla;

Espero que os sirva de ayuda si alguna vez os véis en la misma tesitura.

Un saludo.

Google Calendar + Yahoo Pipes = KML


Siguiendo esta anotación del blogOUsefulInfo, en sus propias palabras: “Rareza, extrañeza,encanto… en buscade OU2.0″, he realizado unpipe deYahoo que permite seguir en un mapa lalocalización de loseventos publicados enel calendario geomático.

http://pipes.yahoo.com/vehrka/geomaticblog_calendar

La idea consiste en juntar los orígenes RSS de loscalendarios en unafuente, procesarla con el geolocalizador de Yahoo y ver larepresentación sobre Yahoo maps al que luego le puedes pedirque te losirva en KML. Puedes consultar lafuente del pipe que es casi auto-explicativa y por supuestocopiarlos a tus propios pipes para modificarlo.

Ya me contaréis que tal con los experimentos.