Taller de OpenStreetMap, Imposm y TileMill¶

Toma de datos¶

Los datos se recopilan por observación directa, preferentemente empleando GPS, aunque pueden emplearse otros medios como fotografía aérea si los derechos de la imagen lo permite. Aún así el proyecto recomienda conocer y recorrer la zona personalmente para garantizar la máxima calidad del resultado.

Los orígenes más comunes de datos son:

• Trazas GPS, resultado de recorrer la zona usando un dispositivo GPS que almacene dicha información.
  • También suelen usarse waypoints, fotos geolocalizadas y archivos de audio geolocalizados
• Imágenes de Yahoo, Bing Maps, el PNOA en España, Landsat y en general cualquier imagen cuyos derechos de autor hayan sido expresamente cedidos, se hayan extinguido o estén en el dominio público.
• Mapas e información de los usuarios. Siempre que se trate de información en el dominio público o cuyos derechos de autor hayan sido expresamente cedidos.
• Información previa existente que requiera ser incluida en un mapa.

Subida de datos a los servidores de OpenStreetMap¶

Una vez recopilada la información, esta debe ser incorporada a la base de datos de OSM. Para ello existen diversos medios, aunque principalmente se emplean clientes web como iD:

y el cliente de escritorio JOSM:

En cualquier caso lo más frecuente es convertir los datos GPS tomados al formato estándar GPX y subirlos posteriormente al repositorio de trazas GPS de OSM de forma que cualquier usuario pueda acceder a dicha información.

Renderizado de los mapas¶

El proyecto OSM tiene varios motores de renderizado tanto en 2D como en 3D que permiten obtener una imagen de la información de la base de datos.

Los principales motores de renderizado son:

• Osmarender En realidad se trata más bien de un conjunto de reglas XLST que genera SVG.

• Mapnik Toma los datos y los carga en un PostGIS para posteriormente renderizar tiles de 256x256. Es el motor de render más utilizado actualmente.

La API de OSM¶

La API de OSM es el único medio de modificar datos de la base de datos. Todas las aplicaciones que quieran obtener datos y subir datos a la base de datos de OSM lo tienen que hacer usando dicha API.

La versión actual de la API es la v0.6 y su uso es obligatorio desde 2009.

La API es una API RESTful de edición, esto quiere decir que utiliza directamente el HTTP para manipular la información y que recibe los mensajes y resultados en formato XML.

Toas las consultas se realizan de forma anónima, pero las actualizaciones se realizan usando OAuth (son necesarios un usuario y una contraseña válidos)

La API da soporte de versionado directamente, de forma que todas las actualizaciones quedan registradas con un número de versión de forma que permite detectar errores y conflictos de manera eficiente.

Las descargas están limitadas a cuadrados de 15’ de arco y además existe una limitación de ancho de banda, de forma que si se excede la primera limitación el sistema responde un mensaje de error y si se excede la segunda se bloquearán los accesos de manera temporal.

La API no está enfocada a consulta, sino a edición, para consultar la base de datos es más eficiente emplear otros métodos que básicamente consisten en obtener uno de los archivos Planet, convertirlo a una base de datos local y consultar sobre ésta.

PUT /api/0.6/changeset/create
PUT /api/0.6/changeset/#id/close
PUT /api/0.6/[N|W|R]/create
DELETE /api/0.6/[N|W|R]/#id

<osm>
  <changeset>
    <tag k="created_by" v="JOSM 1.61"/>
    <tag k="comment" v="Just adding some streetnames"/>
    ...
  </changeset>
  ...
</osm>

GET /api/0.6/[N|W|R]/#id/relations
GET /api/0.6/node/#id/ways
GET /api/0.6/[W|R]/#id/full

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="OpenStreetMap server">
  <gpx_file id="836619" name="track.gpx" lat="52.0194" lon="8.51807"
            user="Hartmut Holzgraefe" visibility="public" pending="false"
            timestamp="2010-10-09T09:24:19Z">
    <description>PHP upload test</description>
    <tag>test</tag>
    <tag>php</tag>
  </gpx_file>
</osm>

OSM XML Data: el formato OpenStreetMap¶

El formato de intercambio estándar de la API es un XML compuesto por combinaciones de los cuatro elementos principales.

Nodos (Node)¶

Los Nodos tienen, entre otras informaciones, las siguientes características:

• id: el identificador
• lat y lon: la posición geográfica en EPSG4326
• visible: boolean que determina la visibilidad
• user: usuario que creó la versión del nodo
• timestamp: marca de tiempo de creación
• version: incremental para cada objeto.

Además el Nodo puede contener información asociada al estilo OSM a traves de pares key/value

<node id="25496583" lat="51.5173639" lon="-0.140043" version="1" changeset="203496" user="80n" uid="1238" visible="true" timestamp="2007-01-28T11:40:26Z">
    <tag k="highway" v="traffic_signals"/>
</node>

Vías (Way)¶

