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…

.highway[type='motorway'] {
  .line[zoom>=7]  {
    line-color:spin(darken(@motorway,36),-10);
    line-cap:round;
    line-join:round;
  }
  .fill[zoom>=10] {
    line-color:@motorway;
    line-cap:round;
    line-join:round;
  }
}

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.

Para hacerlo debes arrancar gvSIG a la antigua (como en las primeras versiones) tirándolo contra java… este proceso no es trivial, de hecho yo casi siempre tengo que preguntar como se hace, así que para no seguir molestando a Xurxo, lo voy a apuntar en un sitio (o sea aquí) y de paso lo comparto con la comunidad.

Para “tirar” gvSIG contra java hay que crear un pequeño archivo .bat en la carpeta en la que se instala gvSIG y poner el siguiente contenido.

@echo oN
SET BASEDIR="C:\Archivos de programa"
SET GVSIG_HOME=%BASEDIR%\gvSIG_1.9
SET PATH=%GVSIG_HOME%;%PATH%
SET JAVA_HOME=%BASEDIR%\Java\jre1.5.0_18
SET PROJ_LIB=%BASEDIR%\gvSIG_1.9\bin\gvSIG\extensiones\org.gvsig.crs\data
SET GDAL_DATA=%BASEDIR%\gvSIG_1.9\lib\gdal_data

cd %GVSIG_HOME%\bin

%JAVA_HOME%\bin\java.exe -Djava.library.path=%GVSIG_HOME%\bin -cp andami.jar;.\lib\gvsig-i18n.jar;.\lib\beans.jar;.\lib\commons-codec-1.3.jar;.\lib\commons-collections-3.1.zip;.\lib\commons-dbcp-1.0-dev-20020806.zip;.\lib\commons-pool-1.2.zip;.\lib\log4j-1.2.8.jar;.\lib\iver-utiles.jar;.\lib\castor-0.9.5.3-xml.jar;.\lib\jcommon-1.0.10.jar;.\lib\jfreechart-1.0.6.jar;.\lib\jh.jar;.\lib\JUF-1.0.jar;.\lib\crimson.jar;.\lib\xerces_2_5_0.jar;.\lib\javaws.jar;.\lib\xml-apis.jar;.\lib\xmlrpc-2.0.1.jar;.\lib\looks-2.1.4.jar;.\lib\JWizardComponent.jar;.\lib\tempFileManager.jar;.\lib\kxml2.jar;.\lib\org.gvsig.exceptions.jar;.\lib\org.gvsig.ui.jar;.\lib\xerces_2_5_0.jar;.\lib\jcalendar.jar -Xmx500M com.iver.andami.Launcher gvSIG gvSIG\extensiones gvSIG

pause

Dos caveat emptor:

1. Andaros con ojo al respecto de la configuración de variables, que dependen de las rutas de vuestro path.
2. Esta instalación usa el java del sistema, no el que viene con la instalación de gvSIG con su propio java, ténganlo en cuenta.

Un saludo

Far from seeing this as a trouble, I see it as a problem and an opportunity, not just for me but for any company or project that may be looking for a good “man in the middle” on geo-technologies.

• Good technical skills
• Focused on problem solving
• Good teammate
• +15 years of experience in informatics
• +10 years of experience in geomatics
• Open source GIS oriented, but who also understands proprietary GIS software
• With learning skills

Please put in touch with me at vehrka (at) gmail (dot) com

You can also check my CV (in Spanish and English) at http://pferrer.eurocv.eu

CU in this cartographic world, which is certainly smaller than the subject that tries to represent.

¡¡Que todos vuestros deseos e ilusiones se vean cumplidos y que seáis muy felices.!!

¿Y el mapa?

Pues cómo os íbamos a  felicitar sin un mapa…

La Navidad en Chile

En Chile hay una pequeña zona (una comuna) en la provincia de Cardenal Caro que se llama Navidad concrétamente en 33º 57′ 17” S, 71º 49′ 48” W.

Quisiéramos haberos podido ofrecer un mejor mapa de la Navidad, pero por desgracia los medios no nos alcanzan a más, aunque en cuanto nos sea posible organizamos una mapping party allí al más puro estilo latino: una auténtica Fiesta del Mapa en Navidad.

Un saludo y un abrazo a todos.

La imagen que acompaña al apunte es CCBYSA proviene de CloudMade y está hecha con datos de OpenstreetMap.

La ciencia en España no necesita tijeras

Desde geomaticblog también queremos unirnos a la campaña iniciada por Javier Pelaez en su blog La Aldea Irreductible.

Hay días en los que te parece que vives en un país de pandereta, este es uno de esos días en los que hay que recordar que queda mucho que educar en la sociedad, sobretodo entre quienes “nos mandan”.

