Photo credit: Megan Bearder / Wolfram Alpha LLC

© Copyright http://www.flickr.com/photos/stevecoast/

Con esta publicación empiezo, lo que espero sea, una serie de traducciones de notas escritas por Steve Coast en OpenGeoData.org.

Steve es el fundador de OpenStreetMap y CloudMade, además de líder tradicional de la comunidad.

Algunos días antes del terremoto de Febrero, empezo a publicar estas reflexiones que, aunque en algunos casos han causado controversia en las listas de correo, pienso merecen ser compartidas en nuestro idioma.

Empezamos con OpenStreetMap – The Best Map.

Este es un capitulo que escribí para un libro que puede o no ver la luz del día. No esta muy pulido, pero oigan, ¡Es libre! Le debo agradecer a Andy Allan, Tom Carden y Paul Jarret por revisarlo y ofrecer correcciones. Cualquier error residual es por supuesto, solo de ellos.

OpenStreetMap – El Mejor Mapa

Los Mapas están rotos y la mayoría de la gente no lo sabe. Ese es el problema que OpenStreetMap, el mapa libre del mundo, esta diseñado para resolver. Los Mapas, como tantos productos técnicos, replican la clásica analogía de los embutidos – muy sabrosos, pero no querrás saber como se hacen.

Así es que ¿Como se hacen los mapas tradicionales? y ¿Como son recolectados los datos que los componen? Hay un par de respuestas. Los gobiernos locales y muchas agencias especializadas en el sector publico están profundamente interesadas en el diseño de sus recursos, edificios, etc. Enormes esfuerzos son hechos por departamentos de bomberos, policía y otros para construir mapas altamente precisos (los datos) y bellos (la cartografía). Apoyados por el contribuyente (N.T: En el sentido tributario) y con requerimientos muy específicos, estos mapas locales son usualmente de gran calidad.

Dando un paso atrás por un segundo, ¿A que nos referimos con calidad? A grandes rasgos la puedes medir de tres maneras: profundidad, cobertura y oportunidad.

Aquí profundidad se refiere a la escala, o nivel de detalle del mapa. ¿Tienes todos los caminos mas no las sendas peatonales? o ¿El contorno del país pero no los caminos? Cada cual es útil a su manera. Algunas formas de pensar sobre esto, es que la profundidad puede querer decir la escala del mapa o el eje Z o altura sobre el área y lo que puedes ver desde aquella.

Cobertura son las otras dos dimensiones espaciales. ¿Tienes todos el planeta o solo un país en el mapa? ¿Un pueblo o solo algunas calles? Este es el X e Y en nuestro volumen cartesiano.

Finalmente, tiempo. Tienes un mapa completo en alguna profundidad y cobertura, pero es de 1956. Aunque muy útil si es que eres un historiador, suficientes cosas han cambiado con los años haciéndolo mucho menos útil hoy. Y aunque 1956 es un extremo para lograr mi punto, los mapas de un año atrás pueden ser igualmente inútiles si es que vives en un camino construido hace 6 meses.

Los Físicos reconocerán esto como las tres dimensiones espaciales más el tiempo, que es una analogía perfecta para comparar mapas.

Volviendo a la creación de esos mapas. ¿Como se hace? Normalmente un profesional, alguien que tiene un grado en algo relacionado con mapas con una (aun más importante) chaqueta de seguridad con brillo fluorescente gastara su tiempo en tu área midiendo cosas. Ellos tendrán acceso a varias de maravillas técnicas para ayudarlos a medir cosas. ¿Que cosas? Los nombres de los caminos, el ancho de este, el contorno de un edificio… en general, todo lo que puedas imaginar dentro de la profundidad objetivo de su mapa.

La tecnología que ellos usaran va desde una simple brújula a avanzados GPS y sistemas de medición de distancia a través de láser. Pero importa eso realmente, todo lo que necesitas saber es que las cosas son medidas y en general, se ha hecho más y más preciso durante los últimos miles de años.

En el contexto del gobierno local, las presiones de eficiencia y las fuerzas del mercado no se sienten tan profundamente y por lo tanto el tiempo y esfuerzo que se pueden dedicar al mapeo son normalmente significativos. En muchos casos, excesivos. Esto deriva en algunos mapas realmente bellos. La belleza es generalmente reconocida como difícil de definir, asi es que para este ámbito de aplicación pensemos en términos de un mapa muy detallado con una muy buena mezcla de los insumos cartográficos elementales – color, tipografía, diseño, etc.