Las Vías son listas ordenadas de nodos que tienen información como:

• id: el identificador
• visible: boolean que determina la visibilidad
• user: usuario que creó el nodo
• timestamp: marca de tiempo de creación
• version: incremental para cada objeto.

Debe tener una lista de nodos agrupados cada uno con su etiqueta XML nd con la referencia id de los nodos que agrupa. Además la Vía puede contener información asociada al estilo OSM a traves de pares key/value

<way id="5090250" visible="true" timestamp="2009-01-19T19:07:25Z" version="8" changeset="816806" user="Blumpsy" uid="64226">
    <nd ref="822403"/>
    <nd ref="21533912"/>
    <nd ref="821601"/>
    <nd ref="21533910"/>
    <nd ref="135791608"/>
    <nd ref="333725784"/>
    <nd ref="333725781"/>
    <nd ref="333725774"/>
    <nd ref="333725776"/>
    <nd ref="823771"/>
    <tag k="highway" v="unclassified"/>
    <tag k="name" v="Clipstone Street"/>
    <tag k="oneway" v="yes"/>
</way>

Relaciones (Relation)¶

Las Relaciones son listas ordenadas de objetos, son objetos en si mismas y sirven para definir relaciones entre cualquier tipo de objeto. También tienen información como:

• id: el identificador
• visible: boolean que determina la visibilidad
• user: usuario que creó el nodo
• timestamp: marca de tiempo de creación

Y además en una etiqueta XML member definir atributos type, id y role que permiten configurar la relación y unas etiquetas tag para describir el tipo de relación.

<relation id="77" visible="true" timestamp="2006-03-14T10:07:23+00:00" user="fred">
  <member type="way" id="343" role="from" />
  <member type="node" id="911" role="via" />
  <member type="way" id="227" role="to" />
  <tag k="type" v="restriction"/>
  <tag k="type" v="no_left_turn"/>
</relation>

Etiqueta (Tag)¶

Pese a ser una primitiva reconocida por la API de OSM en realidad está integrada dentro de las otras primitivas y nos permite definir los atributos de las mismas.

Crear un script de actualización y arranque en Linux¶

Si se utiliza un sistema Linux u OSX y no se dispone de soporte para Java Web Start se puede crear un script como el siguiente para automatizar la descarga de la versión más reciente de JOSM antes de ejecutarlo. Esto resulta interesante porque JOSM se actualiza con mucha frecuencia.

El script sería el siguiente:

#!/bin/bash

cd /tmp
wget -N http://josm.openstreetmap.de/josm-tested.jar
java -jar josm-tested.jar

A este script bastaría con darle permisos de ejecución y ubicarlo en algún lugar accesible. Al ejecutarlo comprobará si la versión de JOSM es la más reciente y de no ser así la descargará. Después lanzará automáticamente el programa.

Carga de datos GNSS¶

JOSM permite cargar información obtenida a través de un receptor GNSS usando para ello el formato de intercambio estandar GPX.

Cargar servicios de imágenes¶

Además de utilizar los datos recogidos en campo con GPS, notas, etc. se pueden también usar imágenes en distintos formatos para usarlas como cartografía de referencia y poder digitalizar sobre ellas.

En especial tienen significativa importancia dentro de JOSM la posibilidad de cargar imágenes base provenientes de diversos proveedores a través de Internet cuya información ya viene integrada en el propio JOSM o incluso se pueden agregar nuevos como por ejemplo orígenes de datos WMS o TMS. En España está autorizado el uso del PNOA y del Catastro para digitalizar sobre las ortofotos siempre que se identifiquen el origen y la resolución temporal con las etiquetas source y sourcedate.

Se puede acceder a la configuración de los proveedores a través del menú Editar ‣ Preferencias ‣ WMS/TMS. Primero se busca el proveedor a partir del código de país y una vez seleccionado se puede hacer clic en el botón Activar y confirmar el diálogo.

Tras los cambios aparentemente nada habrá cambiado, pero ahora hay una nueva entrada en el menú Imágenes y al pulsarla se cargará una capa, debajo de la capa de datos actual, con la ortofotografía de la zona. Es una capa que se puede activar o desactivar , o cambiar la transparencia .

Nodos¶

Digitalizamos los árboles poniendo un punto, haciendo un solo clic, sobre cada copa de la ortofotografía. JOSM está pensado para añadir elementos lineales por lo que por defecto espera tener que añadir líneas, para añadir tan solo puntos deberemos pulsar la tecla Esc después de hacer clic sobre cada árbol.

De momento en realidad estamos simplemente poniendo los Nodos. Para que OSM los reconozca como árboles deberíamos añadir también las Etiquetas, como veremos más adelante.

Vías¶