Como decía Carol Anne: ¡Ya están aquí!; y es que me da en la nariz que a más de uno se le va a erizar el pelo al ver que su reflejo del espejo le saluda y ‘el no está preparado todavía.

Pese a que aún hay muchas sombras en el asunto; sobretodo la de que a muchos nos gustaría que el acceso “gratuito” a lo datos y eso dista de estar garantizado; la noticia es muy buena y creo que la comunidad debería tomarse una cervecita en honor y loa del asunto.

Un saludo,

PD. Un poco más de información del asunto para los muy despistados

Simon ha usado el servicio web Wordle para hacer una nube de palabras de las etiquetas de los artículos que se van a presentar en la conferencia.

El resultado es este:

Nube de palabras de las etiquetas de los artículos de FOSS4G2009

Para que os hagáis una idea de por donde va el “estado del arte” del Software Libre para Geomática.

Portada del libro: Dirac La belleza matemática

Ayer estuve en la feria del libro de Valencia y me encontré una agradable sorpresa.

Pasando por los stands, y levantando de golpe la cabeza, me encontré con un viejo compañero de batallas, allá por los años en los que estudiábamos topografía juntos: Sergio Baselga.

El caso es, como habréis podido observar en la imágen que acompaña al apunte, que Sergio estaba detrás del stand, firmando el primer libro que ha publicado (sin tener en cuenta todas las publicaciones sobre la carrera, claro).

No pudimos hablar mucho, un par de comentarios sobre cómo nos va a cada uno, dónde me enteré que recién había aprobado la oposición como profesor en la Universidad Politécnica de Valencia, donde da clases en los dos ciclos de la ETSI Geodésica, Cartográfica y Topográfica.

El libro que ha publicado es una muestra de una de sus pasiones, las matemáticas, que ya se le daban espectacularmente bien cuando estudiábamos juntos y nos corregía errores en las redes topográficas del proyecto conjunto, en concreto sobre Dirac . El libro está en la cola de espera, para cuando acabe con los que tengo entre manos; pero conociendo la pasión que le pone Sergio a aquello que le gusta, y el alto grado de perfección que se impone en lo que emprende, no dudo que será como mínimo muy instructivo y revelador.

A aquellos que os gusten las matemáticas, la física y las biografías sobre gente que se han dedicado a ello, seguramente este libro os gustará.

• Título: Dirac. La belleza matemática
• Autor: Sergio Baselga Moreno
• Colección: La matemática en sus personajes (nº 34)
• Editorial: nivola
• Otros: encuadernación en rústica, 171 páginas, 19.50€

La idea es pasar de la imágen de la izquierda (figura 1)  a la imagen de la derecha (figura 2) … bueno no os lo voy a contar como obtener exactamente la imagen de la derecha, pero sí por lo menos como obtener la información base:

Figura 1

Figura 2

1.- Obteniendo los datos.

La NASA ha puesto los datos del SRTM a disposición del público y estos pueden ser encontrados en diversos lugares:

• el FTP de la propia NASA.
• la página del USGS.
• una capa de Google Earth Mark Mulligan y el King’s College de London.

cada uno con sus pros y sus contras, en el caso del FTP de la NASA, tendrás que conocer las coordenadas de la zona de antemano y te bajas las teselas enteras del mosaico, la página del USGS te permite obtener un recorte bastante ajustado de la zona y por último, la capa de Google Earth, también te permite obtener las teselas en dos formatos ARCASCII y GeoTiff.

En mi caso, usé la capa de Google Earth, aunque probablemente sea más sencillo usar la página del USGS. En la imagen de la izquierda (figura 3) podéis ver el teselado de la capa de Google Earth, si pincháis en el icono del centro de la tesela, en Google Earth obviamente, obtendréis el diálogo de la derecha (figura 4), dónde está el link a la descarga. Yo me bajé las 4 teselas que conforman la Comunidad Valenciana en formato GeoTiff.

Figura 3

Figura 4

Una vez descargados los zip que necesitemos los descomprimiremos todos en un directorio.

2.- Empezando a trabajar con FWTools.

Voy a suponer que te has bajado e instalado FWTools (2.2.8 en mi caso, aunque ahora hay una versión más  actualizada), no voy a cubrir esta parte, solo voy a dar dos Caveat emptor que hay que tener en cuenta cuando se usa esta herramienta, al menos en Windows:

• Siempre has de asegurarte de ejecutar el setfw.bat que hay en el directorio raíz de la instalación antes de  empezar a trabajar.
• Cualquiera de los scripts de Python de FWTools que quieras ejecutar, debes hacerlo con el Python que se instala con FWTools, lo cual obliga a poner el path completo al python.exe de FWTools y el path completo al script .py que vayamos a ejecutar.