Afuera en la industria, que es otro país para la academia y el gobierno, este no es el caso. Solo una cierta cantidad de tiempo y recursos están disponibles para producir un mapa, y la pregunta se convierte en una de asignación de recursos. La más simple asignación que puedes hacer para los mapas de todos los días es hacerlos donde la gente esta – donde los usan. Claro, esto es en ciudades donde la densidad poblacional hace el mapeo de esas áreas mucho más eficiente que afuera en el campo.

El lado positivo de descuidar las zonas de baja población es que hay menos clientes ahí para usar esos mapas, y por tanto pagar por ellos. Por lo tanto hay poca justificación para gastar igual esfuerzo en áreas equivalentes.

Y aquí chocamos de frente con uno de los mandamientos tradicionales del mapeo; mapearas todas zonas por igual. Es en el mejor de los casos un paso en falso, el sugerir en los círculos cartográficos que el mapeo del campo debiera obtener menos recursos que el de la ciudad. El pilar clásico de servicio universal para todos, independiente de donde vivas, esta frente a ustedes. Sea en el servicio postal, cuidado de la salud o calidad de los caminos, mucha gente (que normalmente, por supuesto, vive en el campo) siente que la calidad de este tipo de servicios debiera ser la misma en todas partes.

Es una cara perspectiva, el mapear la vasta extensión de las áreas de baja densidad poblacional incluso en continente ricos y por lo tanto no ocurre tan a menudo. Lo bueno es que con menos usuarios, y menos por mapear, hay menos fallas (faltas de precisión) en los mapas, y por supuesto, menos clientes para reportarlos. Problema resuelto.

Tradicionalmente, los recursos para mapear son organizados de un manera bastante verticalizada. Si quieres mapear un país compras un cierto numero de autos, los llenas con computadores y equipos de medición, y entrenas a la gente para operarlos. Luego les dices donde manejar y ellos van, reportándose con sus datos y progreso.

Mira a barlovento y vemos a OpenStreetMap (OSM). En su núcleo OSM es simplemente una plataforma para que cualquiera registre cualquier cosa que quiera, en cualquier parte. No es distinto de las plataformas para mapear utilizadas por los gobiernos, los militares y empresas en todas partes. El truco esta en que nos quitamos del camino.

¿Como nos quitamos del camino? Bueno, no requerimos que seas un empleado, para empezar. Somos realmente abiertos a todos, y somos completamente agnósticos sobre que, como y porqué tu mapeas. Esto es muy importante.

Imagina que eres un recopilador de datos en el camino, trabajando para una empresa tradicional de mapas. Tu trabajo es intensamente monótono. Conducir todo el día en área que no conoces, se espera que registres detalles de todo alrededor tuyo de una manera muy estructurada. Un camino es tipo 22 y un taller mecánico es tipo 56. La geometría debe ser precisa hasta cierta tolerancia. No tienes permitido mapear senda para bicicletas, porque estamos haciendo un mapa de caminos para una empresa de mapas tradicional.

Eso es sumamente restrictivo y elimina toda la noción de interés y la creatividad en la construcción de un mapa. Además de eso, cuando tus ejecutivos muestran vídeos de ti manejando por ahí y cocinando tus propias comidas al costado del camino a audiencias interesadas, ellos se ríen de ti – ¿Como puede la gente ser tan estúpida de vivir en un auto y trabajar para nosotros haciendo este trabajo sin sentido?

Si por alguna poderosa fuerza pasas estas barreras, aun no es particularmente probable que te preocupes del camino donde vivo de la forma en que yo lo hago. Entonces, es menos probable que captures buenos datos, lo que deriva en malos mapas.

Y eso es lo que cuenta. Voluntarios en todas partes aman sus barrios y hacemos todo lo que podemos para quitarnos del camino entre el cariño que tienes y el que lo codifiques en el mapa. Puedes ser un ciclista con un vivo interés por las rutas para bicicletas, un caminante buscando sendas o simplemente necesitar un buen mapa base. En cualquier caso, eres bienvenido para hacer bello al mapa de la forma que te parezca.

Independiente de que mapees esta el como lo mapeas. Los métodos abundan. Hoy tu puedes imprimir un mapa, dibujar cualquier cambio sobre el, escanearlo y cargar este a un sitio en Internet como tu fuente de datos. Puedes usar un GPS para crear una senda virtual de puntos como el rastro de migas de pan de Hansel y Gretel. Puedes estar usando una cámara para capturar fotos geo-referenciadas de drenajes de tormentas cerca de ti. No nos importa.