Para digitalizar una vía, buscaremos un nivel de zoom que nos permita ver la vía en su totalidad por lo menos una parte muy significativa de ella. Puede que tengamos que desplazarnos por la imagen, pero como estamos en modo edición si hacemos clic con el botón izquierdo añadiríamos un nuevo nodo. Para desplazarnos sin salir del modo edición podemos conseguirlo haciendo clic en el botón derecho del ratón y movernos por el mapa sin soltarlo.

Para digitalizar la vía vamos marcando nodos de manera consecutiva intentando seguir el eje de esta y respetar la forma siguiéndola sobre la ortofotografía. Es interesante que además pongamos un nodo en cada intersección que tenga la vía, lo que facilitará digitalizar las vías que conectan con ésta más adelante.

Un par de atajos de teclado útiles a la hora de digitalizar vías:

• Pulsar la tecla Alt mientras digitalizas vías, te permite hacer que el próximo nodo, aunque esté conectado al nodo anterior, forme una vía nueva.
• Cuando tenemos una vía seleccionada (también funciona con vías cerradas) tener la tecla Shipt + Ctrl pulsada te permite rotar el elemento seleccionado.
• Si pulsamos Ctrl + Alt podremos cambiar la escala del elemento seleccionada.
• Por último, si mientras digitalizamos hacemos clic con el ratón en el ángulo de la barra inferior (el cuarto elemento) activaremos el modo de ayuda de dibujado de geometrías que nos asiste con ángulos establecidos e intersecciones.

Áreas¶

Las áreas no son más que una vía que empieza y acaba en el mismo punto y tiene una etiqueta que la identifica.

En este ejemplo, digitalizaremos el área de aparcamiento que hay en la zona en la que estamos trabajando, teniendo en cuenta que deberemos cerrar la vía pulsando al final sobre el primer nodo que digitalicemos.

Los edificios son seguramente el caso más típico de áreas a digitalizar.

La herramienta Crear áreas¶

Existen diversas herramientas que permiten manipular las geometrías, una de las más interesantes (especialmente combinada con la anterior) es la de Crear áreas. Esta herramienta permite mover una sección de un área hacia fuera o dentro en paralelo a la dirección existente. En la figura Dibujar un edificio ortogonal se muestra el proceso.

1. Dibujar un edificio con el modo Edificio (en este caso sobre la terraza)
2. Dibujar los puntos de corte de la zona de la fachada a desplazar
3. Mediante la herrameinta Crear áreas llevar meter la fachada hacia dentro
4. Mover el edificio a su ubicación en la parte inferior

Dibujar un edificio ortogonal

¿Qué etiquetas se emplean para indicar que es un árbol?¶

Lo mejor SIEMPRE es consultar la wiki de OSM donde tienen un listado de elementos comunes en los mapas Map Features en español y cómo emplearlos. En este caso buscaremos la entrada de árbol en la página y vemos que se corresponde con el par clave/valor natural/tree.

Pero además si pulsamos sobre la palabra tree nos lleva a la entrada específica de la wiki en la que explican las características a tener en cuenta y generalmente se detallan las claves a las que también suelen estar asociadas las entidades a cartografiar e incluso ejemplos.

En definitiva, los árboles suelen etiquetarse usando las siguientes claves:

• natural con el valor tree
• name
• type
• height
• name:botanical

Pueden asignarse etiquetas a grupos de elementos, para lo que primero hay que seleccionarlos manteniendo pulsada la tecla Mayúsculas mientras se va haciendo clic; para posteriormente aplicar la etiqueta, según el procedimiento ya visto.

También pueden copiarse etiquetas entre elementos, seleccionamos el elemento que tiene las etiquetas y lo copiamos con Ctrl + C y después seleccionamos el elemento destino y pulsamos Ctrl + Shift + V y le asignará automáticamente las etiquetas del primer elemento.

Ahora hay que proceder igual con los demás elementos de nuestro dibujo, tales como carreteras, parkings, edificios, etc...

Consultaremos los elementos en su página correspondiente y añadiremos las etiquetas que creamos sean necesarias para describir la realidad. El resultado tras aplicar las etiquetas podría ser parecido a este:

Añadir etiquetas predefinidas¶

Añadir las etiquetas una a una es muy costoso. En lugar de hacerlo de esta forma, JOSM ofrece todo un conjunto de diálogos predefinidos para los tipos de datos más comunes. Para ello una vez añadida o seleccionada la geometría (vía o nodo) podemos usar la entrada de menú Predefinidos y navegar por los diferentes tipos de datos. Por ejemplo para dar de alta una rotonda podemos navegar a Predefinidos ‣ Viales ‣ Calles/Carreteras ‣ Rotonda.

Si ya sabemos cómo se identificia un elemento en el menú, resulta muy cómodo usar el buscador que se lanza con la tecla F3. Por lo tanto, basta con empezar a escribir Rotonda para que el buscador encuentre nuestra etiqueta.