A lo largo del artículo  supondré que has tenido en cuenta ambas advertencias porque no voy a escribir los path completos ¿ok?.

3.- Uniendo las teselas.

Para unir las teselas emplearemos la aplicación gdal_merge que sirve para unir capas raster a través de la línea de comandos. Teclear un

os dará más información sobre el comando, yo aquí voy a ir a la carne.

Supongamos que tenemos cuatro teselas: los archivos srtm_36_04.tif, srtm_36_05.tif, srtm_37_04.tif y  srtm_37_05.tif; para unirlas basta con teclear:

Obviamente detrás del -o va el nombre del fichero de salida y despues van los nombres de los ficheros de entrada separados por espacios, ojo que en este caso como el formato es el mismo que el formato por defecto (GeoTiff) no hace falta especificarlo con la opción -of.

4.- Reproyectando.

La información del SRTM está en EPSG:4326, seguramente vendrá bien para un puñado de aplicaciones y usos, yo
la voy a convertir a EPSG:25830 (o sea ETRS89 UTM 30N). Esta vez emplearemos la aplicación gdalwarp que es una especie de navaja suiza de GDAL. Teclear un

gdalwarp


nos dará más información sobre el asunto. Pero vamos a lo que vamos…

En este caso -s_srs sirve para indicar el sistema de referencia origen y -t_srs el sistema de referencia destino,
los sistemas de referencia pueden definirse de muchas maneras ya que se basan en proj4, en este caso lo hacemos a través de los códigos EPSG. Lo que viene después son el archivo origen (mosaico.tif) y el archivo destino  (mosaico_r.tif).

5.- Enmascarar (opcional).

Si os fijáis en la figura 2 podéis ver que el relieve solo está presente dentro de los límites de la Comunitat Valenciana. Se
trata de una máscara que evidentemente puede aplicarse de muchas maneras, o no aplicarse, en este caso veremos como hacerlo con GDAL.
Para enmascarar se puede usar cualquier dataset que reconozca GDAL/OGR, así que os podéis ir haciendo una idea de la potencia del asunto… En este caso utilizaremos un shapefile con el límite de la Comunitat Valenciana.

Si váis a usar un shapefile, tened en cuenta lo siguiente:

• El shapefile debe estar bien formado y sin errores, obvio ¿no? pero OGR es un poco más sensible con el tema que
  otras herramientas SIG.
• El shapefile debe ser singlepart. No he encontrado la razón, esto ha sido absolutamente empírico.
• El shapefile debe tener su correspondiente .prj. Podéis ver el punto 5.1. para un pequeño truco sobre cómo obtenerlo.

Para enmascarar con GDAL se usa también gdalwarp.
El shapefile que usaremos para cortar se llama es_cv_25830.shp y el archivo de salida mosaico_re.tif.

5.1.- Obteniendo el .prj.

Usando OGR y más concretamente uno de los scripts de Python que vienen con FWTools, podemos definir de manera sencilla un archivo .prj. En concreto habría que teclear los siguiente:

6.- Recortar.

Yo, en mi inocencia, me llevé una sorpresa al descubrir que “enmarcarar” no es lo mismo que “recortar” para GDAL, al aplicar el paso 5 pensaba que obtendría algo de las dimensiones del shapefile, pero si lo piensas un poco es lógico que no sea así. El caso es que tenía un GeoTiff del mismo tamaño que el de la figura 1, pero todo estaba en negro excepto la Comunitat Valenciana. Para eliminar la zona en negro sobrante emplearemos gdalwarp aunque antes tienes que conocer la extensión de tu zona (Xmax, Xmin, Ymax, Ymin).
En nuestro caso le haremos un ogrinfo al shapefile para conocer cúal es la extensión.

Es muy importante tener en cuenta la opción -al en combinación con la opción -geom=NO si no queréis ver en pantalla un chorreo de coordenadas de los puntos que forman el borde de los polígonos.

Ahora sí, las opciones para gdalwarp.

Si os estáis preguntando porqué leches no he hecho los pasos 4, 5 y 6 de una vez la respuesta es: porque si los intentas
hacer de golpe no sale… bueno al menos a mi no me han salido, agradecería si alguien le pone un poco de luz al asunto.

7.- Escalar.

Si tu opción es usar la imagen de fondo para un mapa y usas Photoshop el artículo ha terminado para tí, coges mosaico_rer.tif y te pones a trabajar con ella.

Sin embargo yo uso GIMP y han postpuesto el uso de imágenes de 16 bits para la versión 2.8 (de momento) por lo que si quiero trabajar con estas imágenes tengo que escalarlas a 8 bits.