Y por supuesto, no nos importa tampoco donde estas. Sea la India, Canadá o la zona del ultimo terremoto o tifón. Es por esto que somos una planicie de libertades porque cada restricción que pones en un contribuidor reduce el numero de contribuciones de ellos, y por tanto la calidad del mapa final.

Esto se debiera sentir muy parecido a Wikipedia, que fue en general la plataforma más simple que podrías armar para permitir a la gente escribir artículos de texto, con muy pocas restricciones. Exploto a la posición en la que está hoy basada en esas libertades. Contra intuitiva para muchos, pero sera obvia para nuestros nietos.

Los Metadatos en OSM son abiertos y tan simples como se pueden tener. Cualquier punto, lineas, u otra características en el mapa puede tener un numero de etiquetas que consisten en pares clave y valor. highway=residential; name=Calle A por ejemplo. La claves actuales y sus valores comúnmente utilizados evolucionan simplemente de la gente utilizándolos y el consenso de la comunidad. El dictarlos como en una ontología de arriba hacia abajo (N.T.: top-down) hubiera sido una locura.

¿Por qué? Porque para empezar ningún individuo podría diseñar una ontología que lo abarcara todo, e incluso si se pudiera empezar no habrían dos personas que concordaran en ella. Así es que nos quitamos del camino.

Las herramientas utilizadas para mapear, el software, es igualmente agnóstico. Existe una simple API XML para la cual cualquiera puede escribir software que le hable. Todo lo que esto significa es que hay una manera publicada y definida para que tu software mágicamente hable al mapa y lo cambie. La definición es tan simple como es posible y deja la complejidad a la etiquetas mencionadas previamente.

La primera critica a OSM fue la calidad de los datos. ¿Como podría un mapa de solo unas pocas calles ser útil para cualquiera? Esto tiene su raíz en viejas ideas acerca de la calidad de los mapas – que un mapa solo puede ser útil si es que esta ‘completo’ y es ‘preciso’. Términos que espero probar aquí no tienen sentido en lo absoluto – ningún mapa esta completo o es preciso – y son útiles como términos relativos.

La clave claro esta en que un mapa de solo algunas calles es útil, si es que ellas son las calles cerca de ti, o aquellas para una tarea especifica. Así mismo, unas pocas calles cerca de ti son útiles también … y como un rompecabezas el mapa puede ser construido de esa manera. O tu puedes pensar OSM como un frankenmapa. Construido con datos de un tipo y fuente aquí y otras allá. Caminos en Londres de alguien y restaurantes de pizza en Berlin de alguien completamente diferente y nosotros integramos y “suavizamos” este basto rompecabezas de datos a lo largo del tiempo en algo coherente y bello.

Hoy el mapa aun no esta completo y aun atrae estas criticas, que muestran una sorprendente falta de perspectiva. Realmente importa muy poco donde esta el mapa en cualquier punto del tiempo, el punto es que a diferencia de casi cualquier otro mapa del planeta, esta continuamente mejorando. Exponencialmente en profundidad, cobertura y oportunidad.

Una buena respuesta es que cualquier critica a un contenido wiki es una autocrítica. Si atacas un articulo en Wikipedia porque le falta un dato o tiene una falta de ortografía o redacción, entonces es casi seguro que arreglarlo – algo que tienes la libertad de hacer – es más rápido y mejor que criticarlo. Así mismo, criticar a OSM por lo incompleto que pueda estar es algo extremadamente barato dada las libertades que tienes de arreglarlo o organizar a otros para hacerlo.

El segundo conjunto de criticas va hacia el enfoque de OSM – que sus herramientas simples, falta de protocolos complejos para comunicar los datos del mapa, ontología indefinida y servidores que se subían y caían como yo-yos… …trabarían el proyecto. Revisemos cada unos de estos.

Antes de OSM, las herramientas para construir mapas eran hechas para profesionales. Profesionales que pasaban años aprendiendo sobre mapas. Profesionales que vestían chaquetas fluorescentes, Profesionales que tenían un inherente interés en excluir a los no-profesionales. Así es que las herramientas eran hechas para ellos. Si vas a a atraer a voluntarios, necesitas un conjunto de herramientas completamente diferente. No puedes simplificar las herramientas de edición de forma tal que cualquiera pueda, salido de la nada, editar exitosamente complejas intersecciones de carreteras, pero puede tratar. Y nosotros los hacemos.

Y por supuesto, las herramientas son todas abiertas y libres. Si tienes un problema con ellas, eres libre de arreglarlas tu mismo o alentar/pagar a alguien para que lo haga por ti.

