Generar tiles de una imagen georeferenciada
Si tenemos una imagen georeferenciada que queremos preparar para mostrar en un mapa web o una app tenemos varias opciones, pero la más simple quizà sea la de fraccionar dicha imagen en casillas para los distintos niveles de zoom con los que vamos a trabajar, y publicarlas en un servidor web bajo una estructura de carpetas z/y/x.
=http://www.gdal.orgGdal[/url] es un conjuto de herramientas libres para tratar y manipular rasters que podemos instalar tanto en Windows, Linux o Mac, en el caso de Ubuntu por ejemplo podeis encontar las librerias en los repositorios. Estas herramientas se utilizan desde la linea de comandos y permiten entre otras opciones georeferenciar una imagen, trasladar la georeferencia, de una imagen o cambiar la proyección de esta entre muchas otras.
Como veis si la imagen con la que vamos a trabajar no está georeferenciada tenemos también la posibilidad de prepararla mediante las utilidades de Gdal, però no es el caso de este artículo.
De entre todos los comandos, existe uno que podemos aplicar rápidamente sobre una imagen ya georeferenciada para generar el resultado que nos interesa en nuestro caso...
Este es el comando gdal2tiles.py, y a partir de una imagen genera la estructura de carpetas necesaria y recorta las casillas que corresponden. Para terminar incluso nos genera un archivo html para visualizar los resultados sobre el mapa de google maps y otro para lo mismo utilizando openlayers.
Para ejecutar el comando tan solo es necesario la imagen, conocer el sistema de referencia aplicado en ella y indicar la carpeta donde depositar la salida como en el siguiente ejemplo:
gdal2tiles.py -z '10-18' -s '+proj=utm +zone=31 +datum=WGS84' imagengeo.tif carpeta_destino
El parametro -z indica los niveles de zoom en los que queremos la salida. En google maps, por lo generar, los niveles de zoom van de 0 (todo el mundo en una casilla de 256x256) a 19 pero en algunas zonas se llega a zoom 20 y 21.
El parametro -s servirá para especificar el sistema de referencia espacial utilizado, en mi ejemplo esto es '+proj=utm +zone=31 +datum=WGS84'. Atención porque las comillas, que pueden ser simples o dobles son importantes.
Los dos últimos parámetros son la imagen original, y la carpeta de salida.
El proceso puede ser un poco lento según el tamaño de la imagen y la cantidad de casillas de salida, de hecho en algún otro momento he realizado el mismo ejercicio utilizando mapnik, y es más rápido, eso si, preparar el proceso también es mas laborioso.
Una vez terminado, solo hay que abrir la carpeta de destino y encontraremos las imageners organizadas en carpetas junto con los archivos googlemaps.html y openlayers.html que permiten visualizar el resultado rápidamente en el navegador.
En el caso de google maps previamente necesitaremos una clave de registro de la API para disponer de permisos de utilización de sus herramientas y que podemos aplicar directamente a la utilidad gdal2tiles.py como parametro.
Aquí les dejo una captura de un ejemplo rápido...
Ubuntu 11.10 y osm2pgsql
Estamos estrenando distribución de Ubuntu y van apareciendo errores, que a pesar de ser pequeños, no dejan de ser molestos...
Despues instalar osm2pgsql des de el repositorio oficial... para cargar cartografía de openstreetmap a postgre...
sudo aptitude install osm2pgsql
Si ejecutamos el comando con los parámetros mínimos:
osm2pgsql -m -d nombre_base_datos archivo_a_cargar
Puede mostrar un error como el que sigue:
Couldn't open style file '/usr/share/default.style': No such file or directory
No encuentra la plantilla de estilo por defecto... y es que realmente el archivo no existe en este lugar. Puestos a resolverlo y después de buscar un rato, he encontrado que el archivo está en: /usr/share/osm2pgsql/default.style
Esto es relativamente fácil de resolver... y de hecho tenemos dos posibilidades:
Crear un enlace simbólico a dicho archivo en el lugar que espera encontrarlo el sistema...
sudo ln -s /usr/share/osm2pgsql/default.style /usr/share/default.style
o ejecutar el comando aplicando el parametro --style indicando el path del archivo:
osm2pgsql -m -d nombre_base_datos archivo_a_cargar --style /usr/share/default.style
Yo personalmente prefiero la primera solución y no tener que volver a pensar en ello.
Saludos.
Mas errores en la instalación de Postgre i Postgis en Ubuntu 11.10
Tal como comentaba en el anterior articulo he tenido algún problema con postgis en postgre 9.1 al instalar un servidor de Ubuntu 11.10, i como he podido comprobar este no ha sido el único traspiés...
Si al ejecutar algún comando de postgre os aparece este error
Can't exec "dpkg-architecture": No existe el archivo o el directorio at /usr/bin/psql line 103.
Use of uninitialized value $multiarch in scalar chomp at /usr/bin/psql line 104.
Se trata de un bug reportado:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/860552
Parece que el error ya está resuelto, de modo que a actualizar:
sudo aptitude update sudo aptitude upgrade
Y todo funcionando.
En mi caso el error deriva de realizar la instalación de postgre y postgis desde el mismo CD que se distribuye para servidor, así que imagino que si realizáis la instalación desde los repositorios no debería haber problema.
Salud.
Ubuntu 11.10 shp2pgsql en postgre 9.1
Hoy me he encontrado con una sorpresa después de poner a punto un servidor de Ubuntu 11.10 con postgis en postgre 9.1, y es que al ejecutar el comando shp2pgsql la respuesta en la terminal ha sido:
El programa «shp2pgsql» no está instalado. Puede instalarlo escribiendo:
sudo apt-get install postgis
Como? pero si postgis ya esta instalado.
Buscando en las carpetas de postgis he comprovado que el binario de la herramienta que comentamos se encuentra en la carpeta /usr/lib/postgresql/9.1/bin
Pues vaya fallo, el problema es que no existe un enlace simbólico a este archivo, de modo que tan solo hay que crearlo:
sudo ln -s /usr/lib/postgresql/9.1/bin/shp2pgsql /usr/bin/shp2pgsql
Espero no encontrar otros bugs en esta instalación de postgis, o por lo menos que sean tan fáciles de resolver como esta.
Darky’s ROM
Como documenté en el anterior post, existe infinidad de ROMs desarrolladas de forma libre para multitud de dispositivos. Algunas nos ofrecen ligereza y rendimiento, mientras que otras disfrutan de una gran variedad de aplicaciones y útiles integrados en la misma ROM. Podeis seguir un listado mas o menos actualizado de las principales ROMs en htcmania.
En cualquier caso, uno de los inconvenientes que encontraremos al flashear a menudo distintas ROMs es que probablemente vamos a necesitar hacer uso de aplicaciones de backup (como Titanium Backup) para restaurar los datos y aplicaciones que teníamos instaladas, y a pesar de que disfrutamos de grandes programas para este proposito, no deja de ser una tarea hasta cierto punto pesada.
En este articulo os presento la que considero una de las mejores ROMs para Galaxy S: La Darky's ROM.
Y mas que por el buen rendimiento y su estabilidad o las aplicaciones que pueda llevar instaladas, la gran ventaja que tiene esta sobre la mayoría de ROMs es la facilidad de actualización, y es que des de la versión 6.0, esta permite la instalación de nuevas versiones de la ROM sin que se pierdan los datos del usuario y aplicaciones, facilitando enormemente la tarea. Incluso si aplicamos el Voodoo lag fix. Tan solo necesitamos partir del ClockWorkMod que lleva integrado esta ROM y instalar la actualización de esta des de la tarjeta SD el ClockWorkMod podeis descargarlo des del apartado de descargas de Darky's ROM.
Preparar el smartphone para flashear una ROM
Una de las ventajas de las que podemos disponer si disfrutamos de un smartphone con android como sistema operativo, es el hecho que este sea un sistema de código abierto, cosa que ha propiciado la aparición de infinidad de colectivos que exprimen al máximo las posibilidades desarrollando y personalizando distribuciones alternativas para las diferentes plataformas que soporta este sistema operativo. En muchos casos incluso resolviendo algunos de los bugs originados por el fabricante que podemos encontrar en algunos de los smartphones, como en mi caso que tras comprobar que el Galaxy S daba problemas con la conectividad del GPS y se relentizaba cada vez mas a medida que iba cargando de aplicaciones el aparato. Los principales colectivos que menciono los podeis encontrar en htcmania.com y xda-developers.com entre otros.
El proceso de poner en funcionamiento una versión distinta a la proporcionada por el proveedor de telefonía o el fabricante varia en algunos aspectos de un modelo a otro, pero los pasos fundamentales a seguir son los mismos, y aunque es cierto que es preferible ser usuario experimentado en informática para llevar a cabo la operación, hoy en día existe gran cantidad de información relacionada al tema que nos ocupa y lo mas importante será antes que nada documentarnos al máximo acerca de las posibilidades para nuestro dispositivo.
En cualquier caso la mayor dificultad será entonces superar el miedo a realizar por primera vez dicha operación (algo de miedo a lo desconocido), comprensible si tenemos en cuenta que estos son aparatos costosos a los que enseguida desarrollamos apego e incluso una cierta dependencia. Hay que tener en cuenta, eso si, que en la mayoría de los casos estaremos perdiendo la garantía del producto al modificar el sistema o volcar un sistema no oficial.
En este artículo intentaremos discernir algunos de los conceptos con los que familiarizarse antes de empezar y prepararemos nuestro aparato para poder recuperar el sistema en caso de fallo o incluso facilitar la "vuelta a atras" si queremos "recuperar la garantía". Ya he comentado antes que los pasos pueden ser distintos para cada aparato, yo me ceñiré al que tengo en mis manos: Galaxy S.
Primeros conceptos:
- Definiremos como ROM un sistema operativo preparado para funcionar en un dispositivo en particular. Estos ROMs pueden ser proporcionados por el fabricante o el operador de telefonía. Todos ellos derivan o son adaptaciones del original desarrollado por google y a partir de estos, los colectivos de desarrolladores, realizan versiones alternativas.
- El proceso de añadir un paquete de software como por ejemplo una ROM a la memoria flash para sustituir un paquete existente o añadir funcionalidades lo llamaremos flashear.
- Rootear el dispositivo. Implica normalmente la instalación de determinados paquetes o aplicaciones que nos proporcionen la capacidad de actuar como root. El root es el usuario administrador del aparato y tiene la capacidad de realizar acciones y acceder a carpetas del sistema que el usuario normal no puede.
- ADB: Es un programa que nos permite comunicarnos con el dispositivo mediante USB para realizar determinadas acciones como por ejemplo acceder al entorno de comandos de este o mandar señales como la señal de apagado, reinicio y recuperación. Este programa se distribuiye junto con el entorno de desarrollo de android, y existen versiones ejecutables para distintos sistemas operativos.
Preparando el dispositivo:
Bueno, pues antes de flashear, deberíamos tomar ciertas precauciones:
- Habilitar el modo de depuración por USB: Esta opción es una casilla que debéis marcar en "Ajustes->Aplicaciones->Depuración USB". A partir de ahora deberíamos acostumbrar-nos a tener siempre esta casilla marcada, ya que en caso de problemas con esta modalidad funcionando podremos conectarnos al aparato mediante el programa ADB que hemos mencionado antes para intentar salvar el dispositivo.
- Rootear el dispositivo. Para realizar algunas acciones importantes necesitaremos los privilegios de ser root, y existen distintas maneras de hacerlo, e incluso algunas de las ROMs que luego podremos instalar ya nos ofrecen por defecto esta posibilidad. Por otro lado, algunas de las modalidades de activación de root no dejan rastro y no suponen una modificación importante. La opción que os recomiendo es la de utilizar z4root. Esta es una aplicación que se encontraba en el market de android pero actualmente la podéis descargar de distintas fuentes siendo la original la que os he enlazado de xda-developers.com. Tras instalarla podreis rootear el dispositivo de forma temporal (dejareis de ser root en el siguiente reinicio del aparato sin dejar rastros) o de forma permanente. Mientras seamos root, cuando ejecutemos un programa que necesite dichos privilegios se nos preguntará por la posibilidad de permitir al programa el acceso como root.
- Realizar copia de seguridad de la carpeta EFS (Esto es así para el Galaxy S, no conozco por ahora si es necesario en otros modelos). Este es un paso importantísimo, ya que en esta carpeta hay ciertos archivos que contienen información relativa a nuestro dispositivo y proveedor de telefonía. Si es eliminada puede que mas tarde nos sea necesaria. Para realizar la copia necesitamos ser root y utilizar un programa como root explorer. En este enlace encontrareis instrucciones para hacerlo y los programas necesarios: copiar EFS.
- Comprobar que tenemos acceso al modo Recovery y Download desde el arranque del smartphone. El modo recovery y download són dos menús que podemos iniciar encendiendo nuestro dispositivo mediante una combinación de botones. A menudo estos modos están bloqueados por los proveedores de telefonía. En el caso de Galaxy S, para acceder al modo de recovery debemos apagar el mobil y arrancarlo presionando al mismo tiempo Subir Volumen + Home + Encendido. Si no aparece el menú de recuperación en unos segundos será prudente desbloquearlo. Este enlace muestra distintas modalidades de desbloqueo para galaxy: Desbloquear modo recovery y download. La importancia de esto reside en que si tenemos una copia de seguridad de nuestra room, podremos recuperarla desde el recovery sin necesidad de utilizar el ordenador. Por otro lado mediante el recovery podremos también instalar también muchas ROMs que estan preparadas para ello del mismo modo. Mucha gente prefiere realizar el proceso mediante els USB desde el ordenador, pero para mi resulta mas cómodo prescindir de este.
- Instalar ROMManager. Este programa lo encontrareis gratuitamente en el market de android, y nos permitirá instalar el ClockworkMod (Que sustituye el recovery original por otro que nos ofrece muchas mas opciones), permitirá instalar BusyBox (Que añade un conjunto de comandos adicionales y es necesario para muchos de los programas que utilizaremos posteriormente). También desde RomManager podremos crear una copia de seguridad de nuestra ROM y descargar e instalar automáticamente ROMs preparadas para nuestro dispositivo. En el caso de Galaxy S no nos ofrecerà ROMs para descargar, pero he comprovado que desde este programa en el punto que nos encontramos con el HTC Desire podemos descargar al menos una docena de ROMs distintas he instalarlas con unos pocos pasos.
- Crear una copia de seguridad de nuestra ROM con el programa del paso anterior.
- Instalar TitaniumBackup. Esta es una aplicación gratuita disponible también desde el Market. Podremos realizar copia de seguridad de todas las aplicaciones instaladas junto con sus datos y una vez cambiada la ROM al volver a instalar TitaniumBackup (muchas ROMs ya lo incluyen de serie) podemos recuperar dichas aplicaciones y sus datos o solamente los datos si la aplicación ya está instalada. Es un programa imprescindible incluso si no queremos realizar un cambio de ROM.
Si hemos seguido estos pasos ya tendremos el camino preparado para afrontar el cambio de ROM sin correr demasiados riesgos. En cualquier caso quiero destacar que siempre quedará bajo vuestra responsabilidad aventuraros a realizar modificaciones al sistema de vuestro dispositivo.
Modificar el system.img de android
El archivo system.img corresponde a la imagen de la carpeta /system de android tanto en el emulador como en los dispositivos físicos. Para modificar el contenido de estas imagenes necesitamos distintas herramientas, ya que se trata de un sistema de archivos específico para flash drives; yaffs2.
Desempaquetar
Necesitaremos unyaffs; un proyecto alojado en http://code.google.com/p/unyaffs/ que permite desempaquetar las imagenes. Podemos descargar el archivo binario o el codigo fuente para compilarlo por nuestra cuenta. En cualquier caso yo he depositado el archivo unyaff que resulta de compilar con el comando gcc -o unyaffs unyaffs.c en la carpeta /usr/bin de mi sistema para poder ejecutarlo desde cualquier carpeta.
Una vez tengamos el programa utilizarlo es tan sencillo como copiar la imagen a una carpeta vacía en la que trabajar (esto es recomendable ya que unyaff no acepta parametro de destino del desempaquetado) y desempaquetar dicha imagen:
#desempaquetamos la imagen en la carpeta actual $unyaffs system.img #podemos eliminar el archivo original $rm system.img
Como comprovareis se habrá generado la lista de archivos y carpetas que normalmente colgarían de la carpeta /system en la carpeta en la que os encontrais.
Empaquetar
Para generar de nuevo una imagen en formato yaffs2 necesitaremos la utilidad mkyaffs2image. Podeis encontrarla en distintos lugares, pero la versión que yo estoy utilizando la he sacado de http://code.google.com/p/fatplus/downloads/ en donde encontrareis el código fuente y una archivo ya compilado. Como en el caso anterior, recomiendo depositar dicho archivo en la carpeta /usr/bin.
Generar la imagen es sencillo, en este caso el programa acepta como parametro el origen de los archivos a empaquetar y el destino de la imagen generada. en cualquier caso, es necesario que nos situemos en la carpeta a empaquetar ya que si indicamos la dirección hasta esta, corremos el riesgo de que los archivos empaquetados incluyan dentro de la imagen la ruta a partir del lugar des de el que empaquetamos. Por otro lado también es importante depositar la imagen generada en una ubicacion distinta para evitar que el empaquetado se coma a si mismo.
Ejemplo:
#empaquetamos los archivos de la carpeta actual dejando la imagen en la carpeta superior $mkyaffs2image . ../system.img
Con esto ya tendremos una imagen funcionando que podemos mandar al dispositivo o arrancar con el emulador especificandolo como parametro:
$emulator -avd nombredeldispositivoemulado -system rutadelaimagen
Ramdisk del emulador de Android
Si modificamos archivos de determinadas carpetas en el emulador de Android como la carpeta /system estos cambios se perderan al reiniciar el emulador, ya que se dicha carpeta se carga a partir del archivo original cada vez que el sistema arranca. Podemos obtener información sobre las imagenes que carga el emulador utilizando la ayuda de este:
$emulator -help-disk-images
Como nos indicará la ayuda, existen varias imagenes que se carga al inicio y las dos imagenes sobre las que comentaremos són ramdisk.img y system.img. La primera es la imagen de inicio y la segunda contiene los archivos de la carpeta /system
Podemos encontrar dichos archivos en nuestro ordenador en la carpeta ./platforms/android-ndistribucion/images del SDK con el nombre de ramdisk.img y system.img
Esto puede parecer un engorro, pero al contrario, son todo ventajas; de este modo nos aseguramos de arrancar siempre con una imagen del sistema estable y sin corrupciones, pudiendo realizar los experimentos que nos apetezcan sin miedo a estropear el sistema.
Por otro lado, si queremos realizar modificaciones permanentes a esta imagen es posible personalizar una copia de esta y iniciar el emulador especificando que utilice nuestra imagen tuneada.
Desempaquetar el ramdisk.img
Para modificar dicha imagen el proceso és algo complejo:
Para empezar copiaremos el archivo ramdisk.img en una carpeta en la que crearemos nuestra propia imagen. Se supone para el siguiente ejemplo que nos encontramos en dicha carpeta. Y realizamos los pasos que se detallan.
#renombramos el archivo $mv ramdisk.img ramdisk.gz #descomprimimos el archivo obteniendo un archivo con el nombre ramdisk $gunzip ramdisk.gz #creamos una carpeta temporal y nos movemos a ella $mkdir tmp $cd tmp #extraemos el contenido del archivo ramdisk $cpio -i -F ../ramdisk #realizamos las modificaciones oportunas. En el ejemplo crearemos un nuevo archivo llamado ejemplo.txt $echo "Esto es un ejemplo" > ./ejemplo.txt #empaquetamos la nueva imagen $find | cpio -o -H newc -O ../ramdisk_tuneada #descendemos a la carpeta donde tenemos los archivos generados, eliminamos el original y renombramos la nueva ramdisk $cd .. $rm ramdisk $mv ramdisk_tuneada ramdisk #comprimimos la imagen y la renombramos para que tenga el nombre original $gzip ramdisk $mv ramdisk.gz ramdisk.img
Ahora ya tendremos una nueva imagen con nuestras modificaciones a punto. Para cargar dicha imagen solo hay que iniciar el emulador especificando que utilice nuestro archivo.
$emulator –avd nombredeldispositivoemulado -ramdisk ruta_de_nuestro_archivo
Para modificar el system.img podeis ver los pasos en el siguiente articulo: modificar el system.img de android
Manipular archivos en las carpetas del sistema en android
Si intentamos modificar o añadir archivos a las carpetas del sistema como la carpeta /system en Android nos encontraremos que aun siendo root no es posible realizar dichas acciones. Esto se debe a a que es necesario montar la partición de dicha carpeta en modalidad de escritura. Esto podemos realizarlo del siguiente modo:
#montamos en modalidad de escritura la carpeta /system $mount -o remount,rw -t yaffs2 /dev/block/mtdblock7 /system #accedemos a la carpeta y realizamos las modificaciones oportunas $cd /system $mkdir carpeta_ejemplo #montamos de nuevo la carpeta /system en modalidad de lectura $mount -o remount,ro -t yaffs2 /dev/block/mtdblock7 /system
En el ejemplo se utilizan comandos del sistema para crear una carpeta, pero podemos subir archivos mediante adb una vez montada la unidad en modalidad de escritura
Ejemplo:
#usamos adb push origen destino para mandar un archivo al dispositivo $adb push ./archivo_a_subir /system/.
Puede suceder, pero, que el dispositivo al que accedemos sea el emulador, entonces, al subir archivos, o copiarlos desde la shell pueden producirse el error Out of memmory o No space left on device. Probablemente no sea cierto que no queda espacio de almacenamiento. Es posible evitar este error si en lugar de iniciar el emulador desde Eclipse o de ADV Manager del SDK lo hacemos utilizando el siguiente comando:
#usamos el comando emulator des de la terminal para arrancar manualmente el dispositivo $emulator –avd nombredeldispositivoemulado –partition-size 128
Por último hay que tener en cuenta que las modificaciones que hagamos al sistema si estamos utilizando el emulador no serán permanentes, y cada vez que reiniciemos el emulador, este aparecerá fresco como una rosa de nuevo, esto es debido a que hemos estado trabajando sobre una ramdrive que se lee al reiniciar se lee de nuevo a partir de una imagen original. Podemos especificar que la imagen a cargar sea una personalizada a medida tal como detallo en el siguiente articulo: ramdisk del emulador de android
Renderizar Mapnik usando metatiles
Tal como se documenta en OpenStreetMap podemos utilizar mapnik como motor gráfico para renderizar casillas a partir de información geográfica proveniente de las fuentes de datos de la misma comunidad o a partir de muchos de los formatos de archivos más difundidos en el entorno del GIS.
Terrassa y sabadell a partir del estilo por defecto de OSM
Si seguimos el manual al pie de la letra terminaremos renderizando imágenes de un area deseada mediante el script de python generate_image.py que encontraremos en las utilidades de OpenStreetMap para mapnik o generando colecciones de casillas usando el scrip del mismo paquete generate_tiles.py. El sistema es enormemente flexible y versatil, de modo que el tipo y aspecto de la cartografía que resultará ofrece un abanico enorme de posibilidades.
Terrassa y Sabadell con curvas de nivel y parte de un raster
Tal como se especifica en las mismas fuentes comentadas, el rendimiento en el procesado y la cantidad de cartografía a generar depende en gran medida de las características de nuestro equipo informático, ya que generar las casillas con generate_tiles.py puede ser muy tedioso si el área a cubrir es amplia. Este procesará cada una de las casillas individualmente, y por otro lado, la cantidad de casillas que pude suponer un area relativamente pequeña a un zoom cercano puede ser muy elevada.
Actualmente hemos realizado ciertas pruebas para generar casillas en nuestro servidor y disponer de cartografía personalizada, y uno de los impedimentos es precisamente el tiempo de proceso que puede requerir trabajar con grandes volúmenes.
Una posible solución es evitar que se renderize cada casilla por separado, ya que esto requiere para cada casilla un conjunto de consultas y búsqueda de datos geográficos en los orígenes de datos que se repetirá de nuevo para cada petición de casilla. Si observamos que el funcionamiento del script generate_image.py; podemos llegar a la conclusión de que debería ser más rápido renderizar una imagen que llamaremos metatile que cubra una superficie de varias casillas para luego fragmentarla y almacenar estos archivos individualmente. Esto implica importantes cambios en el archivo generate_tiles.py para que cumpla nuestro propósito.
Como comentaba, después de algunas pruebas hemos obtenido los primeros resultados, consiguiendo por ahora una solución que detallaré en otro post.