De cualquiera de estas dos formas, al final llegaremos a un diálogo que ofrece una interfaz para añadir las etiquetas más comunes referidas al tipo seleccionado, usando listas para elegir las opciones más habituales, botones de tipo check para indicar características que solo toman un valor e incluso disponemos de un enlace a la documentación ampliada en el wiki del proyecto y un botón que nos permite «anclar» el elemento a la barra de herramientas en caso de que vayamos a usar mucho este tipo de elemento.

Especificar las fuentes¶

Es muy importante identificar los orígenes de datos de la información, ya que es una de las formas de medir la calidad de los datos que almacena OSM.

En España, si se digitalizan datos sobre la ortofotografía del PNOA hay que añadir a TODOS los elementos digitalizados el par clave valor source/PNOA y a ser posible la clave source:date cuyo valor corresponde con la fecha en la que se realizó el vuelo

Otros posibles orígenes de datos válidos para usar en España se pueden encontrar listados en la página web Spain Datasources de la wiki de OpenStreetMap.

Si podemos instalar paquetes en el entorno virtual¶

Crear el entorno virtual e instalar los paquetes necesarios ejecutando:

$ virtualenv venv
$ source venv/bin/activate
(venv)$ pip install imposm rtree

Si no podemos instalar paquetes en el entorno virtual¶

Descargamos un entorno virtual ya preparado y nos aseguramos de descomprimirlo en la carpeta /home/user/tallerimposm. Una vez descargado lo activamos con:

$ cd /home/user/tallerimposm
$ source venv/bin/activate

Comprobar la versión de imposm¶

Para comprobar la versión de imposm ejecutamos:

(venv)$ imposm --version

Y deberíamos obtener:

Enabling Shapely speedups.
imposm 2.5.0

Lectura¶

Se realiza empleando el comando:

$ imposm --read /usr/local/share/data/osm/Nottingham.osm.bz2

Como la cantidad de datos no es muy grande, solo tardará unos segundos. Una vez acaba podemos comprobar que ha creado los archivos de cache listando los archivos del directorio:

$ ls

imposm_coords.cache  imposm_nodes.cache  imposm_relations.cache  imposm_ways.cache  venv

Imposm ha generado los archivos .cache que son archivos binarios con los datos preparados para ser incluidos en la base de datos.

Escritura¶

Se realiza empleando el comando:

(venv)$ imposm --database nott-osm --host localhost --user user --write

Solicitará la constraseña del usuario user y cargará los datos que hay en los archivos .cache.

Podemos investigar qué ha hecho Imposm lanzando la aplicación pgAdmin III que está instalada en la máquina virtual en el menú Development. Podemos comprobar que ha creado 24 tablas nuevas, todas con el sufijo new_

El esquema de tablas y qué etiquetas ha importado son los estándar ya que aún no hemos cambiado los mappings. En concreto podremos encontrar:

• Amenities
• Places
• Transport_points
• Administrative polygons
• Buildings
• Landusages
• Aeroways
• Waterareas
• Roads (en realidad repartidas en varias tablas en función de la categoría)
• Railways
• Waterways

También vienen unas tablas con geometrías de las vías de transporte generalizadas en función de dos tolerancias y unas vistas que agrupan todas las carreteras.

Optimización¶

El último paso de la carga de datos sería la optimización de los datos que se realiza empleando el comando:

(venv)$ imposm --database nott-osm --host localhost --user user --optimize

Todo en un paso¶

En realidad los tres pasos anteriores se podrían ejecutar en un solo comando:

$ imposm --database nott-osm --host localhost --user user  \
    --read --write --optimize /usr/local/share/data/osm/Nottingham.osm.bz2

Pasar a producción¶

El flujo de trabajo recomendado permite el despliegue de las tablas conservando hasta 3 versiones a la vez del mismo juego de datos. El despliegue se inicia al ejecutar el comando:

$ imposm --database nott-osm --host localhost --user user --deploy-production-tables

La importación de datos se hace sobre tablas a las que se le añade el prefijo osm_new_ en el nombre. Podremos comprobar con pgAdmin III como se ha cambiado el nombre de todas las tablas perdiendo el prefijo new_. Si ya hubiéramos hecho otro despliegue las actuales tablas osm_ se renombrarán automáticamente a osm_old_. Cada vez que se hace un despliegue se borrarán primero las osm_old_.

Si volvemos a cargar la cache y a pasar a producción las tablas con:

$ imposm --database nott-osm --host localhost --user user \
   --write --optimize --deploy-production-tables

veremos como las tablas que no tengan prefijo pasarán a tener el prefijo old_.

Revertir el despliegue y borrar tablas temporales¶

Para revertir el despliegue se puede ejecutar el comando:

$ imposm -d osm --recover-production-tables

Finalmente para borrar definitivamente las tablas marcadas con old_ y las marcadas con new_ se emplea el comando:

$ imposm --database nott-osm --host localhost --user user --remove-backup-tables

Tablas¶

Hay definidas tres clases de Python para las geometrías base: Points, LineStrings y Polygons y todas las tablas tienen que ser instancias de una de ellas. Las tres clases usan los mismos argumentos:

name

Nombre de la tabla (sin prefijos).

mapping

El mapping de los pares clave/valor básicos que se meterán en la tabla.

fields

El mapping de campos adicionales que también son pares clave/valor de OSM y que se convertirán en columnas de la tabla.

field_filter

Filtros que permitan discriminar los datos que se introducen.

mapping¶

El argumento Mapping debe ser un diccionario (un diccionario de Python) en la que las claves de OSM (p.e. highway, leisure, amenity, etc.) son las claves del diccionario y los valores de OSM (p.e. motorway, trunk, primary, etc.) los valores de las claves del diccionario.

Para una tabla de paradas de autobús, de tranvía y de ferrocarril el mapping debería ser parecido a este:

mapping = {
    'highway': (
        'bus_stop',
    ),
    'railway': (
        'station',
        'halt',
        'tram_stop',
    )
}

fields¶

El argumento fields debe ser una lista (o una tupla) con el nombre de la columna y su tipo de dato. Se emplea para añadir información adicional a la tabla. Imposm tiene clases para los tipos de datos más comunes que son las responsables de hacer sustituciones como 1, yes y true a TRUE en caso de datos booleanos por lo que se recomienda su uso:

fields = (
    ('tunnel', Bool()),
    ('bridge', Bool()),
    ('oneway', Direction()),
    ('ref', String()),
    ('z_order', WayZOrder()),
)

En el ejemplo la línea ('tunnel', Bool()) convertirá los valores de la clave tunnel a valores booleanos.

Ejemplo¶

 towers = Points(
   name = 'towers',
   mapping = {
     'man_made': (
       'tower',
       'water_tower',
     )
   }
   fields = (
     ('height', Integer()),
   )
)

Ampliando el esquema por defecto¶

El esquema que carga Imposm por defecto es generalmente insuficiente ya que se suele emplear un abanico de datos mucho más amplio.

Por ejemplo, en nuestro caso no se está incluyendo en la base de datos ningún registro de los siguientes tipos y subtipos:

• Amenity
  • restaurant
  • pub
  • cafe
  • place of worship
  • parking
• Natural
• Tourism
• Barrier

Por lo que debemos modificar el archivo de mapping para que los incluya. El archivo mapping se encuentra en la siguiente localización:

/usr/local/lib/python2.7/dist-packages/imposm/defaultmapping.py

lo copiamos y editamos empleando los siguientes comandos:

(venv)$ cd ~/tallerimposm
(venv)$ cp venv/lib/python2.7/site-packages/imposm/defaultmapping.py mappingtaller.py
(venv)$ medit mappingtaller.py

Buscamos la cadena amenities = Points usando el comando buscar de medit pulsando en la lupa de la barra de herramientas.

Como podemos ver, Imposm por defecto tiene determinados tipos de Amenity cuando son puntos pero no tiene ninguno de los indicados en la lista referida un par de párrafos más arriba.

Vamos a añadir al argumento mapping los elementos que le faltan (no importa el orden) respetando la sintaxis de tuplas de Python de forma que quede de la siguiente manera:

amenities = Points(
    name='amenities',
    mapping = {
        'amenity': (
            'university',
            'school',
            'library',
            'fuel',
            'hospital',
            'fire_station',
            'police',
            'townhall',
            'restaurant',
            'pub',
            'cafe',
            'place_of_worship',
            'parking',
        ),
})

El caso de los árboles (natural/tree) es distinto ya que por defecto Imposm no incluye un mapping para la clave Natural, por lo que la crearemos desde cero, justo debajo del objeto amenities vamos a crear un nuevo objeto para poder importarlos.

arboles = Points(
    name = 'arboles',
    mapping = {
        'natural': (
            'tree',
        ),
    },
)

Guardamos el archivo con y salimos de medit.

Ejecutamos el comando para escribir y optimizar los datos en la base de datos:

(venv)$ imposm --database nott-osm --host localhost --user user \
  --read /usr/local/share/data/osm/Nottingham.osm.bz2 \
  --write --optimize --deploy-production-tables \
  --overwrite-cache --remove-backup-tables -m mappingtaller.py

En este caso es necesario volver a leer los datos y generar los archivos de cache, ya que hemos modificado la estructura de los datos. Con la opción --overwrite-cache se sobrescribirán directamente los archivos necesarios.

Con pgAdmin podemos comprobar como se han importado 1059 árboles y si echamos un vistazo a la tabla osm_amenities veremos que se han importado puntos con las etiquetas que hemos elegido.

Ejercicio¶

Como ejercicio del taller se propone crear el mapping, escribir los datos en la base de datos y desplegar las tablas para las claves de OSM siguientes:

tourism (71 puntos nuevos):

information, hotel, artwork y attraction

barrier (1688 puntos nuevos):

gate, bollard, entrance, cycle_barrier, lift_gate, stile y fence