Los protocolos para transmitir y mutar los datos de mapas son generalmente complejos. Excesivamente complejos. OSM adopto el enfoque más simple que pudo y lo reitero, junto con buena parte del proyecto. OSM tomo una visión casi ingenua del mundo para encontrar la forma de representarlo al principio – simplemente puntos y lineas entre dos puntos. Con etiquetas en cada uno, y eso era todo. Hoy es un poco más complicado, pero no por mucho. ¡Hoy tenemos lineas que pueden ir entre más que dos puntos!

Entonces, en 2005 o por ahí, OSM era tan simple en su resultado. Todo dato, independiente del tipo era dibujado como simples lineas blancas en un fondo verde oscuro, cuando funcionaba. La introducción del color fue una cambio de escalón en los datos que fueron ingresados. Y es así como el proyecto ha superado normalmente sus metafóricos puentes. Si tu provees la salida, como renderear las autopistas diferentes de los caminos, o proveer enrutamiento entre direcciones, entonces la gente ingresara datos que sean utilizables. Si expones las herramientas para visualizar los datos del mapa (como dibujar hoteles donde existen) entonces la gente te dará los datos para hacer uso de ellos (ingresar hoteles en el mapa).

Al no limitar a los contribuyentes con una ontología dos cosas son posibles. Primero, tipos de datos creativos e inesperados pueden ser agregados – y esto pasa todo el tiempo. Segundo, expones un aspecto lúdico del proyecto que es el permitir la experimentación. El lado negativo potencial es que la gente agregue datos malos a propósito o por accidente, pero el lado positivo de las libertades y la gente que atrae superan ampliamente los potenciales problemas.

Como ha sido notado varias veces, el problema de escalar un sitio web para que sea utilizable con más usuarios es un buen problema a tener, comparado con el problema de no tener usuarios en lo absoluto. OSM por suerte ha tenido este problema durante toda su vida, y ojala lo tenga siempre. El que muchas veces se haya visto sobrecargado, no es sorpresa tomando en cuenta que el presupuesto para el proyecto completo sobre 5 años, excluyendo conferencias y constituido enteramente por donaciones, es probablemente inferior al salario de un profesional bajo. Hoy un dedicado grupo de programadores profesionales y administradores de sistemas trabajan voluntariamente para mantener OSM y estamos en una mucho mejor posición.

Hablemos sobre eficiencia. Puedes medir la eficiencia de un mapeador con la cantidad de cosas que recolecta (que es presumiblemente precisa) dividido por el costo. Un empleado de una empresa de mapas tradicional puede mapear 1.000 caminos al día por un costo, incluyendo auto y gastos generales de digamos $1.000 dolares. Esto nos da una eficiencia de $1 por camino. OSM por supuesto es una actividad no pagada lo que nos lleva a dividir el numero de caminos (digamos 1.000 nuevamente) por cero, que es el costos de capturar esos caminos. De forma tal que OpenStreetMap es infinitamente eficiente. Es difícil competir con eso.

Aunque siendo serios, ninguna comparación de eficiencia de mapeadores es razonable debido a las motivaciones y tipos de datos. Los contribuyentes de OSM mapean muchos tipos de datos relevantes para ellos, en los dias y horarios convenientes. La idea de pasar mapeando 9×5 convertiría esto instantáneamente en un trabajo en lugar de un hobby, y por tanto en algo muy poco atractivo.

¿Donde falla OSM? Podemos hacer una analogía más extensa a Wikipedia y la sobredimensionada noción de que cualquiera puede romperla escribiendo tonterías en cualquier articulo que se le ocurra. Wikipedia evoluciono una idea de Punto de Vista Neutral (NPoV) para combatir esto. Los artículos debieran ser escritos como si los describiera una persona externa y neutral. Entonces, muchas herramientas son utilizadas para rastrear datos ingresados maliciosamente.

Este ultimo punto es crucial. Muchos tienen la noción de que encontrar ediciones maliciosas en Wikipedia es equivalente a una aguja en un pajar – doloroso y difícil de encontrar. Esto simplemente no es el caso. Existen herramientas simples que por ejemplo listan la actividad de edición de los últimos 10 minutos. Cualquiera puede leer estas listas y revisar que las ediciones sean validas, y mucha gente lo hace. Adicionalmente, existen medidas técnicas simples como revisar por improperios.

OSM deja de lado casi por completo estos asuntos, porque ningún NPoV es necesario. Estamos mapeando datos reales después de todo – es difícil discrepar con la existencia de la ciudad de Nueva York. Así pues, cualquier asunto de opinión – que es potencialmente un asunto mayor – es esquivado.

