La experiencia del USGS con I.G. voluntaria y su prototipo colaborativo de OpenStreetMap

El presente artículo es una traducción íntegra de: Wolf, E.B., Matthews, G.D., McNinch, K., and Poore, B.S., 2011, OpenStreetMap Collaborative Prototype, Phase 1: U.S. Geological Survey Open-File Report 2011-1136, 23 p.

Salvo mención en contrario, las organizaciones citadas en este artículo pertenecen al ámbito de los Estados Unidos, y su mera mención no implica ningún apoyo o patrocinio.

El artículo completo puede ser consultado visitando la siguiente página web: http://pubs.usgs.gov/of/2011/1136/

2. Introducción

The National Map (www.nationalmap.org) es un esfuerzo colaborativo entre el USGS y colaboradores a nivel Federal, Estatal y local, para suministrar información topográfica para los Estados Unidos. La información geográfica inclute ortofotografías (fotografías aéreas), elevación, toponimia, hidrografía, líneas límite, transporte (incluyendo carreteras), estructuras, y uso del suelo. The National Map es una contribución significante a la Infraestructura de Datos Espaciales Nacional (NSDI) y actualmente está siendo transformado para servir mejor a la comunidad geoespacial, al ofrecer datos y servicios geoespaciales integrados y de alta calidad a través de Internet, incluyendo mapas topográficos digitales de nueva generación.

El USGS está respondiendo a los cambios en la producción y compartición de los datos a través de Internet, explorando colaboraciones con clientes y productores de datos no tradicionales (Sugarbaker et al, 2009)[11]. La Web Geoespacial (Scharl y Tochterman, 2007)[10], o la unión de localización con información y contenidos de Internet, ha democratizado la producción cartográfica en línea. El acceso civil a la señal del Sistema de Posicionamiento Global (GPS), la disponibilidad de interfaces de programación de aplicaciones (APIs) que permiten mezclar datos geoespaciales de diferentes fuentes dentro de una plataforma basada en mapas, la creciente madurez del software libre geoespacial, y la rápida proliferación de dispositivos móviles con capacidades geográficas han hecho más fácil para el público general acceder y utilizar datos espaciales en línea. Estos cambios técnicos han promovido una cultura de mapeamiento colaborativo en línea por usuarios que no son profesionales de las ciencias y Sistemas de Información Geográfica (SIG). Esta tendencia a recolectar y usar datos cartográficos por parte de usuarios no profesionales ha sido denominada Información Geográfica Voluntaria (VGI) (Goodchild, 2007)[4]. En lugar de ser meros usuarios pasivos de los mapas y datos de fuentes oficiales, estos usuarios son capaces de producir sus propios datos e innovadoras tecnologías geográficas.

Históricamente, el USGS ha llevado a cabo programas para que los voluntarios pudiesen contribuir datos a los mapas topográficos del USGS. En la década de los 90, el Cuerpo voluntario de Ciencias de la Tierra llevó a cabo el programa “adopta un quad¹“, anotando revisiones en potencia sobre mapas en papel y enviándolos por correo al USGS. En la era de Internet, cambió de nombre para pasar a ser el Cuerpo del National Map. El énfasis se ponía en la recolección y edición de información sobre estructiras; incluyendo el proporcionar información sobre la localización de edificios como parques de bomberos, colegios y oficinas de correos. Poco después de empezar el programa, los ciudadanos enviaron los nombres y coordenadas GPS de las estructuras a través de un portal web. Un sistema posterior basado en ArcIMS de ESRI permitió una metodología de digitalización para la captura de datos. Este programa fue interrumpido debido a motivos presupuestarios.