Formatos vectoriales admitidos¶

CSV

Se trata de archivos de hoja de cálculo con variables separadas por comas y que tienen la información geográfica en columnas que se llaman «lat» o «latitude» o incluso «geo_longitude», TileMill reconoce automáticamente el nombre de esas columnas.

ESRI Shapefile

Uno de los formatos vectoriales más populares antiguamente. Si el archivo .prj no está presente TileMill intentará averiguar el SRS de la información contenida.

KML

Este formato soportado, tiene algunas limitaciones para ser usado en TileMill ya que no reconoce algunas de las funcionalidades avanzadas de los KMLs (estilos embebidos, imágenes, modelos 3D). Tampoco reconoce el formato KMZ.

GeoJSON

Es uno de los formatos más populares actualmente, es un formato basado solamente en texto con una estructura flexible.

Formatos raster admitidos¶

GeoTIFF

Es uno de los formatos más conocidos para almacenar imágenes aéreas, satélite y modelos de elevación del terreno. Para manipular la información raster TileMill emplea GDAL que es una potentisima biblioteca de acceso a datos raster.

Bases de datos admitidas¶

SQLite

Es el sistema de bases de datos basadas en un solo archivo más popular del Software Libre. Estas bases de datos se pueden generar empleando un software de escritorio como QGis.

PostGIS

Literalmente el elefante en la habitación. El mayor proyecto de base de datos relacional geográfica del Software Libre.

Pintando puntos¶

#osm_puntos {
  marker-width: 6;
  marker-fill: #EE0000;
  marker-line-color: #55060f;
}

Existen dos tipos de puntos Point y Marker entre los dos suman 30 propiedades.

Pintando lineas¶

#osm_lineas {
  line-width:1;
  line-color:#168;
}

Existen 19 propiedades distintas para las ĺíneas.

Pintando áreas¶

#osm_buildings {
    line-color: darken(#ccc,40%);
    line-width: 2;
    polygon-opacity: 1;
    polygon-fill: #ccc;
}

Existen 5 propiedades distintas para las áreas.

Pintando con clase¶

También se pueden usar clases y condiciones para filtrar las propiedades por atributos o por el nivel de zoom en el que nos encontremos. Finalmente los selectores se pueden anidar para compartir propiedades. Más información en la documentación sobre selectores.

En el ejemplo siguiente se seleccionan todos los puntos de la capa osm_puntos que tengan algún dato en el campo tourism (pidiendo que sea distinto a la cadena de texto vacía) y se aplicará solo a partir del nivel de zoom 14. En ese selector se establecen unas propiedades generales de tamaño y color del borde y a continuación se anidan selectores por cada una de las clases a renderizar estableciendo solo la propiedad que va a cambiar, es decir, el color del símbolo.

#osm_puntos[tourism!=""][zoom>13]{
    /** propiedades generales **/
    marker-width: 8;
    marker-line-color: #000;

    /** temático por tipo de turismo **/
    [tourism="artwork"]{
      marker-fill: #a6cee3;
    }
    [tourism="attraction"]{
      marker-fill: #1f78b4;
    }
    [tourism="gallery"]{
      marker-fill: #b2df8a;
    }
    [tourism="hostel"]{
      marker-fill: #33a02c;
    }
    [tourism="museum"]{
      marker-fill: #e31a1c;
    }
}

Y alguna cosilla más¶

El uso de @ te permite definir variables

/** colores para agua y bosque**/
@water : #c0d8ff;
@forest: #cea;

/** estilos para usos del suelo
    de para agua y bosque **/
#landusage{
    /* características generales */
    line-color: #000;
    line-width: 2;
    polygon-opacity: 1;

    [type="water"]{
      polygon-fill: @water;
    }
    [type="wood"]{
      polygon-fill: @forest;
    }
}

Y existen funciones para operar sobre los colores para aclararlos, oscurecerlos, etc. (referencia de color) :

@border-water: darken(@water,50%);

En algo como esto:

@water  : #c0d8ff;
@forest : #cea;

/** los bordes más oscuros **/
@border-water  : darken(@water,50%);
@border-forest : darken(@forest,50%);

#landusage{
    /* características generales */
    line-width      : 2;
    polygon-opacity : 1;

    [type="water"]{
      polygon-fill : @water;
      line-color   : @border-water;
    }
    [type="wood"]{
      polygon-fill : @forest;
      line-color   : @border-forest;
    }
}

Añadiendo una capa de puntos¶

Procederemos ahora a añadir nuestra primera capa de puntos, para lo que desplegaremos el menú de capas pulsando en el botón y seleccionamos + Add layer

En la ventana que aparece seleccionaremos la opción de PostGIS y rellenamos los campos como se indica.

ID

osm_puntos

Class

puntos

Connection

dbname=nott-osm host=localhost port=5432 user=user password=user

Table or subquery

osm_places

Unique key field

osm_id

Geometry field