Por lo tanto las ediciones erróneas caen una de tres categorías: errores involuntarios, discrepancia en los datos, y ediciones maliciosas.

Los errores involuntarios son los más comunes y fáciles de corregir con herramientas como las que utiliza Wikipedia, junto con la honestidad que lleva a un nuevo contribuidor a probar y volver a arreglar la cosas ellos mismos.

Las discrepancias tienden a ocurrir en puntos de conflicto político. Cualquier lugar donde tengas a un par de gobiernos discrepando sobre quien posee cierta tierra por ejemplo. Piensa en Corea del Norte y Corea del Sur, Pakistán y la India, y la República Turca del Norte de Chipre. En muchos de esos casos, la batalla entre contribuidores es mucho menor de lo que podrías esperar – no se trata de si un camino existe, ni de que podría tener dos nombres en diferentes idiomas. Ni siquiera de que se muestren ambos nombres, ¡Sino de que nombre se muestra primero!

Considero este tipo de pasiones lejos de destructivas, si es algo, es un testamento increíble a la cantidad de esfuerzo que los contribuyentes están dispuestos a verter en el mapeo de su área.

La ediciones maliciosas son probablemente las menos significativas y siempre existirán. Vivimos en un mundo en que la mayoría de la gente, la mayor parte del tiempo, quiere hacer lo correcto, y esto se ve reflejado en un buen mapa. Las ediciones maliciosas ocurren tan infrecuentemente y las herramientas son tan buenas para detectarlas, que duran muy poco. Este es un buen precio a pagar por todos los otros beneficios de un mapa Libre.

Pero veamos las alternativas. Si tienes un problema con Wikipedia u OSM eres libre de comprar una enciclopedia o mapa, usar una fuente comercial o visitar tu biblioteca local. En ningún momento querríamos obligarte a usar estas herramientas abiertas y libres. Pero para la mayoría de la gente las pequeñas potenciales desventajas de tener un mal articulo o mapa, y es una pequeña posibilidad, es ampliamente superado por los beneficios de ser libres en ambos sentidos de la palabra.

OSM es licenciado abiertamente. Esto quiere decir que no solo la imagen del mapa esta disponible para que la uses bajo ciertos términos como un mapa tradicional. Quiere decir también que la imagen, los datos subyacentes y casi todo lo demás, como el software, están disponibles. No solo disponible, sino que también eres libre de modificarlo todo.

Se requieren dos cosas cuando usas datos de OSM – primero que si modificas cualquier cosa, gentilmente distribuyas esas modificaciones a todo el resto de la gente bajo los mismo términos. Esto se conoce como Compartir Como (Share Alike) o el aspecto viral de la licencia. Lo otro que te pedimos hacer es decir donde conseguiste los datos en primer lugar.

Estas son peticiones pequeñas y muy razonables que mantienen al proyecto unido. En la practica significan varias cosas, pero solo destacaremos una: Asegura la retroalimentación. Cualquier cambio debe alimentarse de vuelta al mapa y al software continuamente. Esto evita que gente tome el mapa, lo mejore, y luego lo cierre a otros contribuidores. Actúa para forzar un “bien común” de datos en crecimiento.

Por supuesto, mucha gente discrepa con la idea de contribuir de vuelta recíprocamente. Una empresa tradicional de mapas probablemente amaría el tomar los datos de OSM para el área rural y combinarlos con sus propios datos más completos de una ciudad, para construir un mapa completo. Esto podría parecer razonable desde su perspectiva – ellos se concentran en un área importante y obtienen el área menos monetizable gratis.

Sin embargo, desde la perspectiva de la comunidad, no hace mucho sentido. Significaría que la versión comercial del mapa seria perpetuamente mejor que OSM de forma tal que menos y menos esfuerzo irían a OpenStreetMap. Solo ese hecho es suficiente para hacerlo inútil, por no hablar de que muchos sentirían como sucio el ayudar a una empresa a completar su mapa gratis. Este en contraste con una empresa que basa sus productos en un mapa reciproco, y hace esfuerzos por mejorarlo, en el entendimiento de que la marea subiendo flota a todos los botes.

¿Seguramente el proveedor tradicional de mapas proveerá algunos datos para ayudar a OSM a cambio? En casi todos los casos, este simplemente no es el caso. Hay muy pocos incentivos para contribuir a su propia extinción. Porque eso es lo que esta pasando.