Queriendo volver a evaluar la posibilidad de un programa de cartografía voluntaria, el USGS organizó un taller sobre I.G. Voluntaria en enero del 2010 (USGS VGI Workshop) (http://cegis.usgs.gov/vgi/index.html). El taller reunió a representantes de diferentes organizaciones con experiencia en información geográfica voluntaria, desde esfuerzos de ciencia ciudadana (por ejemplo, el Programa de Observación Cooperativa del NOAA²) pasando por identificación masiva en línea de fotografías históricas (por ejemplo, la Biblioteca del Congreso) y empresas que usan voluntarios y sensores en sus coches para actualizar redes viarias (por ejemplo, TeleAtlas), hasta una organización sin ánimo de lucro que construye un mapa del mundo creado únicamente por voluntarios (OpenStreetMap, www.openstreetmap.org).

3. Descripción del problema

Incluso después de que el taller de VGI del USGS demostrara que hay un número creciente de programas que usan información suministrada por voluntarios, en los sectores público, privado y sin ánimo de lucro, hay numerosas cuestiones que necesitan ser exploradas para poder evaluar la utilidad y efectividad de la VGI por parte del USGS en la creación del National Map. Estas cuestiones son:

¿Cómo de precisos son los datos?
De entre las conclusiones del taller, una de las cuestiones más urgentes está relacionada con la precisión de los datos: ¿Cómo de precisos son los datos voluntarios? Algunos programas de ciencia ciudadana como el Conteo Navideño de Pájaros de Audubon llevan en marcha varias décadas y su precisión está estudiada y contabilizada (Cohn, 2008)[2]; sin embargo, estos programas cuentan con protocolos altamente estructurados diseñados por científicos profesionales, y proporcionan entrenamiento intensivo a los voluntarios. El caso de la información geográfica voluntaria es más problemático, puesto que es un fenómeno relativamente reciente y tiene muchas variaciones (Goodchild, 2007)[4].

¿Qué tipo de tareas se adaptan bien a la recolección voluntaria de datos?
No todas las clases de datos espaciales se adaptan bien a la recolección voluntaria, debido a distintas necesidades de precisión, compleción y frecuencia de actualización. También hay consideraciones sobre la complejidad y seguridad, así como relaciones entre los diferentes conjuntos de datos. Las entidades con una geometría que pueda ser identificable visualmente mediante imágenes aéreas, o mediante trabajo de campo con GPS, como los edificios y carreteras, son más susceptibles de ser recolectadas por voluntarios, al contrario que entidades más abstractas como fronteras políticas. Los atributos de una entidad también tiene un impacto en cómo de bien un tipo de entidades se recolecta con voluntarios. Las entidades con atributos muy complejos que necesitan de un control de calidad significativamente superior no se prestan tan bien a esfuerzos voluntarios como lo hacen las entidades con atributos simples.

Los métodos de Información Geográfica Voluntaria permanecen sin ser probados en los sistemas de producción de los institutos geográficos nacionales, que tienen requisitos muy particulares sobre controles y revisiones de calidad de los datos. Los proyectos de edición colaborativa no espacial, como Wikipedia, cuentan con voluntarios específicamente asignados a la tarea de moderar y revisar contribuciones de otros voluntarios. Los esfuerzos actuales de mapas colaborativos, como OSM, no cuentan específicamente con una estructura de moderación y revisión de los datos; en cambio, dependen de la comunidad de voluntarios en pleno para identificar y corregir datos erróneos o vandalismo. El Prototipo Colaborativo del USGS servirá como un ensayo para comprobar si los voluntarios son capaces no sólo de recolectar datos, sino también de revisarlos, probarlos, y certificarlos a los institutos geográficos.

¿Qué motiva a los voluntarios?
En el taller de VGI del USGS se discutió sobre cómo motivar y mantener el interés de los voluntarios, siendo un asunto a considerar a la hora de crear un programa voluntario de recolección de datos. Se observó que los voluntarios necesitan tener una razón tangible para compartir su tiempo, conocimiento y esfuerzo. La motivación voluntaria puede incluir el estar involucrado en una comunidad que simboliza algo más grande que ellos mismos, y el devolver algo a esa cominidad; un hobby; un interés en una geografía particular y el deseo de mejorar su apariencia en un mapa libre; el poder disfrutar de datos de calidad para sus propios proyectos; recompensas y reconocimiento; o simplemente curiosidad.

¿Cuál es la mejor manera de estructurar estos programas y proporcionar incentivos?
Se puede establecer un buen programa voluntario a través de diferentes estructuras y organizaciones del proyecto. En el taller de VGI del USGS se discutieron muchos esfuerzos de recolección de datos voluntarios ya existentes, con diversas estructuras: Wikipedia, el Conteo Navideño de Pájaros de Audubon, OSM, etcétera. El USGS está en el proceso de evaluar cuál de estos modelos de proyecto es el que mejor funciona a la hora de establecer un programa para contribuir al National Map.

¿Cómo pueden los datos voluntarios ser integrados con datos producidos por organizaciones profesionales?
The National Map tiene necesidades particulares para datos autoritativos, no como proyectos como OpenStreetMap que proclaman no ser fuentes autoritativas de datos. El cómo certificar e integrar los datos voluntarios en el National Map son problemas significativos que no han sido investigados con anterioridad por la comunidad geoespacial.

¿Cuál es la relación coste-beneficio de usar datos voluntarios?
La utilidad, precisión, y compleción de los datos recolectados por voluntarios son investigados, junto a los costes asociados. Los resultados de este análisis costebeneficio serán un factor determinante en el futuro del programa.

¿Cómo de sostenibles son estos programas voluntarios?
Mantener a los contribuidores voluntarios involucrados a largo plazo es una cuestión discutida en detalle durante el taller VGI del USGS. El consenso fue que es para los voluntarios es más fácil crear nuevos datos, y más difícil actualizarlos, mantenerlos y validarlos. El cómo proyectos exitosos como Wikipedia y OSM han logrado mantener estables las contribuciones voluntarias todavía no ha sido estudiado.

¿Cómo de bien se podrían integrar los sistemas web de recogida de datos ya existentes en los esfuerzos VGI del USGS?
Una evaluación de los sistemas existentes para datos contribuidos por los usuarios reveló que la pila de software de OSM ha conseguidoun éxito real y parece prometedor.

4. Enfoque del proyecto OSMCP

El USGS ha puesto en marcha un proyecto de investigación, el OSMCP, para intentar resolver algunas de las cuestiones que el taller de VGI del USGS planteó. La Fase Uno se inició en el año fiscal 2010 (FY2010) y estuvo limitada a evaluar la idoneidad de sistemas de recolección de datos via web existentes para uso de VGI por parte del USGS. La Fase Uno estuvo enfocada a crear un sistema para la edición colaborativa por parte de colaboradores del USGS sin incorporar contribuciones voluntarias. Las fases posteriores se añadirán a esta primera fase y expandirán el ámbito para incluir contribuciones voluntarias no profesionales.

Se construyó un protitipo usando el mismo software libre que utiliza OSM. Este software fue replicado, desplegado, y personalizado en un sistema del USGS. Se insertaron datos desarrollados por una organización colaboradora del USGS, que fueron editados tanto por el USGS como por esta organización colaboradora en un entorno web. La Fase Uno incluye los siguientes componentes:

• Seleccionar y desplegar hardware y software
• Desarrollar documentación, incluyendo especificaciones para la edición colaborativa de datos de carreteras para el National Map.
• Elegir un colaborador (y datos proporcionados por él) para su edición colaborativa.
• Cargar y editar datos en el entorno de OSM.
• Evaluar los datos resultantes tras la edición colaborativa.

El OSMCP empezaría con un prototipo que pueda ser utilizado para adquirir experiencia en edición colaborativa y poner en marcha una infraestructura para las siguientes fases del proyecto. Las subsiguientes fases del OSMCP se construirán sobre la Fase Uno y continuarán explorando el uso de VGI en el USGS. Hay planes para que las fases futuras involucren a grupos de usuarios más grandes, incluyendo contribuciones de grupos de voluntarios. Se intenta que la Fase Uno sea un primer hito en el proceso de incrementar la capacidad del sistema para dar respuesta a las cuestiones del taller VGI del USGS con respecto a precisión, motivación de los voluntarios, y coste-beneficio.

5. Materiales y métodos

La Fase Uno del proyecto incluye el explorar la capacidad de una herramienta de edición colaborativa en web para facilitar la co-edición inter-agencias y la integración de los datos en el National Map.

5.1 Selección y despliegue del software y hardware
En el taller VGI del USGS se discutieron varios sistemas software para recolectar información geográfica contribuída. Los factores tenidos en cuenta para elegir el software para el proyecto incluyeron:

• Interfaz amigable al usuario que pueda ser utilizada con efectividad con sólo un mínimo de formación o documentación;
• Bajo coste y compatibilidad con el hardware del USGS ya existente;
• Sin necesidad de licencias de usuario para los contribuidores de datos;
• Que el soporte técnico del USGS pueda aprender a resolver problemas y dudas sobre el sistema;
• Que la funcionalidad básica aguante de manera simultánea un alto número de usuarios:
  ◦ Editando via web con un navegador, incluyendo Internet Explorer, Mozilla Firefox y Apple Safari,
  ◦ Creando y editando entidades espaciales incluyendo su posición y atributos a través de digitalización en puestos de trabajo,
  ◦ Mostrando una imagen ortorrectificada como fondo de digitalización,
  ◦ Personalizando los tipos de entidad y sus atributos sin programar,
  ◦ Almacenando o transfiriendo los datos a una base de datos fácilmente exportable a ArcGIS de ESRI.

Se consideraron las siguientes opciones para la arquitectura software:

• Contribuciones directas de la USGS a OSM (www.openstreetmap.org)
• Descarga y uso de OSM como parte del National Map.
• Modificación de las herramientas de edición administrativa de los Datos Nacionales de Hidrografía (NHD) del USGS (http://webhosts.cr.usgs.gov/steward/scripts/st2_software.pl).
• Modificación de la Herramienta de Edición Web del NHD de Alabama (http://nhdwet.alabama.gov/)
• Desarrollar una nueva aplicación personalizada basada en ArcGIS Server de ESRI or el software de servidor de mapas GeoServer (www.geoserver.org)
• Usar la arquitectura software de OSM con una base de datos de dominio público.

Una de las opciones consideradas en el taller VGI del USGS fue incentivar que el personal del USGS seleccione y recopile información útil de OSM para incluirla en el National Map. Esta opción no se persiguió dado a la licencia de los datos. Los datos en OSM se encuentran bajo una licencia Creative Commons Compartir Igual (www.openstreetmap.org/copyright), que obliga a cualquier persona utilizando los datos el ofrecer las modificaciones de vuelta a la comunidad bajo la misma licencia. No hay restricciones sobre el uso o redistribución de los datos. Esta diferencia hace que el USGS no pueda recopilar datos de OSM y ponerlos después en el National Map, puesto que debe ser una fuente de datos en el dominio público.

Otra alternativa considerada para una plataforma VGI del USGS fue el modificar el software de administración del NHD. El NHD es la capa de hidrografía del National Map y se mantiene a través de una red de administradores-contribuidores. Estos administradores reciben formación y soporte, y se les anima a firmar acuerdos de colaboración con el USGS. El software desarrollado para procesar los cambios del NHD necesita una licencia software de ArcGIS de ESRI. El software de actualización de NHD está diseñado específicamente para gestionar los tipos de datos del NHD. El NHD utiliza una representación topológica; el software está diseñado específicamente para ese tipo de representación de los datos. No se persiguió esta opción debido a la necesidad de una licencia de usuario de ArcGIS por usuario, y por la complejidad de ArcGIS en comparación a otras herramientas comparables de edición web.

Además de las herramientas creadas por el USGS para contribuciones de usuarios al NHD, la Herramienta de Edición Web (WET) de Alabama depende de un ArcGIS Server y todavía estaba en fase de desarrollo durante el taller de VGI. La WET necesita un login de software, y las ediciones no son incorporadas directamente al conjunto de datos hasta que son revisadas por un administrador del NHD. Esta opción no se persiguió debido a la limitación en el flujo de trabajo y a que la herramienta todavía estaba en desarrollo durante el inicio de la investigación.

Una cuarta opción era construir una aplicación web personalizada para apoyar los esfuerzos de VGI del USGS usando alguna de las muchas herramientas de geoprocesamiento y de servidor de mapas existentes, o bien comerciales o bien libres, como por ejemplo ArcGIS Server de ESRI, o GeoServer. El coste de desarrollo de tal aplicación personalizada sería prohibitivo.

La última opción tenida en consideración (y la que fue adoptada en última instancia) requería que el software de OSM fuera replicado en los sistemas del USGS. OSM es uno de los esfuerzos más ambiciosos para producir un mapa base del mundo a través de contribuciones voluntarias. La comunidad OSM, que tuvo una buena representación en el taller de VGI del USGS, propuso que el USGS utilizase la arquitectura de software libre que hay detrás de OSM. Esta arquitectura de software está bien documentada, es fácil de configurar, no necesita de ninguna licencia de software adicional para los usuarios del sistema, y tiene una gran comunidad de contribuidores, desarrolladores de software libre, y contribuidores en foros y en el wiki que pueden solventar dudas y cuestiones técnicas. La interfaz de edición de OSM es fácil de utilizar, y fue evaluada por el personal del USGS para verificar que abarca todas las funciones todas las funciones de edición necesarias para permitir que los datos sean integrados en el National Map. El software de OSM es fácil de modificar, configurar y personalizar para adecuarse al proyecto. La decisión de utilizar el software de OSM en la Fase Uno de este proyecto se hizo debido a su facilidad de uso, licenciamiento libre, potencial soporte y ayuda, y el liderazdo que la comunidad de OSM ha mostrado al utilizar cartógrafos voluntarios en la web.

5.2 El sistema software del OSMCP
La comunidad de OSM ha desarrollado una arquitectura de software sustancial (OpenStreetMap, 2010) para recolectar la información espacial generada por los usuarios. El software es gratis y está bajo licencias libres; utiliza el sistema operativo Linux, servidor web Apache, arquitectura web Ruby on Rails, y una base de datos relacional PostgreSQL (véase Figura 1). Una variedad de diferentes aplicaciones han sido desarrolladas para facilitar las contribuciones de usuarios, incluyendo el editor Potlach y Potlach 2, empotrados en páginas web, los clientes de escritorio JOSM y Merkaator, así como varias aplicaciones para iPhone. El software de OSM no impone ninguna estructura de datos más allá de nodos (puntos), vías (líneas, polígonos), y relaciones. Además, los atributos de las entidades en OSM se manejan a través de etiquetas ad hoc. No se impone ninguna ontología en los datos recolectados usando OSM.

Figura 1. Componentes de la arquitectura de sistemas de OSM (OpenStreetMap, 2010).

La arquitectura de sistemas de OSM se basa en un modelo distribuído, que consiste en una base de datos PostgreSQL con una capa intermedia, denominada API 0.6, desarrollada en Ruby on Rails (Figura 1). Algunas grandes importaciones y cargas de datos pueden hacerse de manera directa usando una herramienta demoninada Osmosis. La edición e importaciones de menor índole se realizan a través de la interfaz de la API 0.6 con herramientas como JOSM, Merkaator, y dentro de un navegador web, con Potlatch.

En la Fase Uno se ha usado un servidor físico sito en las instalaciones de NGTOC del USGS en Rolla, Missouri, conectado a Internet con una dirección públicamente accesible: www.navigator.er.usgs.gov. Este servidor se situó en una zona desmilitarizada (DMZ) detrás del Servicio de Aplicaciones Seguras Empresarial (eSAS) del USGS. Los servidores de la DMZ son accesibles desde la Internet pública. El eSAS protege a los servidores de la DMZ al filtrar peticiones web. El servidor tiene cuatro núcleos Intel Xeon 3.6GHz con 6 GB de RAM y 650GB de espacio en disco. El sistema operativo utilizado es Ubuntu Server 9.10 “Karmic Koala” 64-bit, con Apache 2.2 proporcionando el servicio de HTTP.

La interfaz web de OSM fue reconfigurada para el esquema de datos deseado para el National Map (Tabla 1) (http://nationalmap.gov/transport.html). El software de OSM no impone ninguna ontología o esquema de datos en particular. En el caso de la comunidad de OSM, el esquema de datos evoluciona a través de un proceso colaborativo. Uno de los principales desafíos en el OSMCP fue demostrar que el software de OSM puede ajustarse a un esquema predeterminado. La interfaz de Potlatch se reconfiguró para este esquema, editando varios ficheros de texto de configuración (véase apéndice B).

Tabla 1. Diferencias entre los esquemas de OSM y mejores prácticas del USGS.

El esquema de OSM resultó ser menos complejo que el esquema de Mejores Prácticas (BP). Por ejemplo, el editor Potlatch reconoce la clave de la etiqueta “highway” como un tipo de vía particular, que representa parte de una red viaria automobilística, pero no significa específicamente que sea una carretera de acceso limitado y de alta velocidad³.

En el esquema de OSM, algunos usos comunes de la etiqueta highway incluyen highway=”calle residencial” y highway=”vía de servicio”.

Algunas modificaciones técnicas centradas alrededor del editor Potlatch se detallan en la Figura 2. Potlatch es un editor basado en Adobe Flash, escrito en ActionScript 1, diseñado para ser ejecutado dentro de un navegador web. La simbología vectorial en Potlatch se controla a través de una serie de ficheros de texto (listados en la Tabla 2) almacenados en el servidor. Los ficheros de Potlatch se modificaron para proporcionar una simbología más adecuada al esquema BP. La figura 3 muestra la interfaz de Potlatch con la simbología vectorial codificada para el esquema.

Figura 2. Componentes de la arquitectura de sistemas del OSMCP (subconjunto de Figura 1).

Tabla 2. Ficheros que definen la simbología vectorial de Potlatch (nótese la forma británica de “colour”).

Figura 3. La interfaz de Potlatch con datos vectoriales sobreimpuestos a la capa de ortofotos del National Map. La simbología está ligada al esquema de datos.

Editar en Potlatch es básicamente una experiencia de digitalización en pantalla. Aunque a los usuarios se les permite subir trazas de GPS en un fichero GPX, la práctica más común entre los contribuidores de OSM en áreas con buena cobertura de imágenes aéreas es dibujar encima de la ortofoto. En el sitio web de OSM (http://www.openstreetmap.org), Potlatch muestradatos vectoriales sobreimpuestos a ortofotos donadas por Microsoft Bing Maps, que proporcionan cobertura mundial a color a 0.3m (Meyer, 2010)[7].

En la Fase Uno del proyecto, se configuró una caché de teselas local para proporcionar el fondo de ortofotografía proveniente de la capa del National Map en vez de utilizar las imágenes aéreas de Microsoft. Esto sigue las directrices de calidad internas del NGTOC, puesto que al usar una capa de ortofotografías que mayoritariamente proviene del Plan Nacional de Imagen Aérea (NAIP) se puede determinar la calidad de los datos. Potlatch necesita que las imágenes sean servidas desde una caché de teselas “estilo Google”, en la que las teselas se encuentran accesibles a través de HTTP como ficheros de imagen con direcciones adecuadas. Las teselas se extrajeron de un Servicio de Mapas Web (WMS) proporcionado por el National Map: Combined/TNM_Large_Scale_Imagery (MapServer) (véanse sus metadatos en http://raster.nationalmap.gov/ArcGIS/rest/services/Combined/ TNM_Large_Scale_Imagery/Map Server). Aunque el National Map ofrece ortofotos como un servicio teselado, las imágenes de tal servicio sólo abarcan los niveles de zoom del 1 al 11 (menos que aproximadamente una escala 1:220000) lo cual no ofrece el detalle suficiente como para dibujar entidades en Potlatch. Para poder identificar visualmente entidades en Potlatch, la edición tiene lugar en los niveles de zoom entre 16 y 20 (escalas mayores a aproximadamente 1:20000). El script de Python Tilecache 2.11 proporcionó los medios tanto para generar teselas dinámicamente como para hacer la “siembra”[sic] inicial de la caché. La mayoría del área de estudio para la Fase Uno fue sembrada de antemano, pero el proceso fue demadiado lento como para completarse antes de que los colaboradores recolectadan datos durante la Fase Uno del OSMCP.

5.3 Desarrollando especificaciones de edición de datos colaborativa
El USGS mantiene directrices para los datos de carreteras contribuídos al National Map. Estas directrices incluyen información sobre precisión espacial, representación de las geometrías, compleción, topología, y reglas de sus atributos (J. Walters y G. Matthews, USGS, sin publicar, 2010). Para que el USGS incorpore datos de terceros, incluyendo otros organismos y/o voluntarios, es necesario que los terceros cumplan con unas especificaciones mínimas para asegurarse de que los datos son de una calidad suficiente para el National Map. Para el proyecto de la Fase Uno, al colaborador se le pidió cumplir los requisitos mínimos del estándar del USGS para carreteras. Llegar a un acuerdo en las especificaciones crea métodos de trabajo similares a través de varios niveles gubernamentales y públicos, lo cual es la situación ideal. Este tipo de convenciones no siempre es posible con todos los potenciales colaboradores y voluntarios.

5.4 Eligiendo una entidad colaboradora (y sus datos) para la edición colaborativa
Se eligió al Centro de Soporte y Acceso de Datos de Kansas (DASC) como entidad colaboradora para este proyecto. El DASC se eligió por dos razones principales: primero, el DASC estaba dispuesto a proporcionar tiempo y personal al proyecto; segundo, los datos de carreteras en posesión del DASC, a nivel de estado, estaban parcialmente completos. La calidad de estos datos en relación a los datos de carreteras del Censo fue evaluada en un informe interno del NGTOC (G. Matthews, USGS, sin publicar, 2009). El informe concluyó con que los datos del DASC tienen una precisión posicional similar a los datos del Censo y sus atributos encajan bien con el Modelo de Datos de Mejores Prácticas. Sin embargo, los datos del DASC carecían de la representación estándar de dobles calzadas y nudos de enlace. Esta deficiencia específica en la representación geométrica proporcionó un punto donde centrarse en el proceso de co-edición del OSMCP.

Se seleccionaron los condados de Douglas y Johnson en Kansas como áreas de interés para su edición. El DASC está en el condado de Douglas. El condado de Johnson es adyacente a Douglas y abarca las áreas metropolitanas de Lawrence, así como gran parte de Kansas City. Se eligió este área debido a la variedad de tipos de entidades de carretera y porque el personal del DASC tiene un conocimiento del terreno razonable en ese entorno (Figura 4).

Figura 4. Área de interés para la Fase Uno del OSMCP.

5.5 Preprocesamiento y carga de datos en entorno OSM
Los pasos de preprocesamiento para la Fase Uno del proyecto se llevaron a cabo en dos etapas. Primero, el DASC asimiló los datos de carreteras hasta nivel de estado para crear un conjunto de datos de carreteras consistente. Después, el USGS procesó las carreteras del DASC usando el Motor de Manipulación de Entidades (FME) de Safe Software, para cruzar los atributos con el esquema de Mejores Prácticas para Transporte del USGS, y convertirlo desde una Geodatabase Personal a formato XML de OSM (Figura 5). Esto proporcionó un conjunto base de carreteras con atributos consistentes.

Figura 5. Conversión de atributos de carreteras del DASC a esquema de mejores prácticas usando FME 2011 beta.

Los pasos de geoprocesamiento incluyeron: evaluar auto-intersecciones en líneas, ejecutar un filtro de geometría para comprobar el tipo de entidad, ejecutar un proceso de encajado para resolver problemas de geometría (p. ej. líneas duplicadas), detectar y quitar astillas (slivers), ejecutar un proceso de ajuste para asegurar conectividad en la nueva red y, por último, convertir las geometrías de carreteras de Kansas al esquema del USGS.

Despúes de que se completara el procxeso inicial, el fichero resultante fue convertido a formato OSM para poder ser cargado en la base de datos PostgreSQL de OSM. Esto fue un proceso sencillo que involucró copiar atributos, detectar ciertas cadenas de texto para ayudar a identificar tipos de vía, y luego escribir el fichero OSM final (Figura 6).

Figura 6. Conversión de datos preprocesados a formato nativo de OSM.

5.6 Edición colaborativa de los datos de carreteras de Kansas en entorno OSM
Un miembro del NGTOC supervisó la edición de carreteras con el DASC, y verificó que los datos editados cumplían con todos los estándares del USGS. En el área de interés del proyecto, el USGS se responsabilizó de la edición de autovías interestatales, rutas, y los enlaces y vías de servicio correspondientes. Esta edición cubrió un total de 435 kilómetros con un coste aproximado de 88 horas. Esta edición preliminar del USGS se completó antes de que el colaborador se involucrara.

Para poder ayudar al DASC en familiarizarse con la interfaz web del OSMCP, un miembro del USGS se desplazó hasta las dependencias del DASC y pasó tiempo con su personal; ayudándoles a entender el software y los procedimientos a ser usados en la edición de datos. El DASC fue responsable de las rutas estatales, unos 115 kilómetros de carretera con un coste de unas 40 horas. Accedieron a la interfaz web de Potlatch a través de un navegador normal, como Mozilla Firefox o Microsoft Internet Explorer. Aunque los editores tanto del USGS como del DASC informaron de que la interfaz web es eficiente y fácil de usar, hubo un problema de edición por parte del DASC. Una sección de las carreteras importadas inicialmente estaba colgando el navegador, debido a un número de puntos inusualmente alto. Este problema pudo ser ocasionado inicialmente por “streaming” de puntos, un caso donde un editor puede haber no cerrado una sesión a tiempo. Este tipo de problema puede incluso causar que un equipo de escritorio se ralentice mientras intenta cargar miles de puntos de una única sección de línea. En el futuro, errores de datos como este pueden ser prevenidos por el USGS si se simplifican los datos con FME antes de cargarlos en la base de datos de OSM.

6. Resultados de datos de la Fase Uno del OSMCP

El proceso de edición se centró en deficiencias específicas en los datos del DASC identificados en un informe interno (G. Matthews, USGS, sin publicar, 2009). Se quería de antemano que los datos de carreteras cumplieran con los requisitos del NGP para precisión posicoinal, y que los atributos estaban preparados para ser compatibles con el esquema de Mejores Prácticas. La tabla 3 muestra un sumario de cambios de los datos resultantes tras finalizar la Fase Uno. El incremento en el número de entidades y longitud de carreteras interestatales se debe mayormente a la mala o inexistente representación de vías de doble calzada en los datos iniciales de Kansas. Los cambios a las vías de incorporación y salida no han sido capturados correctamente en este sumario, pero son evidentes visualmente como se puede apreciar en la Figura 7.

Tabla 3. Comparación de datos de carreteras del DASC para los condados de Douglas y Johnson.

Figura 7. Izquierda: enlace sin editar. Derecha: intersección corregida con incorporaciones.

Además de ediciones centradas en vías de doble calzada y representación de enlaces, se realizaron muchas mejoras menores en los datos tanto por el personal del NGTOC como por el del DASC, que no se muestran en la tabla superior.Muchas entidades mostraban discrepancias menores en su representación con respecto a la ortofotografía, como por ejemplo tramos cortos en Interestatales. En la mayor parte, estos problemas entran dentro de la tolerancia de error especificada por las Mejores Prácticas del NGP. Sin embargo, la naturaleza de la interfaz del OSMCP permite al usuario identificar y corregir rápidamente estos pequeños errores posicionales. De igual manera, se realizaron muchas pequeñas mejoras a los atributos cuando el usuario los advierte, como por ejemplo un uso consistente de abreviaturas y uso de mayúsculas. No se realizó una medición de estos cambios menores.

6.1 Análisis del software OSM para edición colaborativa
El software de OSM proporciona una plataforma fácil de usar, que se ejecuta en un navegador web, y que permite co-edición por personal geográficamente disperso. Durante el proceso se identificaton los siguientes resultados positivos y negativos.

Positivo

• OSM y su software tiene mayor soporte y apoyo por parte de la comunidad de I.G. Voluntaria que los otros sistemas en consideración
  ◦ ArcGIS 10 soporta editar datos a través de la API 0.6.
  ◦ FME 2011 soporta leer y escribir el formato XML de OSM.
  ◦ Existen múltiples herramientas gratis y libres además del editor Potlatch que se consideran parte del núcleo de la infraestructura.
• El software de OSM es razonablemente sencillo de configurar y utilizar
  ◦ El software es gratis y sin restricciones por licencias.
  ◦ El software se puede utilizar en múltiples puestos sin necesidad de negociar nuevas licencias de software.
• Varias agencias pueden editar los mismos datos con las mismas especificaciones a la vez.
  ◦ La detección de conflictos funciona bien.
  ◦ Se realiza control de versiones automático y no se necesita hacer una copia local de los datos antes de editarlos.
  ◦ La plataforma soporta miles de sesiones de edición simultáneas.
  ◦ El proceso de edición en Potlatch (en un navegador) es mucho más rápido y fácil que ArcGIS.
  ◦ Potlatch permite crear datos geoespaciales complejos sin necesidad de experiencia técnica

Negativo

• Configurar el software necesita de personal con conocimientos de Linux, Ruby on Rails y PostgreSQL.
  Existen pocas oportunidades de formación para desarrollar un buen nivel de competencia con estas herremientas. El personal que trabaje con el proyecto necesita entirse cómodo siendo autodidacta para con las herremientas de OSM (Steve Coast, omunicación escrita, 2010).
• Algunos artefactos en los datos pueden sobrecargar la base de datos de OSM.
  El software de OSM no puede manejar buen números extremadamente grandes de bjetos en una pantalla. Por ejemplo, algunas de las entidades de carreteras del DASC ontenían un número inusualmente grande de puntos (miles de puntos en un tramo de arretera recta de un kilómetro de largo). Las consecuentes llamadas a la API y queries QL tomaban mucho más tiempo del esperado.
• Trabajar en la DMZ del USGS puede dar lugar a problemas.
  La API 0.6 de OSM es una aplicación de Ruby on Rails. Usa HTTP para la omunicación cliente-servidor. El proxy eSAS incluye ficheros para detectar tráfico TTP “inusual” de y hacia los servidores dentro de la DMZ (USGS, 2010)[11]. La comunicación entre el cliente Potlatch y la API estaba siendo continuamente impedida por el filtro eSAS, porque las URLs pasadas al servidor no son fácilmente predecibles. Al contratio que los filtros y proxy web usados por los usuarios de escritorio del USGS, el proxy eSAS bloquea el tráfico, sin proporcionar errores específicos como “bloqueado por cortafuegos”. Un cortafuegos con filtrado agresivo cautó lo que parecía ser problemas en la configuración de la aplicación. Inicialmente fue difícil determinar si el problema estaba en la configuración del servidor, o en alguna otra parte. Se gastó una cantidad significante de esfuerzo comprobando la configuración de los servidores y preguntando a la comunidad de OSM antes de sospechar del cortafuegos.
• Los editores de OSM están diseñados para un control de calidad cualitativo, no cuantitativo.
  La filosofía detrás de OSM se basa en calidad implícita en vez de en calidad explícita. OSM no tiene en cuenta ninguna medida cuantitativa de calidad de los datos, tal como precisión posicional o actualidad. En su lugar, se supone que los usuarios de OSM identificarán errores de calidad en el mapa, específicamente en las entidades en el área local del usuario, y que las corregirá hasta llegar a la mejor representación posible. Las herremientas diseñadas por la comunidad de OSM reflejan una noción de calidad siguiendo el principio de la Ley de Linus, que dice que “si hay suficientes ojos, se pueden ver todos los errores” (Raymond, 2001). Esto quedó demostrado por las pequeñas ediciones de tipo posicional y atributos que quedaban fuera del ámbito de la Fase Uno.

7. Discusión y dirección futura

La Fase Uno del OSMCP ha probado que es posible crear y mejorar datos según las especificaciones del USGS a través de un prototipo de I.G. voluntaria. El esfuerzo terminó con la creación de un sistema funcional para contribuciones de entidades colaboradoras a través de edición colaborativa de datos espaciales, por múltiples organizaciones en un entorno distribuído. La plataforma prototipo de I.G. voluntaria proporciona un punto de partida para, en el futuro, seguir evaluando la utilidad y efectividad de la I.G. voluntaria para el National Map.

7.1 Fase Dos
En la Fase Uno, las entidades colaboradoras externas al USGS que contribuyeron con ediciones eran parte de una única oficina de información geográfica estatal. El DASC es una organización formalmente estructurada, con experiencia profesional en SIG. La Fase Dos no se centrará en carreteras, sino en la capa de estructuras. Históricamente, el cuerpo del National Map se centró en datos de estructuras. Son algo menos complejos que los datos de carreteras, pues consisten únicamente en puntos sin relaciones topológicas, en lugar de líneas o arcos con una topología relativamente compleja. La Fase Dos se construye a partir de la plataforma OSM ya existente, pero se actualizará la interfaz de usuario para usar Potlatch 2. Esta nueva versión de Potlatch proporciona una mayor flexibilidad para incorporar especificaciones de datos específicas a una organización. Se crearán conjuntos de teselas de fondo de mapa adicionales, a partir de servicios de mapas web (WMS) ofrecidos como parte del National Map (http://services.nationalmap.gov/ArcGIS/rest/services/TNM_Vector_Large/MapServer) y mapas topográficos escaneados (http://raster.nationalmap.gov/ArcGIS/rest/services/DRG/TNM_Digital_Raster_Graphics/

La Fase Dos se centrará también en incorporar un componente más público, basado en voluntarios. En lugar de trabajar con una organización estatal especializada en SIG, el USGS involucrará a clubs de aficionados de SIG en las universidades del área de Denver, para recoger de manera sistemática datos de estructuras para los quads topográficos de 7.5 minutos del área de Denver: Arvada, Commerce City, Fort Logan, y Englewood. Esto permitirá al USGS entender la cantidad y calidad de los datos recolectados por voluntarios. Debido a que la fase 2 involucrará a una audiencia más amplia y menos formal, se prestará especial atención a los elementos de la interfaz del OSMCP para asegurarse de que cumplen fielmente las especificaciones del USGS. Uno de los conceptos básicos del diseño centrado en el usuario es construir interfaces que guíen al usuario naturalmente a través de los pasos correctos de un proceso. Al prestar atención a los detalles de la interfaz de usuario, el usuario final tendrá menos problemas siguiendo las directrices de recogida de datos.

Otra meta importante de la Fase Dos será explorar métodos para no sólo entender la calidad de los datos de voluntarios, sino también gestionar el control de calidad de los datos que se recogen. Se explorarán métodos que involucren “editores de usuarios”. En otras palabras, el proyecto incluirá una investigación de el uso de voluntarios para realizar el control de calidad sobre los datso recogidos por otros voluntarios. Además, se explorarán métodos cuantitativos para determinar el nivel de compleción. Se identificarán los errores de estructuras mal identificadas (errores de comisión o de atributos), así como métodos para estimar estructuras no presentes (errores de omisión). Una posible técnica implica comparar los datos contra conjuntos de datos ya existentes como los del Sistema de Información de Nombres Geográficos (GNIS). Estos métodos para estimar la calidad serán un factor importante para determinar los siguientes pasos del uso de datos de voluntarios en el National Map.

7.2 Fase Tres
Si los resultados de la Fase Dos indican que la incorporación de datos provenientes de voluntarios proporcionan datos de calidad a un coste menor que otros métodos de recogida de datos, la Fase Tres del OSMCP expandirá la recogida de datos de estructuras a áreas más diversas. Usando los quads de 7.5 minutos como una estructura organizativa para monitorizar la calidad de los datos, se elegirán quads específicos para probar la capacidad de los datos contribuídos por usuarios, especialmente en áreas rurales (Brando, 2010; Girres, 2010; Haklay, 2010)[1]. Entender cómo incentivar actividades de recogida de datos en estas áreas hará que se cumpla mejor el objetivo de cobertura uniforme del National Map. Se involucrará un abanico más amplio de voluntarios (Tabla 4). Diferentes grupos de voluntarios proveerán diferentes oportunidades de sostenibilidad. Por ejemplo, la captura inicial de grandes áreas remotas puede necesitar de grupos más preparados técnicamente como clubs de SIG. Sin embargo, el mantenimiento puede ser gestionado mejor a través de revisiones regulares por grupos de escuelas primarias, donde un nuevo grupo de voluntarios puede revisar los datos cada año.

Tabla 4. Grupos potenciales de voluntarios para la Fase Tres.

La Fase Tres implicará menos cambios tecnológicos a la plataforma, prestándose mayor atención al aspecto de la interfaz para cumplir con los estándares del USGS. Se han sugerido varios modelos de calidad de datos para la información geográfica voluntaria. Un modelo importante se centra en la calidad de los contribuidores de datos (Grira et al, 2009)[5]. La Fase Tres utilizará métodos automatizados para estimar la calidad, cuando y donde sea posible, para crear indicadores de calidad para los usuarios. El nivel de formación necesaria puede ser variado a través de los distintos grupos de voluntarios, para determinar la formación necesaria para cumplir con los estándares de calidad de datos.

Agradecimientos
Este proyecto no habría sido posible sin el apoyo actico del Centro de Soporte y Acceso de Datos, los esfuerzos del personal de Soporte de Tecnologías de la Información del NGTOC en Rolla, y el interés y entusiasmo de la comunidad de OSM. Austin Green proporcionó un valioso apoyo durante la creación de los tados traducidos mediante FME 2011. HEnnifer Walters creó el documento de especificaciones de edición usado en el proyecto. A través de la comunidad de OSM, recibimos comentarios a través de listas de correo que beneficiaron directamente al proyecto; de Steve Coast, Richard Weait, Brett Henderson, IAn Dees, Andrzej Zaborowski, Matt Amos, Tom Hughes, Andy Allan, Shaun McDonald, Richard Fairhurst, Steve Bennett y Brendan Morley.

Notas
1. N. del T.: un quad es una hoja del mapa topográfico 1:24000 del USGS.
2 National Oceanic and Atmospheric Administration.
3 N. del T.: El highway norteameticano es similar a una autopista (de alta velocidad y acceso limitado), mientras que OSM usa highway en su sentido británico, que equivale a las carreteras convencionales españolas.

8. Bibliografía