.. _revison: ====================== Revisión de los datos ====================== .. note:: Texto extraído de la `guía de coordinación de OSM `_ .. contents:: Contenidos :depth: 3 :backlinks: none .. important:: Esta sección cubre los procesos de control de la calidad de los datos, particularmente en el contexto de un proyecto dirigido de cartografiado de OSM, como los que lleva acabo el `Humanitarian OpenStreetMap Team `_ en varios países y como los proyectos `Open Cities `_ en Bangladesh, Sri Lanka y Nepal. Los métodos mostrados pueden resultar de utilidad en otros contextos, cuando el control de calidad sea una tarea habitual. Cuando intentamos cartografiar un conjunto completo de elementos y atributos de un área determinada, necesitamos maneras de comprobar los errores y maneras de asegurar la precisión del trabajo. En este tutorial trabajaremos con diferentes métodos para revisar datos, para cada método explicaremos los pasos a dar y sus razones para darlos. Un proyecto de cartografía bien gestionado incluirá cada uno de estos tres procesos, de forma que se evalúen y corrijan los datos, así como para realizar informes. - Comprobaciones diarias - Repetición del trabajo - Sentencias SQL Estos métodos de comprobación son cada vez más importantes a medida que el modelo de datos crece y el número de elementos registrados se convierte en una cantidad bastante grande. Por ejemplo, no llevaría mucho tiempo ni esfuerzo el crear un modelo de datos que solamente involucrara puntos de interés (POIs por sus siglas en inglés): .. image:: img/reviewing_osm_data_image01.png :align: center En este caso las preguntas que habría que contestar podrían ser: - ¿Los POIs han sido cartografiados en todos los lugares? - ¿Hay algún POI al que le falte el atributo de nombre? - ¿Hay algún POI al que le falte el atributo de tipo? - ¿Hay algún POI al que le falte el atributo de número de teléfono? - ¿Está el valor del campo nombre con las mayúsculas y minúsculas correctas? - ¿El número de teléfono tiene sentido? Generalmente los modelos de datos son más complejos, como por ejemplo en el caso de la cartografía de edificios. Consideremos un modelo de datos que incluya esto: .. image:: img/reviewing_osm_data_image02.png :align: center Se podrían estar cartografiando miles de edificios con los mismos atributos y el análisis se convertiría en más crítico. En el presente tutorial se usarán los edificios como ejemplo, aunque los mismos métodos se pueden aplicar a la comprobación de otros elementos. Comprobaciones diarias ---------------------- La manera más rápida de realizar comprobaciones en los datos es revisarla y validarla con regularidad. La frecuencia puede ser diaria, pero como máximo debiera ser semanal. Representa una tarea importante para el supervisor del equipo de trabajo ya que encontrar de manera temprana errores y malas prácticas a la hora de editar significa que los errores pueden ser corregidos y los editores de cartografía pueden aprender y hacer las cosas de manera apropiada. Revisaremos algunos de los métodos que se pueden emplear para comprobar los datos usando simplemente JOSM. Algunas de las preguntas que hay que formularse al respecto de los datos son: - ¿Hay errores **topológicos** (como edificios que se solapan o relaciones erróneas)? - ¿Hay errores de **etiquetado** (etiquetas mal escritas, pares clave-valor mal empleados)? - ¿Están los datos **completos** de acuerdo al modelo de datos? Examinemos cómo encontrar respuestas a estas preguntas empleando JOSM. Se asume que se está comprobando el trabajo de otras personas, pero los mismos procesos deberían funcionar también (e incluso ser más sencillos) cuando se examina el trabajo propio. Se emplearán una serie de archivos de datos de ejemplo del proyecto de Open Cities de Dhaka. Para poder continuar se deben descargar los siguientes archivos: `dhaka_validation_example.osm `_ .. warning:: NO SE DEBEN salvar los cambios en OpenStreetMap. Estos ejercicios tienen solamente un carácter de demostración. .. image:: img/reviewing_osm_data_image03.png :align: center Validación de datos ~~~~~~~~~~~~~~~~~~~~~~~ El primer paso para comprobar los datos es ejecutar la Herramienta de Validación de JOSM, que comprobará automáticamente los datos cargados en busca de los errores más comunes. Esta herramienta es especialmente útil para encontrar errores **topológicos** pero no será tan útil para encontrar errores de etiquetas. - La herramienta se activa pulsando el botón de Validación que se encuentra en el lado izquierdo de JOSM. (Este paso no será necesario si el panel de Validación ya está desplegado). .. image:: img/reviewing_osm_data_image04.png :align: center - A continuación hay que asegurarse de que no hay nada seleccionado pulsando con el ratón en cualquier lugar en blanco del mapa. Si hay elementos seleccionados cuando se emplea la Herramienta de Validación solamente los elementos seleccionados son validados. (En ocasiones es conveniente comprobar solamente algunos elementos, pero por ahora vamos a comprobar todo el fichero). - Se pulsa en el botón "*Validation*" del panel. .. image:: img/reviewing_osm_data_image05.png :align: center - Aparecerán una lista de avisos: .. image:: img/reviewing_osm_data_image06.png :align: center - También aparece una nueva capa, indicando dónde están los errores. Puede ser conveniente ocultar esta capa de momento. .. image:: img/reviewing_osm_data_image07.png :align: center Pasamos a revisar algunos de los avisos. Puede verse que hay cuatro avisos de "*Crossing buildings*". Estos avisos informan de que hay edificios que se solapan en algún lugar. Se selecciona el primer elemento de la lista, pulsamos con el botón derecho y después elegimos "*Zoom to problem*". .. image:: img/reviewing_osm_data_image08.png :align: center También se puede pulsar en el botón "*Select*" que está en la parte de abajo de la ventana de Validación, lo que seleccionará las vías en cuestión. Así es como se muestra que dos vías tienen un problema: .. image:: img/reviewing_osm_data_image09.png :align: center - En este caso se trata de un error que nunca se habría podido detectar sin la herramienta de validación. Si se hace *zoom* a menor escala se puede apreciar cómo los edificios se solapan ligeramente, lo que es un error topológico, porque los edificios no suelen solaparse unos con otros. Para arreglar el error, es necesario desplazar el nodo central. Si los edificios realmente se tocan, lo que es muy probable, el nodo central puede unirse con la vía. - Una vez se ha corregido, se puede volver a ejecutar la herramienta de Validación y comprobar como ha desaparecido el elemento de la lista. Este método de comprobación automática de los datos en una manera muy eficaz de corregir errores topológicos, particularmente aquellos que son difíciles de apreciar para las personas. En la lista de avisos de validación, se pueden encontrar otros avisos como "*Building inside building*" que es el resultado de una equivocación similar. Sin embargo otros avisos, como "*Crossing waterway/highway*", no son errores necesariamente. En este caso se puede apreciar claramente que la herramienta de validación puede ser muy buena para detectar posibles errores, pero que se requiere de que alguien supervise si el error es importante o no. .. image:: img/reviewing_osm_data_image10.png :align: center Si se comprueba el aviso que hay bajo "*Similarly named ways*" se puede ver que no se trata de un error topológico. Si se pulsa "*Select*" se seleccionarán las dos vías en cuestión. .. image:: img/reviewing_osm_data_image11.png :align: center ¿Se aprecia la naturaleza del error? Aunque hay dos segmentos de vía diferentes, que en realidad son la misma vía pero que han sido nombrados de manera ligeramente diferente - "*road*" está en mayúsculas en una de las vías pero no en la otra. Parece tener sentido que ambas deberían tener el mismo nombre, y en este caso la palabra "*road*" debe estar en mayúsculas. Usando la búsqueda de JOSM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buscar en JOSM es una manera muy potente de revisar datos. Permite la introducción de términos de búsqueda, también llamados consultas, para seleccionar solamente los elementos que se quiera. - Para acceder a la búsqueda, hay que ir al menú *Edit -> Search* o presionar CTRL + F en el teclado. .. image:: img/reviewing_osm_data_image12.png :align: center - Hay muchas consultas que pueden realizarse, pueden verse detalles y ejemplos en la propia caja de búsqueda y pulsando el botón "*Help*". - Se intentará seleccionar todos los edificios. Prácticamente todos los edificios van a tener la etiqueta **building=yes** y solamente algunos tendrán la etiqueta **building=construction**. Se puede construir una consulta como:: *building = yes* OR *building=construction* - Esta consulta seleccionará todos los edificios, pero en previsión de que alguien hubiera empleado una etiqueta equivocada en el edificio, podemos emplear un carácter comodín, que seleccionará todos los elementos que tengan la clave **building**. .. image:: img/reviewing_osm_data_image13.png :align: center - Se seleccionarán todos los edificios. Se trata de una funcionalidad muy útil, ¿pero cómo ayuda a revisar los datos? Ahora que todos los elementos de un solo tipo han sido seleccionados, pueden comprobarse etiquetas erróneas. - En la ventana de Propiedades - podemos ver todas las etiquetas de los elementos seleccionados. Todos tienen las mismas claves, pero como cada elemento tiene valores diferentes aparecen marcados como **. .. image:: img/reviewing_osm_data_image14.png :align: center - Se pulsa en la etiqueta **building:use** y después pulsamos en "Edit". .. image:: img/reviewing_osm_data_image15.png :align: center - **¡PRECAUCIÓN!** no se debe editar el valor y pulsar OK, porque eso cambiaría los valores de todos los elementos edificio. **Y esto sería muy perjudicial**. - En lugar de eso, se pulsa en la caja desplegable junto al Valor. .. image:: img/reviewing_osm_data_image16.png :align: center - Hay que apreciar que todos los elementos en negrita tienen un número entre paréntesis junto a ellos. Se trata del número de elementos seleccionados que tienen el valor de la etiqueta. Se puede comparar ésta con las etiquetas representadas en nuestro modelo de datos y buscar errores. Por ejemplo, la etiqueta que usamos como ejemplo representa un uso como edificio. En los inicios del proyecto Open Cities Dhaka (que es de donde provienen los datos de ejemplo) había una cierta incertidumbre sobre si etiquetar un edificio con diversos usos como **building:use=multipurpose** o **building:use=mixed**. Como la primera etiqueta ya estaba siendo utilizada en otros países, fue la que finalmente se eligió. Sin embargo, tal como se puede apreciar uno de los edificios se ha etiquetado como **mixed**. Es necesario corregir esto. (Otro error obvio son dos términos distintos empleados para **garage**, pero no se corregirá este error en este momento). - No puede cambiarse el elemento etiquetado como **building:use=mixed** desde esta pantalla, ya que hay cientos de elementos seleccionados. De manera que, para corregir el error, se debe encontrar el edificio concreto. ¿Cómo? Empleando la herramienta de búsqueda. - Hay que pulsar "*Cancel*" para abandonar el dialogo. **Hay que recordar que pulsar OK puede ser peligroso**. - Se abre la búsqueda de nuevo y se introduce:: "building:use"=mixed - Nótese que las comillas son necesarias porque el carácter dos puntos (:) tiene su propio significado para el motor de búsqueda. Esta acción seleccionará el único edificio que tiene esa etiqueta. Ahora se puede remplazar su valor por **multipurpose**. .. warning:: Se debe recordar que pese a seguir el tutorial, NO se deben guardar los cambios en OpenStreetMap. Se trata de un ejercicio meramente demostrativo. Repetición del trabajo ---------------------- Cuando se trabaja en un proyecto como el de realizar un cartografía detallada de edificios, deben implementarse métodos adicionales de control de calidad, tanto para obtener un mejor trabajo final como para poder informar sobre la precisión al final de proyecto. Si hay varios equipos colaborando en la recolección de datos en el área, suele ser común que uno o más de los equipos no realice un trabajo satisfactorio. Incluso los equipos que realizan un trabajo eficiente y preciso cometen errores. Si se imagina un equipo que cartografía unos 100 edificios al día - no es descabellado que un pequeño porcentaje de los atributos recolectados sean erróneos. De este modo, un buen proyecto debe incluir los procesos de comprobación de parte del trabajo realizado, para arreglar errores, determinando qué equipos han realizado un trabajo satisfactorio y obteniendo aproximadamente el porcentaje de errores para incluirlo en el informe final. Por supuesto, no tiene sentido repetir el trabajo realizado en cada edificio en el área, pero entre el 5 y el 10 % de los edificios deberían ser revisados. Las áreas sometidas a revisión deben ser escogidas de distintas zonas para poder comparar entre equipos de trabajo. Los equipos pueden volver a realizar el trabajo de otros equipos, o si es posible debería ser el personal más experimentado los que realizaran la revisión. Es práctica común que los jefes de equipo empleen un día a la semana a realizar repetición de trabajo de partes del área objetivo. Corrigiendo errores ~~~~~~~~~~~~~~~~~~~~~~~ ¿Qué debe hacerse cuando se detectan errores? Si la cantidad de errores es pequeña (menos del 5% de los edificios), las incidencias deben llevarse al equipo de campo original de forma que cobren conciencia del error y no lo vuelvan a cometer. Los datos deben ser corregidos en OpenStreetMap y el resultado de la repetición del trabajo registrada. Si hay errores más importantes, deberán tomarse acciones más drásticas. El equipo de campo deberá ser informado convenientemente y las áreas en las que trabajaron podrían tener que volver a trabajarse por completo, dependiendo de lo erróneos que resulten ser los datos. Un número de errores superior al 10% será seguramente inapropiado. Informando sobre la precisión ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ El segundo objetivo de la repetición de trabajos es el poder hacer un informe sobre la precisión de los datos cuando acaba el proyecto. Los usuarios de los datos querrán saber qué métricas y metodologías se han empleado para asegurar la calidad. Incluir este proceso como parte de la metodología de revisión, permite explicar claramente de qué manera se ha asegurado la calidad y se podrán aportar pruebas sólidas sobre los porcentajes de error de los datos obtenidos. Por ejemplo, Se podría imaginar que se gestiona un proyecto en el que hay que cartografiar 1000 edificios. Así que se decide cartografiar el 10%, o sea 100 edificios, seleccionándolos aleatoriamente en el área. Después de realizar la repetición del trabajo de campo se aprecia que seis de ellos tienen un alto nivel de errores. En este caso se supone que se ha establecido que un error es tener al menos una etiqueta errónea. Un seis por ciento de los edificios que se han repetido tienen errores - que pueden subsanarse, pero se debe extrapolar que el seis por ciento de los 1000 edificios tienen alguna incorrección. Al cierre del proyecto debería informarse de que este es el error probable. La repetición del trabajo debe realizarse a lo largo del proyecto. Imaginando que se espera hasta el final del proyecto para encontrar que ¡40 de cada 100 edificios tienen errores! Podría llegar a arruinar todo el proyecto. Es mejor encontrar tempranamente errores a gran escala de forma que estos puedan ser corregidos. Consultas SQL ------------- Probablemente la mejor herramienta de análisis a emplear son las consultas SQL en un sistema GIS, como QuantumGIS (QGIS). Es similar a buscar información en JOSM, pero ofrece una capacidad de análisis más potente, aunque puede costar un poco más de tiempo preparar el entorno. Usar JOSM es una forma rápida de comprobar los errores más básicos, mientras que QGIS está diseñado para encontrar datos que faltan o atributos incorrectos. Se asume que el lector está familiarizado con los GIS, por lo que el presente manual se centra en la creación de consultas que permitan revisar datos de OpenStreetMap. Para realizar los ejercicios que vienen a continuación se empleará de nuevo los datos del proyecto de Dhaka de Open Cities, que puede descargarse de `dhaka_sql.zip `_ . Los datos de OpenStreetMap se exportaron empleando la herramienta (`export.hotosm.org `_ y el área de trabajo se determinó al principio del proyecto. Preparar los datos ~~~~~~~~~~~~~~~~~~~~~~ Se descomprimirá el archivo Zip y se cargará su contenido en QGIS. Se procederá a recortar solo los edificios que se encuentren en el área de proyecto, de forma que se simplificará el trabajo a realizar a posteriori. - En primer lugar se seleccionan los polígonos que estén en el área del proyecto. Para ello se empleará el plugin *Spatial Query*. Si no se encuentra instalado, ir a *Plugins -> Manage and Install Plugins* para encontrarlo e instalarlo. - Ir a *Vector -> Spatial Query -> Spatial Query*. - Se deben rellenar los ajustes para seleccionar elementos **planet_osm_polygon** que estén **within target_area**. .. image:: img/reviewing_osm_data_image17.png :align: center - Se pulsa *Apply*. Solamente se seleccionarán los polígonos que estén en el área. .. image:: img/reviewing_osm_data_image18.png :align: center - Se pulsa con el botón derecho del ratón en la capa y se guarda la selección como un nuevo *shapefile*. Se añade este último al proyecto. .. image:: img/reviewing_osm_data_image19.png :align: center - A continuación se filtran tan solo los polígonos que sean edificios y que fueron recogidos como parte del proyecto. - Se pulsa con el botón derecho sobre **planet_osm_polygon** y se pulsa en "Filter..." - Se introduce la siguiente consulta:: *"building" != NULL AND "source" = 'Open Cities Dhaka Survey'* - Se pulsa OK. El filtrado de los datos con la consulta mostrará solamente los polígonos que tengan algún contenido en la columna edificio. También eliminará los edificios que no tengan la etiqueta *source* asociada al proyecto. - Se guardan los datos como un nuevo *shapefile*. Se usará el archivo para las consultas SQL. .. image:: img/reviewing_osm_data_image20.png :align: center Consultas SQL ~~~~~~~~~~~~~~~~~ Ahora pueden ejecutarse consultas en la capa de edificios para detectar posibles errores. Se plantearán algunas cuestiones sobre las que se podrían realizar consultas. El modelo de datos del proyecto indica los atributos que deberían recogerse en cada edificio - estos atributos son: - name - building - building:levels - building:use - building:vertical_irregularity - building:soft_storey - building:material - building:structure - start_date - building:condition Nótese que en los *shapefiles* los nombres de columna están truncados, ya que estos están limitados a 10 caracteres. ¿Qué tipo de preguntas se pretende preguntar? ¿Qué es posible que sean errores? Un error común es que se ha cartografiado el edificio, pero no se han recolectado todos los atributos. De forma que se ejecutará una consulta que muestre todos los edificios que no tienen el juego completo de atributos. Algunos atributos, como el nombre o el año de inicio (año de construcción), pueden estar vacíos sin que sea un error, porque muchos edificios no tienen nombre y se desconoce el año de construcción. Pero el resto de atributos deben ser recogidos. Se desarrolla una consulta con este fin: - Hacer pulsar con el botón derecho en la capa de edificios (la capa creada en la sección anterior) y pulsar "Filter..." se abrirá el constructor de consultas. En este constructor se prepararán las consultas complejas que devolverán los datos solicitados. - Se puede construir la consulta haciendo doble pulsación en los campos, operadores y valores, o puede copiarse la siguiente consulta:: "building_c" = NULL OR "building_s" = NULL OR "building_l" = NULL OR "building_m" = NULL OR "vertical_i" = NULL OR "soft_store" = NULL OR "building_u" = NULL - Se pulsa en "Test" y se comprueba que la consulta devuelve 125 elementos. Esto quiere decir que de los 3500 edificios cartografiados, a 125 les falta un atributo o varios. .. image:: img/reviewing_osm_data_image21.png :align: center - Se pulsa OK para mostrar solo los edificios que cumplan las condiciones de la consulta. .. image:: img/reviewing_osm_data_image22.png :align: center - Estos edificios pueden ser examinados para identificar qué atributos faltan y si es necesario realizar de nuevo el trabajo. Es posible hacer un mapa con QGIS que muestre a qué edificios les faltan atributos para entregar al equipo que vaya a volver a campo. ¿Qué otras consultas pueden ser de utilidad? También se pueden comprobar atributos que no están en el esquema de datos. Como ya se vio en la sección de JOSM. Se pueden emplear las consultas para encontrar los edificios cuyos atributos no se correspondan con el modelo. También pueden emplearse para buscar anomalías, que probablemente aunque no necesariamente son errores. Por ejemplo, si se abre el constructor de consultas, se selecciona **building_l** y se pulsa "All" para cargar los posibles valores de atributos, se aprecia que la mayoría de edificios tienen un número entre uno y 20 (este atributo es building:levels, el número de plantas del edificio). Pero también hay un 51. Parece poco probable que haya un edificio de 51 alturas en el área, de forma que se puede localizar y ser comentado con los cartógrafos. Las consultas pueden ser una forma muy efectiva de encontrar errores en el juego de datos. Combinadas con otras características de QGIS, pueden emplearse para producir mapas que pueden ser usados para revisar datos en el área. Resumen ------- En el presente tutorial se han revisado diversos modos efectivos de mantener la calidad de los datos durante un proyecto y se han realizado algunos ejercicios para practicar la revisión de datos OSM. Cuando se organiza un proyecto de cartografiado, o incluso cuando se están empleando los datos de un área para uso personal, estos métodos pueden resultar ventajosos.