En una conferencia recientemente, fui abordado por un iracundo ejecutivo de una empresa de mapas tradicional, enojado porque encontraban tan difícil trabajar con OSM. No por la calidad de los datos, el formato o la ontología, sino porque la licencia los forzaría a contribuir de vuelta. Por supuesto, no estamos obligando a nadie a trabajar con datos de OSM, pero cuando lo haces, estos son los requerimientos.

Esas empresas amarían el que esas restricciones desaparecieran, pero sin ellas, hay pocas razones para que cualquiera contribuya al bien común. Terry Pratchett resume sucintamente esto con la canción “wouldn’t it be nice, if everyone was nice” (¿No seria agradable, si todos fueran agradables?). Ese es el porque de estas dos simples restricciones (reciprocidad de compartir las modificaciones a los datos, y atribuir a quien te los proveyó) han evolucionado con muchos proyectos abiertos, para proveer el balance correcto de zanahoria y garrote, para proveer la plataforma legal común para contribución más básica posible.

El que OSM proveyera todos sus datos bajo Dominio Publico seria claramente más simple, pero yo humildemente afirmo que seria tan simple que quedaríamos con un simple conjunto de datos vacío. Esto es conocido como la tragedia de los bienes comunes – si tienes un recurso de propiedad común del que todos pueden consumir sin la necesidad de reponerlo, este se agotara. Hay algunas excepciones a esa regla, pero OSM probablemente moriría rápidamente en un ambiente totalmente abierto. Además, ha funcionado brillantemente hasta ahora, ¿Para que cambiarlo?

La Comunidad es tan importante en OSM como en cualquier otro proyecto. Si imaginas a un colegio vacío durante un día feriado, es pálido en comparación al rico, ruidoso y vivo edificio de cuando el colegio esta funcionando. Y así es con los proyectos abiertos. Sin una comunidad OSM seria una calle sin salida con una simple descarga de un conjunto de datos estáticos, y casos así abundan. Construir comunidad es difícil, como cualquiera que lo haya hecho te dirá.

Comunidad es una palabra vaga. Muchas empresas piensan que tienen una comunidad cuando en realidad tienen un conjunto de clientes. ¿Como distinguir? Una comunidad puede discutir a su interior y el gráfico de red de esas discusiones se ve como un mapa de Internet: complejo debido a todas las interconexiones entre los nodos de la red. Un conjunto de clientes se ven como un monton de lineas apuntando en un solo sentido, hacia la empresa, que a menudo se ve como un hoyo negro, porque nada logra salir.

Algunas arreglan eso, y proveen una lista de correos o un foro para que la gente se comunique. Es un gran paso, pero normalmente no es suficiente. Una verdadera comunidad es capaz de salir de la caja a la que han sido asignados. La empresas tradicionales puede que te dejen arreglar su mapa para ellos, de una manera bastante restringida, y eso es un buen paso. Pero, ¿Puedes arreglar su software? No. ¿Puedes ayudarlo con su metodología de recolección de datos? No.

Eres una hormiga trabajadora, proveyéndoles algo valioso – datos de mapas. Eso funciona hasta cierto punto, especialmente si es que tienes un gran numero de víctimas (perdón, ¡Clientes!) que te pueden ayudar. Tu como la hormiga trabajadora, incluso obtienes algo de vuelta – un mapa más usable y actualizado. Pero las motivaciones y sentimientos que obtienes de ayudar en un ambiente tan controlado y con poca retroalimentación son nada comparadas con ayudar un proyecto genuinamente reciproco como OSM.

Piensa esto por un segundo, la mayoría de esas compañías que se abren a que los ayudes a corregir sus datos, emplean un segundo nivel para para revisar lo que estas enviando. Ellos recolectan lo errores que les envías y entonces pagan a alguien más para que vaya y los revise. Eso es estúpido por dos razones.

Uno, le dices a tus clientes al primer problema que de hecho no confías en nada que ellos hagan. Eso es un gran desincentivo a la contribución. Si imaginas todos los problemas que tienes que superar para editar un mapa: tienes que preocuparte, tienes que dedicar el tiempo, tienes que entender el problemas, y así… En cada etapa remueves a la mitad de la gente que podría contribuir. ¿Porque adelantarse a todo eso diciéndoles a tus clientes que además no confías en nada que ellos hagan?

Dos, si tu estas pagando para que alguien vaya a mapear de todas formas, para que tener toda la infraestructura de envío de usuarios. Hace poco sentido más allá de ayudar a optimizar donde hagas arreglos y ese es un pobre compromiso comparado con OSM.