geometry

SRS

Seleccionamos 900913

Y pulsamos Save & Style para que añada los datos con un estilo por defecto.

Veremos como inmediatamente aparece un punto en la zona de Inglaterra.

Corrigiendo la visualización por defecto¶

En realidad nuestra zona de trabajo es bastante más pequeña que la que muestra por defecto TileMill, por lo que modificaremos las preferencias para que muestre por defecto una zona más ajustada a nuestro juego de datos. Para ello pulsaremos en el botón de configuración del proyecto y lo configuramos de la siguiente forma:

Zoom

Desplazar las barras para que los niveles de zoom estén entre 12 y 20

Center

-1.1476,52.9531,12

Bounds

-1.2488, 52.9083, -1.0771, 53.0076

Añadiendo elementos lineales¶

Para representar las calles utilizaremos una de las ayudas que proporciona ImpOSM; como ya hemos dicho, por defecto separa las vías en varias tablas, pero también crea una vista de PostGIS que aglutina toda la información relativa a estas.

Añadiremos una nueva capa de PostGIS que lea la información de la tabla osm_roads

Para obtener todos los distintos tipos de vía podemos usar emplearemos pgAdmin III donde podemos lanzar la consulta:

SELECT type as tipo, count(type) as total
FROM osm_roads
GROUP BY type
ORDER BY total DESC, tipo;

Añadiremos una entrada para cada tipo de vía.

• residential
• footway
• service
• cycleway
• tertiary
• unclassified
• primary
• steps

Para representarlo usaremos el código como el siguiente:

#osm_lineas {
    line-width:1;
    line-color:#cce;
    [type = 'footway'], [type = 'cycleway'] {
          line-color:#f2f974;
    }
    [type = 'residential'],     [type = 'service']  {
          line-color:#aaa;
    }
    [type = 'steps'] {
          line-color:#7cc7fd;
    }
    [type = 'unclassified'] {
          line-color:#ff9f3b;
    }
    [type = 'primary'] {
          line-width:2;
          line-color:darken(#ff9f3b, 30%);
    }
    [type = 'tertiary'] {
          line-width:1.5;
          line-color:darken(#8beb18, 10%);
    }
}

Añadiendo los edificios¶

Añadiremos ahora los edificios, que están en la tabla osm_buildings.

#osm_edificios {
  line-color:#a71b62;
  line-width:0.5;
  polygon-opacity:1;
  polygon-fill:#d86ebb;
}

Añadiendo etiquetas¶

Por último, añadiremos los nombres de las calles, para lo cual primero tenemos que definir una variable, preferentemente al principio de todas las definiciones, que tenga el nombre de la fuente y las posibles fuentes sustitutas si la fuente no está instalada en el sistema.

@futura_med: "Futura Medium","Function Pro Medium","Ubuntu Regular","Trebuchet MS Regular","DejaVu Sans Book";

TileMill incorpora un gestor de fuentes que nos permite ver qué fuentes hay instaladas en el sistema al que se accede empleando el botón de fuentes , las fuentes instaladas aparecen en negrita y el gestor nos permite copiar y pegar literalmente el nombre de la fuente.

Aunque la capa de calles ya tiene el campo name que es el que vamos a utilizar, es siempre muy recomendable volver a añadir la capa y usarla exclusivamente para las etiquetas. En este caso rellenaremos los campos con los siguientes datos:

ID

calles_nombres

Class

nombres

Connection

dbname=nott-osm host=localhost port=5432 user=user password=user

Table or subquery

(SELECT * FROM osm_roads WHERE name IS NOT NULL) AS foo

Unique key field

osm_id

Geometry field

geometry

SRS

Seleccionamos 900913

En esta ocasión en vez de la tabla, hemos usado una subconsulta, de forma que solo carguemos en memoria las entidades que tengan algún valor en el campo name. A las subconsultas hay que añadirles un alias para que TileMill las reconozca.

TileMill habrá asignado a la capa un estilo por defecto para capas de líneas, aunque nosotros lo vamos a modificar para que represente textos:

#calles_nombres {
    text-name: "[name]";
    text-face-name: @futura_med;
    text-placement: line;
}

Estos son los elementos mínimos para que una etiqueta aparezca en TileMill, aunque si vamos a la ayuda del programa y vemos la sección text veremos que las etiquetas tienen 30 opciones de configuración distintas.

Usando iconos como marcadores¶

Para usar los iconos deben referenciarse con una ruta relativa a la carpeta del proyecto

Por ejemplo para pintar puntos de interés

.amenity.place[zoom=15] {
  [type='police']{
    point-file: url(../res/comi-9px.png);
  }
  [type='fuel'] {
    point-file: url(../res/petrol-9px.png);
  }
  [type='townhall'],
  [type='university'] {
    point-file: url(../res/poi-9px.png);
  }
}

Pintando cajas de carretera¶

.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;
  }
}