Para escalar las imágenes usando GDAL empleamos la instrucción  gdal_translate aunque antes tiraremos mano de gdalinfo.
La orden gdalinfo nos aportará información de máximos y mínimos del histograma de la imágen, y aprovecharemos esos máximos y mínimos para escalar de 0 a 255 niveles de gris con gdal_translate. Para obtener la información del histograma tecleamos

Y una vez determinados los máximo y mínimos podemos esclar tecleando:

La opción -ot permite definir el tipo de dato, en este caso 8 bits (1 byte), del formato de salida, que por defecto es GeoTiff; por eso no lleva la opción -of.
En la opción -scale se pone la correspondencia entre el rango de la imagen de entrada (0~1757) y el de la imagen de salida (0~255). En este caso, como la imagen tiene información DEM el rango 0~1757 indica las altitudes máxima y
mínima en las que se mueve la Comunitat Valenciana. Os recuerdo que en la imagen original las altitudes son ortométricas.

De esta forma habremos obtenido la imágen que nos puede servir para componer la base del mapa.

Figura 5

8.- Enlaces de interés.

El enlace que siempre hay que tener presente cuando se trabaja con las FWTools es http://www.gdal.org/gdal_utilities.html donde se recoge la documentación de las utilidades de GDAL.

Me mandan a campo con un GPS peeeero a la vueltaquieren unos datos en ED50UTM30N (EPSG:23030). Que pesaos son, a ver cuando se enteran de qué es el ETRS89 y de que las cosas habría que pedirlas en EPSG:25830,que ya se lo hemos dicho en alguna ocasión pero vamos, que ni publicándolo en el BOE.

Muy bien, puesto que gvSIG te permite hacer la conversión usando la rejillaen formato NTv2 del IGN a priori no hay problema y la cosa queda muy bien, en la imágen podéis ver los datos en azul que son los datos WGS84 (EPSG:4326) reproyectados usando la rejilla y los datos en rojo que son los mismos datos pero en EPSG:23030, coincidencia total, color morado, que es el de la ingeniería.

Pero a mi me asaltó una duda, ¿y si no tengo gvSIG? ¿con qué lo hago?. Pues como gvSIG usa proj.4 para esos menesteres y GDALtambién, y como ya nos explico Eloi se puede usar GDAL en línea de comandos con OGR, me he decidido a realizar la misma transformación a mano y usando ogr2ogr.

Así que me miro un par de webs, cazo un par de ideas por aquí y por alla y compongo la siguiente instrucción lista para teclear en la consola (cuidado que he añadido un salto de línea para mayor claridad):

Explico por partes: “-t_srs” indica que se deben reproyectar los datos de salida, la cadena de texto que viene detrás son los argumentos de proj.4 que indican el SRS de salida, ojo al argumento “+nadgrids” que debe tener la ruta completa al fichero de rejilla (yo lo copié al mismo directorio donde estaba el archivo SHP por comodidad, por ello el “./“). “-f “ESRI Shapefile”” indica el formato de salida. Por último el nombre del archivo de salida y el de entrada.

Voy todo ilusionado, le doy al enter y…

Para el que no tenga ganas de sacar proporciones de las imágenes, se trata de un desplazamiento de unos 170m en dirección SW.¿Que diablos ha pasado?

Aja, OGR no está usando la rejilla para hacer la transformación, ¿pero si la documentación y los ejemplos de transformación NAD27y NAD83 funcionan? ¿qué pasa?

Bueno, os ahorro un rato de pruebas futiles y googleo: aquí está la pista y aquí la explicación del problema y la solución, que os detallo acontinuación.

Resulta que el problema es de OGR, que no es capaz de parsear todos los comandos de proj.4, así que cuando no entiende algo, lo ignora, como pasa en la imagen de arriba. Como esa es una fea costumbre, los programadores de OGR ha incluido una pequeña puerta de atrás: el parámetro “+wktext“. Al incluir este parámetro en la cadena que le damos a OGR le indicamosque NO tiene que parsear la cadena, si no más bien pasársela tal cual a proj.4 para que esté haga la magia.

Así pues, ni corto ni perezoso incluí el dichoso parámetro en la instrucción:

Y de esta manera obtuve la imagen que deseaba:

Que ustedes lo reproyecten bien.

ACTUALIZACIÓN (20/01/2012): Nacho Varela  nos informó de que se habían perdido las imágenes, y en el proceso de reconstruirlas nos hemos dado cuenta que el famoso “+wktext” ya no es necesario y que GDAL/OGR ya parsea la cadena completa y se la manda a proj4.