¿Importa esto? ¿Habrá solo un mapa? Casi de seguro no. OSM evolucionara en el mejor y más completo mapa posible pero hay bastante tiempo de sobra en las vidas de todos, y diferentes motivaciones para hacer quizás 5-10 mapas posibles, soportados por distintas comunidades o retroalimentación del cliente, porque conducir todos esos caminos de una manera “top-down” por más de un par de compañías no hace mucho sentido financiero.

La empresas también tienden a enredar sustancialmente el ciclo de retroalimentación. OSM siempre ha tratado de minimizar el tiempo entre que tu agregas o arreglas algo en el mapa, y tu viendo ese cambio reflejado para que todos lo aprecien.

Considera esto – el tiempo de ese ciclo para las empresas de mapas tradicionales puede ser de 18 a 24 meses. En OSM es de 18 a 24 segundos o 18 a 24 minutos.

¿Por que es esto importante? Porque cada vez que arreglas algo en OSM tu cerebro te da una pequeña gota de serotonina, o algo, que te hace sentir bien. Y eso viene de un rápido ciclo de retroalimentación. Con la empresas tradicionales tu ciclo de retroalimentación es demasiado, demasiado largo. Cualquier cosa más allá de un par de minutos es muy largo, porque no hay asociación entre el acto de arreglar algo con la buena sensación. Más seguido que no, tu ayuda a arreglar algo y esto cae a un hoyo negro.

De hecho, obtener un email un mes después diciendo que arreglaron algo es un detrimento a que ayudes nuevamente. Seguro, el usuario piensa, debe haber un sistema mejor. Y así es como descubren OSM.

En otra conferencia en la que estuve, el anfitrión y las partes interesadas querían construir un nuevo mapa comunitario, sin embargo en el almuerzo fuimos abandonados a nuestra suerte para encontrar comida. Considera esto – si no puedes construir una comunidad de personas para ir almorzar o tomar una cerveza, ¿Como organizaras una para mapear el mundo por ti?

Los mapas se están volviendo más detallados todo el tiempo. Cada vez que tu aumentas la profundidad y detalle de un mapa desde países hasta rutas mayores, a rutas primarias, a secundarias… todo hasta los edificios. Cada vez que aumentas el nivel de profundidad, aumentas exponencialmente la cantidad de datos en el mapa. Y con eso, aumentas exponencialmente el numero de fallas en el mapa y el tiempo y costos de arreglarlos o volver a registrar todo el mapa.

El costos logístico de producir mapas de una manera “top-down” prácticamente equivale a tener flotas de autos conduciendo alrededor de Norte América y Europa. Aumentar el detalle con senda peatonales y costaría aun más que el beneficio que cualquier compañía obtener si es que trataran de hacerlo de una manera similar. Obtener esto de los clientes y otros es simplemente inevitable – no hay otra forma de hacerlo. Pero muchos trataran de agregar aseguramiento de la calidad entre sus contribuidores y el mapa y eso limitara el alcance y la profundidad de las contribuciones.

Igualmente para los mapas base solo de las rutas, hace sentido hoy el casi solo obtener los datos de la gente. Hemos visto el inicio de esto pasar y como la Destrucción Mutua Asegurada, otras compañías nos seguirán hasta que no quede ningún mapa “top-down” en el mundo.

Aquellos mapa serán, algunas veces y en ciertas áreas, mejores que OSM. Pero el crecimiento de OpenStreetMap es inexorable y como un tren de carga rodara finalmente sobre todo lo que se atraviese a su paso. Puede pasar incluso antes de que las empresas tradicionales se den cuenta de esto e intenten seriamente a obtener datos a través de la gente.

Así, el futuro es brillante para OSM. A medida que el numero de usuarios sube lo hace la cantidad y variedad de los datos ingresados en el mapa. Como un blanco en movimiento con una comunidad detrás de el, OSM es comparable a un mapa de arriba a abajo liberado trimestralmente.

En todas partes, desde zonas de crisis a teléfonos móviles, OSM se esta convirtiendo en el mapa por defecto, así como Wikipedia se convirtió en la enciclopedia por defecto, y eso es algo bello de ver.

Casi cuatro semanas después de ocurrido el terremoto que azoto a la zona centro de sur de nuestro país, la comunidad OpenStreetMap se ha movilizado.

Los primeros días las listas de correo Talk-cl, CrisisMappers y CrisisMappers-Chile simplemente explotaban, pero a medida que las semanas pasaron, las ideas decantaron, y algunos resultados fueron emergiendo.