.highway[zoom=13] {
  .line[TYPE='motorway']      { line-width: 2.0 + 2; }
  .fill[TYPE='motorway']      { line-width: 2.0; }
}

Montando un TMS¶

Como hemos visto, TileMill genera un fichero en formato MBTiles para poder llevar nuestra renderización de un sitio a otro fácilmente. En ocasiones por otro lado, resulta conveniente exportar las teselas almacenadas en la base de datos de este formato a una estructura de carpetas siguiendo el estándar TMS, ya que de esta forma puede resultar accesible por ejemplo por un cliente web como OpenLayers.

Para extraer las imágenes de este tipo de ficheros podemos usar la herramienta mbutil, desarrollada por Mapbox y que ofrece un ejecutable para la línea de comandos que exporta el fichero fácilmente.

Para instalarla teniendo un entorno virtual activado basta con ejecutar:

(venv)$ pip install mbutil

Para generar un TMS ejecutamos:

(venv)$ mb-util --scheme=tms exportado.mbtiles directorio/

Extensiones¶

TileMill es un software que dispone de extensiones conocidas como plugins. Esta funcionalidad se introdujo a partir de la versión 0.9 aprovechando que NodeJS, el software sobre el que está construído., facilitó el mecanismo para gestionarlos.

Las funcionalidades principales de TileMill se agrupan en cuatro extensiones básicas que no se pueden desactivar (marcadas como Core) y 7 extensiones opcionales disponibles que añaden funcionaliades diversas como poder ver el mapa en varios niveles de zoom a la vez, poder utilizar mapas de Mapbox como mapa base o poder ordenar las columnas en la vista de tabla.

Mapas interactivos¶

TileMill admite cierta interactividad que se puede configurar para cada mapa. Esta interactividad solo es útil si se va a subir el mapa al servicio de alojamiento de teselas de Mapbox, ya que en los productos generados revisados (imágenes, MBTiles, etc.) no se puede acceder a esta funcionaliad. El proyecto Geography Class está cargado por defecto en la instalación de TileMill y es un ejemplo excelente de interacción en el mapa.

Las dos características más interesantes a configurar son:

• Leyenda: aparecerá sobre el mapa en la esquina inferior derecha. Se trata de un documento HTML estático que deberemos editar directamente en TileMill.
• Tooltip: se configura una plantilla en HTML en la que se puede hacer referencia a los valores del objeto sobre el que el ratón se posiciona. El tooltip solo puede acceder a los campos de una única capa.

Estas opciones se establecen haciendo clic sobre el icono con forma de mano en la parte inferior izquierda de la interfaz de TileMill.

Vías¶

Se destacará la red viaria de forma que exista una clasificación de carreteras que permita identificar visualmente los siguientes tipos:

• motorway y motorway_link
• trunk y trunk_link
• primary y primary_link
• secondary y secondary_link
• tertiary
• residential
• pedestrian, path y cycleway
• rail
• resto

Tabla

osm_roads

Edificios¶

Se destacará el entramado urbano que permita diferenciar los siguientes tipos:

• city_hall, conservatory y museum
• college, library y university
• flat, flats, house y residential
• industrial, light_industry_units
• retail, shop, shopping_mall y shops
• resto

Tabla

osm_buildings

Áreas¶

Se destacarán con un color distinto debajo de la capa de edificios las siguientes áreas urbanas:

• commercial, retail
• hospital
• industrial
• nature_reserve, park, wood
• residential
• university

En caso de existir una correspondencia entre un tipo de edificios y un área, el área deberá ser un 20% más oscura que el edificio pero emplear el mismo tono, además los polígonos de área deberán tener una opacidad del 10%.

¿Qué tabla hay que emplear? Abre la aplicación Geospatial ‣ Databases ‣ pgAdminIII y explora la base de datos nott-osm para averiguar dónde está la información.

Lugares de interés¶

Para la simbología de lugares de interés emplearemos la biblioteca de símbolos Maki desarrollada también por la empresa Mapbox y el código que hemos visto en la sección Usando iconos como marcadores. Se representarán las comisarías de policía y los hospitales cada uno con su símbolo puntual distintivo.

La biblioteca de iconos Maki ha sido especialmente diseñada para ser empleada con TileMill y proporciona los iconos tanto en formato raster (.png) como en formato vectorial (.svg). En la página web está el enlace para descargar la biblioteca en ambos formatos en un archivo .zip. También se puede encontrar el enlace a un tutorial sobre las posibilidadesde empleo en TileMill.

Para usar las imágenes de Policía y Hospital:

1. Crearemos una carpeta imgs dentro del directorio del proyecto que podemos encontrar en /home/user/Documents/MapBox/project/cfp2014.
2. Descomprimimos el archivo .zip, que es una copia del repositorio de GitHub, y navegamos hasta la carpeta renders.
3. Copiaremos las imágenes police*.png y hospital*.png en el directorio imgs que hemos creado anteriormente.