Mikel Maron de la OpenStreetMap Foundation a través de los excedentes del programa de becas del Open Society Institute para el State Of The Map 2009, gestiono la compra de 7 equipos GPS Garmin eTrex Legend HCx, para ser utilizados en el mapeo de la zona afectada por el terremoto y la implementación de un esquema tipo GPStogo en Chile. Andrés Vasquez, miembro de la comunidad local, se encargo de transportarlos desde Rochester, NY hasta nuestras manos.

Frederik Ramm de Geofabrik implemento un clon del sistema desarrollado para la catástrofe de Haiti en Enero, un sitio con imágenes Garmin, Shapefiles y extractos OSM para la zona que va desde la Región de Valparaíso hasta la Región de la Araucania.

RapidEye, GeoEye, DigitalGlobe, la Agencia de Exploración Aeroespacial Japonesa (JAXA) y la empresa rusa ScanEx (con el satélite Israelí EROS-B) liberaron imágenes aéreas. Cubriendo sectores como Constitución, San Javier, Puerto Saavedra y la Costa Norte de la Región del Biobío en distintas resoluciones.

Cristiano Giovando implemento un WMS con la imágenes liberadas por GeoEye en http://geohub.jrc.ec.europa.eu/mapserv/chile?LAYERS=chile:geoeye el que a su vez sirve tiles bajo la URL del tipo http://geohub.jrc.ec.europa.eu/tilecache/tilecache.cgi/1.0.0/chile/!/!/!.png que pueden ser utilizadas directamente en Potlatch.

Bruce Willet y Chris Nicholas recopilaron un conjunto de archivos Shapefile con datos para las regiones más afectadas.

Dane Springemeyer implemento un servidor de renders con ciclo de refresco rápido, también cubriendo la zona afectada. El cual ha servido como base conceptual para el trabajo que Alvaro Monares esta haciendo con el fin de que configuremos un servidor chileno de renders rápidos.

El mismo Alvaro Monares y Juan Pizarro, han conseguido espacio y enlace para hospedar este proyectado servidor en dependencias del Departamento de Ciencias de la Computación de la Universidad de Chile y la Universidad de Talca, respectivamente. Juan nos anunciaba ayer a través de la lista de correos que la Universidad de Talca ha dispuesto de un servidor para esta iniciativa.

En un esfuerzo de Sebastian Borgwardt y Jean-Guilhem Cailton se tradujo la interfaz de MapOSMatic.

En los próximos días se programara una capacitación en el uso de Potlatch especialmente orientada a la gente de las regiones más afectada por el terremoto, y que viva en Santiago. La idea es que puedan integrar en el mapa sus conocimientos específicos de las ciudades y pueblos afectados.

También se esta coordinando, probablemente para el fin de semana largo del 2,3 y 4 de Abril, un OSM Camp en la ciudad de Talca. La idea es avanzar en el mapa de la ciudad, hasta dejarlo al menos en un nivel superior al de las alternativas comerciales en la Web (Google Maps, Mapcity, Planos.cl, etc.).

Finalmente, el sitio de Ushahidi Chile, que en un principio había migrado a Google Maps como capa por defecto, debiera volver a OpenStreetMap en los próximos días, ya sea a través de un render Custom Style de CloudMade o del render personalizado chileno que debiera estar implementado pronto.

Después del terremoto que azoto a Port-au-Prince y buena parte del sur de Haiti en Enero pasado, la comunidad de OpenStreetMap se organizó para colaborar en el mapeo intensivo de la capital haitiana y sus alrededores, con el fin de prestar apoyo a las actividades humanitarias que se iniciaban.

Aunque al principio se trabajó con las imágenes disponibles a través del servidor WMS Yahoo!, solo algunos días después de iniciar el trabajo GeoEye autorizó el uso de sus imágenes satelitales post terremoto, lo que permitió identificar edificios destruidos y campamentos de sobrevivientes, así como el resto de los daños a la infraestructura (caminos, puertos, etc.).

Geofabrik monto un sistema para generar cada 5 minutos extractos del mapa en formato Shapefile y para dispositivos Garmin.

La gente de ITO junto con cargar en su cuenta de Flickr imágenes del antes y el después de Port-au-Prince, han cargado en Vimeo uno de esos vídeos que solo ellos son capaces de realizar, para mostrar el trabajo de la comunidad durante Enero en el país caribeño.

Más información en:
http://wiki.openstreetmap.org/wiki/WikiProject_Haiti/Earthquake_map_resources
http://wiki.openstreetmap.org/wiki/WikiProject_Haiti