universitat oberta de catalunya -...

UNIVERSITAT OBERTA DE CATALUNYA

Ingeniería Técnica de Informática de Sistemas

ANÁLISIS DE PLATAFORMAS PARA LA

PUBLICACIÓN DE INFORMACIÓN

GEOGRÁFICA EN LA NUBE

Alumno: María Eugenia Hernández Gutiérrez

Dirigido por: Víctor Velarde Gutiérrez

Curso 2011-12 (Febrero)

TFC SIG 2011-12. Análisis de plataformas para la publicación de información geográfica en la nube

Página 2 de 60

Gracias a mi familia y amigos por su comprensión y apoyo incondicional durante todos estos años

y a los consultores de la UOC que me han ayudado a cumplir mi sueño de seguir aprendiendo.

RESUMEN

El presente documento constituye la memoria del Trabajo Final de Carrera (en adelante TFC) titulado Análisis

de plataformas para la publicación de información geográfica en la nube.

Se comienza con una introducción donde se ilustra la importancia de la información georreferenciada en la

sociedad actual para continuar definiendo nuestro proyecto y justificando su necesidad. Además se establecen

los objetivos del proyecto, su planificación y los productos obtenidos.

A continuación se realiza un estudio preliminar analizando qué son y para qué sirven los Sistemas de

Información Geográfica (en adelante SIG, GIS en su versión inglesa), haciendo un breve recorrido por su

evolución, detallando sus funciones básicas: edición de datos geográficos, vinculación de datos de distinta

índole y análisis de datos geográficos o georreferenciados, para terminar explicando la función de publicación

de información geográfica; para ello se analiza brevemente la herramienta Quantum GIS.

Posteriormente se define un nuevo escenario, la Neogeografía, y se estudian a fondo sus contribuciones a

través de la investigación intensiva y organizada de aspectos relacionados, como Web 2.0, mashups

geográficos, redes sociales, APIs de servicios geográficos como los de Google, entre otros.

Paralelamente surge una nueva tendencia denominada Computación en la nube, que implica la aparición de

hardware, plataformas y servicios web donde se externalizan labores informáticas diversas a empresas

especializadas.

Dentro de estas plataformas y en el ámbito SIG, existen varias que permiten el almacenamiento y publicación

de información geográfica. Entre ellas destacan, por orden alfabético, CartoDB, Geocommons, Google

Fusion Tables, ikiMap y ScribbleMaps. Se realiza un análisis técnico objetivo, detallado y comparado de

sus características donde se recogen de manera sintética y clara las capacidades de cada una de ellas.

Estas plataformas son potencialmente utilizables por un gran número de usuarios y organizaciones. Pero en

este TFC se selecciona la plataforma adecuada para una organización concreta, un medio de

comunicación local que pretende desarrollar un sitio web informativo en el que poder ubicar en un mapa las

noticias que suceden dentro de un municipio (eventos culturales, mapas de obras, etc.), además de permitir la

participación ciudadana (quejas al ayuntamiento, objetos perdidos…) y lograr la difusión de sus mapas en

redes sociales y blogs. Se recoge en este apartado el proceso de selección, los pasos a seguir para su

implantación en la organización y el diseño de un prototipo funcional (creación y personalización del blog

municipal en Blogger), mostrando su posible uso por la organización.

Para finalizar este documento se redactan las futuras líneas de continuación, las conclusiones finales y, un

glosario de términos y referencias bibliográficas utilizadas.


Página 3 de 60

ÍNDICE

RESUMEN ........................................................................................................................................... 2 ÍNDICE............................................................................................................................................... 3 1 INTRODUCCIÓN ............................................................................................................................ 5

1.1 Definición del proyecto y justificación...................................................................................... 5 1.2 Objetivos y Competencias...................................................................................................... 6

1.2.1 Objetivos generales........................................................................................................... 6 1.2.2 Objetivos Específicos ......................................................................................................... 6 1.2.3 Competencias................................................................................................................... 6

1.3 Planificación......................................................................................................................... 7 1.3.1 Análisis de Requisitos ........................................................................................................ 7 1.3.2 Metodología ..................................................................................................................... 7 1.3.3 Plazos de entrega y disponibilidad....................................................................................... 7 1.3.4 Recursos materiales .......................................................................................................... 8 1.3.5 Organización de Tareas...................................................................................................... 8 1.3.6 Diagramas de Gantt ........................................................................................................ 10

1.4 Productos obtenidos............................................................................................................ 11 1.4.1 Memoria del TFC............................................................................................................. 11 1.4.2 Presentación multimedia.................................................................................................. 11 1.4.3 Prototipo........................................................................................................................ 11

2 LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA ............................................................................. 12 2.1 Un intento de definición....................................................................................................... 12 2.2 Historia de su desarrollo ...................................................................................................... 12 2.3 Utilidades de los Sistemas de Información Geográfica ............................................................. 13 2.4 Funcionamiento de los SIG. Descripción técnica...................................................................... 13

2.4.1 Carga, edición, visualización y almacenamiento de datos geográficos .................................... 14 2.4.2 Análisis espacial.............................................................................................................. 16 2.4.3 Publicación en Internet, servidores de mapas ..................................................................... 16

3 LA NEOGEOGRAFÍA ..................................................................................................................... 18 3.1 La socialización de los medios de producción de información geográfica .................................... 18

3.1.1 La nueva cartografía. Las APIs de servicios geográficos ....................................................... 18 3.1.2 Servicios web OGC.......................................................................................................... 19 3.1.3 El desarrollo de la tecnología GPS ..................................................................................... 19 3.1.4 La disponibilidad de datos geográficos globales................................................................... 19

3.2 La web 2.0. Distribuida, abierta y colaborativa ....................................................................... 19 3.3 Los mashups, aprender compartiendo ................................................................................... 20

3.3.1 Creación de un mashup ................................................................................................... 20 4 LA COMPUTACIÓN EN LA NUBE ..................................................................................................... 21

4.1 Modelo de servicio .............................................................................................................. 21 4.2 Plataformas en la nube. Funcionalidades básicas. ................................................................... 22 4.3 Plataformas de publicación de información geográfica. Lista de aspectos a evaluar ..................... 22

4.3.1 Vías de carga de datos .................................................................................................... 22 4.3.2 Opciones para las capas base ........................................................................................... 22 4.3.3 Valoración de funcionalidades y usabilidad ......................................................................... 23 4.3.4 Capacidades de estilo y representación en los mapas .......................................................... 23 4.3.5 Opciones para la difusión de mapas en redes sociales y otros medios externos....................... 23 4.3.6 Políticas de seguridad: control de acceso a los datos Y backups ............................................ 23 4.3.7 Cumplimiento con estándares........................................................................................... 24 4.3.8 Interoperabilidad con otras plataformas o servicios externos ................................................ 24 4.3.9 Rendimiento................................................................................................................... 24 4.3.10 Capacidad de trabajo en múltiples navegadores web y tipos de dispositivo ......................... 24 4.3.11 Valoración de la API para programadores: lenguajes, documentación y ejemplos ................ 25 4.3.12 Tecnologías subyacentes .............................................................................................. 25 4.3.13 Modelo de negocio....................................................................................................... 25

5 ANÁLISIS TÉCNICO DE PLATAFORMAS DE PUBLICACIÓN ................................................................. 26 5.1 Cartodb. Base de datos geoespacial para el desarrollo de aplicaciones web ................................ 26

5.1.1 Ficha básica ................................................................................................................... 26


Página 4 de 60

5.1.2 Análisis detallado ............................................................................................................ 26 5.2 GeoCommons. Todo sobre análisis abierto, datos y mapas....................................................... 31

5.2.1 Ficha básica ................................................................................................................... 31 5.2.2 Análisis detallado ............................................................................................................ 31

5.3 Google Fusion Tables. Reúne, visualiza y comparte tus datos online.......................................... 36 5.3.1 Ficha básica ................................................................................................................... 36 5.3.2 Análisis detallado ............................................................................................................ 36

5.4 IkiMap. La plataforma social de la cartografía......................................................................... 41 5.4.1 Ficha básica ................................................................................................................... 41 5.4.2 Análisis detallado ............................................................................................................ 41

5.5 Scribble Maps. Anotaciones visuales sobre mapas................................................................... 47 5.5.1 Ficha básica ................................................................................................................... 47 5.5.2 Análisis detallado ............................................................................................................ 47

5.6 Tabla comparativa entre plataformas .................................................................................... 50 6 SIG TRADICIONAL VS SIG EN NUBE .............................................................................................. 52 7 CASO DE ESTUDIO Y PROTOTIPO.................................................................................................. 53

7.1 Especificación de requisitos.................................................................................................. 53 7.2 Análisis de requisitos........................................................................................................... 53 7.3 Selección de una plataforma ................................................................................................ 54 7.4 Implantación en la organización ........................................................................................... 55 7.5 Desarrollo de un prototipo funcional...................................................................................... 56

8 LÍNEAS DE CONTINUACIÓN.......................................................................................................... 57 9 CONCLUSIONES.......................................................................................................................... 58 10 GLOSARIO............................................................................................................................... 59 11 BIBLIOGRAFÍA ......................................................................................................................... 60

Índice de ilustraciones Ilustración 1. Calendario de trabajo ....................................................................................................... 8 Ilustración 2. Gantt. Fases 1 y 2. PEC1 y PEC2...................................................................................... 10 Ilustración 3. Gantt. Fase 3. PEC3 ....................................................................................................... 10 Ilustración 4. Gantt. Fase 4. Entrega final............................................................................................. 10 Ilustración 5. Diferencia entre un modelo vectorial y un modelo raster..................................................... 15 Ilustración 6. Modelos de aplicación web .............................................................................................. 20 Ilustración 7. La computación en la nube.............................................................................................. 21 Ilustración 8. Compartir con CartoDB................................................................................................... 28 Ilustración 9. Permisos en CartoDB...................................................................................................... 28 Ilustración 10. Rendimiento en CartoDB ............................................................................................... 29 Ilustración 11. Arquitectura de CartoDB ............................................................................................... 30 Ilustración 12. Compartir con Geocommons.......................................................................................... 33 Ilustración 13. Permisos en Geocommons............................................................................................. 33 Ilustración 14. Rendimiento en Geocommons........................................................................................ 34 Ilustración 15. Arquitectura de Geocommons ........................................................................................ 35 Ilustración 16. Rendimiento en Fusion Tables........................................................................................ 39 Ilustración 17. Arquitectura de Fusion Tables ........................................................................................ 40 Ilustración 18. Compartir con ikiMap.................................................................................................... 43 Ilustración 19. Permisos en ikiMap....................................................................................................... 43 Ilustración 20. Arquitectura de la API de ikiMap..................................................................................... 45 Ilustración 21. Arquitectura de ikiMap .................................................................................................. 46 Ilustración 22. Compartir con Scribble Maps ......................................................................................... 48 Ilustración 23. Prototipo funcional del blog municipal ............................................................................. 57

Índice de tablas Tabla 1. Fases del proyecto e hitos ........................................................................................................ 7 Tabla 2. Organización de tareas ............................................................................................................ 8 Tabla 3. CartoDB. Principales características ......................................................................................... 26 Tabla 4. Geocommons. Principales características.................................................................................. 31 Tabla 5. Google Fusion Tables. Principales características ....................................................................... 36 Tabla 6. ikiMap. Principales características............................................................................................ 41 Tabla 7. Scribble Maps. Principales características ................................................................................. 47


Página 5 de 60

1 INTRODUCCIÓN

En estos últimos años estamos asistiendo a un crecimiento exponencial en el uso de información

georreferenciada. El prefijo “geo” unido a la más variada terminología evidencia este hecho.

Estamos inmersos en una sociedad de la información que se está orientando geográficamente al ser capaz de

añadir una referencia geoespacial a las bases de datos (y de conocimiento).

Empresas líderes en el sector de las tecnologías de la información y la comunicación han realizado grandes

inversiones para incluir en sus modelos de negocio la variable geográfica. La empresa de telefonía móvil

Nokia compró NavTeq, una de las mayores empresas de cartografía del planeta. El fabricante de dispositivos

de navegación TomTom adquirió Tele Atlas, empresa europea líder en la creación de cartografía digital.

Google ha participado con GeoEye en el lanzamiento del GeoEye-1, uno de los satélites de observación

terrestre más avanzados del mundo.

Mientras que los Sistemas de Información Geográfica comerciales son sistemas de pago y código cerrado,

limitados a la utilización de especialistas altamente cualificados, se empieza a consolidar un sistema global

de información geográfica análogo a la World Wide Web, abierto, distribuido, colaborativo e interoperable,

permitiendo la creación de nuevos servicios y aplicaciones a partir de otros ya existentes.

Hoy en día ambas tendencias convergen y se complementan: mientras que el usuario común evoluciona hacia

análisis espaciales más complejos, los expertos en SIG comparten cada vez más sus datos mediante

servicios, incorporan en sus flujos nuevos formatos de datos como el KML o toman los mapas de Google como

base para mostrar los suyos. Esto nos deja un nuevo escenario, denominado por algunos SIG 2.0, una

reformulación que consiste en la integración de SIG con funcionalidades geográficas centradas en el usuario.

No obstante, no hay que olvidar que la apertura al público de estas herramientas, a la vez que puede dar a la

información un mayor nivel de calidad debido a la permanente actualización a la que se ve sometida, también

puede ocasionar una pérdida de fiabilidad, siendo necesario mantener una visión crítica y contrastar datos con

otras fuentes.

En la actualidad, un gran número de plataformas, herramientas y recursos hacen que la tarea de crear y

compartir mapas resulte muy asequible a usuarios inexpertos.

1.1 DEFINICIÓN DEL PROYECTO Y JUSTIFICACIÓN

El presente proyecto es esencialmente un trabajo de investigación comparado entre diferentes

plataformas de publicación de información geográfica en la nube.

Las plataformas web de publicación de información geográfica tienen como objetivo la construcción

automática de mapas interactivos a partir de datos de cualquier tipo (demográficos, históricos, culturales,

económicos, etc.) ligados a una localización geográfica concreta, así como su compartición vía web con otras

personas o con el público en general.

Otros Sistemas de Información Geográfica nos permiten crear mapas, visualizar escenarios, integrar

información, presentar ideas en forma gráfica, etc., pero las plataformas que analizaremos se diferencian de

ellos, principalmente, en que proporcionan una infraestructura completa para publicar información en línea,

sin necesidad de instalar nada en nuestros equipos, lo cual constituye un gran avance.


Página 6 de 60

Estas plataformas son bastante recientes y aún poco conocidas; por ello se plantea este trabajo de

investigación. Estudiaremos estas plataformas a partir de un análisis técnico exhaustivo de cada una de ellas y

las compararemos con los SIG tradicionales para detectar hasta qué punto una plataforma online sustituye o

complementa al enfoque tradicional SIG en el ámbito de la publicación y difusión de mapas.

Posteriormente usaremos este conocimiento en un contexto concreto, el de un medio de comunicación local,

en concreto un blog municipal. En la actualidad es bastante habitual que un medio de comunicación local

pretenda ubicar en un mapa las noticias o eventos que suceden en el municipio, permitir la participación

ciudadana o lograr la difusión de esos mapas entre las diferentes redes sociales y blogs.

1.2 OBJETIVOS Y COMPETENCIAS

En este apartado se detallan tanto los objetivos generales como específicos del proyecto, así como las

competencias que deben haberse adquirido al finalizar el mismo.

1.2.1 OBJETIVOS GENERALES

G1. Conocer los fundamentos básicos de los SIG, con mayor énfasis en los nuevos enfoques y

herramientas geoespaciales.

G2. Conocer la problemática de la gestión de información geográfica y en particular de su proceso de

publicación en Internet.

G3. Reflexionar sobre el concepto de computación en la nube aplicado a la información geográfica y sus

implicaciones en las organizaciones actuales.

G4. Aplicar los conocimientos sobre las plataformas en la resolución de las necesidades concretas de una

organización.

1.2.2 OBJETIVOS ESPECÍFICOS

E1. Realizar un trabajo de investigación técnico sobre el panorama geoespacial actual.

E2. Conocer desde un punto de vista detallado el manejo de varias plataformas para la publicación de

información geográfica en Internet, entre las que se encontrarán al menos GeoCommons, IkiMap,

ScribbleMaps, CartoDB y Google Fusion Tables.

E3. Comparar razonadamente y seleccionar una plataforma, indicando cómo sería utilizada por un

hipotético medio de comunicación local.

E4. Aprender el uso de herramientas para la visualización y gestión de datos geográficos como Google

Earth (y algún software SIG libre como Quantum GIS o gvSIG), durante el proceso de prueba de las

plataformas.

1.2.3 COMPETENCIAS

C1. Capacidad para gestionar de manera autónoma un proyecto de análisis técnico de soluciones software,

aplicable al ejercicio profesional.

C2. Capacidad de evaluación crítica y selección de alternativas.

C3. Capacidad para realizar una correcta planificación y ejecución de tareas.

C4. Capacidad para redactar un documento técnico riguroso y sintético sobre el trabajo realizado.

C5. Capacidad para presentar públicamente los resultados del proyecto y responder razonadamente las

preguntas del tribunal de evaluación.


Página 7 de 60

1.3 PLANIFICACIÓN

Una vez definido qué hay que hacer (análisis de los requisitos), se debe concretar cómo se va a hacer

(metodología), cuándo se va a hacer (estudiando los hitos y la disponibilidad) y con qué recursos se contará

para llevar a cabo las tareas (material). A partir de este momento estamos en disposición de organizar las

tareas y estimar su duración. El diagrama de Gantt muestra el tiempo de dedicación previsto para las

diferentes actividades a lo largo del tiempo de proyecto.

1.3.1 ANÁLISIS DE REQUISITOS

El enunciado del TFC (75132-TFC SIG 2011/2012 Semestre 2) es el documento de especificación de

requisitos, donde se describe cómo debe ser el producto de nuestro proyecto y qué se debe hacer.

1.3.2 METODOLOGÍA

La metodología de desarrollo se basa en un ciclo de vida en cascada, contemplándose dos fases diferenciadas:

Primera fase: investigación sobre plataformas de publicación geográfica en la nube, análisis técnico

comparativo de las diferentes plataformas, análisis de requisitos de un medio local y selección de una

plataforma idónea en base a los requisitos del cliente.

Segunda fase: diseño de prototipo para un medio informativo, implementación y pruebas; realización de

presentación multimedia ilustrando el trabajo del TFC y la memoria.

En el desarrollo del TFC tiene mucho más peso la primera fase que la segunda.

1.3.3 PLAZOS DE ENTREGA Y DISPONIBILIDAD

A continuación se describen las fechas de entrega y el calendario de trabajo. Se establecen las fases en que

está dividido el proyecto así como los hitos, que se corresponden principalmente con las entregas de parciales

y memoria final del proyecto y de sus borradores previos.

Tabla 1. Fases del proyecto e hitos

FASES HITOS NOMBRE FECHA DE ENTREGA

Hito I Entrega de borrador PEC1 9/03/2012

PEC 1. Plan de trabajo

Hito II Entrega de PEC 1 (Plan de Trabajo) 13/03/2012

Hito III Entrega de borrador PEC2 6/04/2012 PEC 2. Estudio de SIG y exploración de plataformas

Hito IV Entrega de PEC2 10/04/2012

Hito V Entrega de borrador PEC3 11/05/2012 PEC 3. Análisis de plataformas y selección para diseño de prototipo

Hito VI Entrega de PEC3 15/05/2012

Hito VII Entrega de borrador de la memoria 7/06/2012 PEC 4. Desarrollo de prototipo funcional y entrega final

Hito VIII Entrega final de la memoria 11/06/2012

Hito IX Debate virtual 29/06/2012

Teniendo en cuenta los hitos establecidos anteriormente (plazos de entrega), las especificaciones del proyecto,

las horas dedicadas a desempeñar el trabajo profesional y la conciliación de la vida familiar y laboral, una


Página 8 de 60

previsión razonable de tiempo de dedicación al proyecto son 18 horas a la semana, distribuidas de la siguiente

forma: De lunes a sábado: 3 horas al día. Domingos y festivos: descanso.

Ilustración 1. Calendario de trabajo

En el calendario aparecen en amarillo las fechas de inicio y fin de proyecto así como

los hitos, coincidentes con las fechas de entrega de las PECs y memoria final. En rojo

aparecen los domingos y festivos, días que se dedican en principio al descanso a no

ser que el desarrollo del proyecto se vea comprometido.

Se comienza la planificación con el inicio del proyecto (29 de febrero) y se acaba con

la entrega del mismo (11 de junio). Son 86 días laborables, que suman un total de

258 horas. El 29 de junio finaliza el debate virtual y con ello el TFC.

1.3.4 RECURSOS MATERIALES

Se indica a continuación el material necesario para llevar a cabo el proyecto.

Software:

- Programas de uso ofimático de MSOffice; en particular Word, Excel y PowerPoint. Acrobat Reader.

- Software de administración de proyectos OpenProj. Software de grabación de escritorio Camtasia.

- Visualizador Google Earth y Quantum GIS como software SIG libre.

- Sistemas operativos Windows XP/7. Navegadores Internet Explorer, Mozilla Firefox, Chrome, Opera, etc.

- Acceso a las plataformas en línea de publicación de información geográfica.

Hardware:

- Ordenador personal, portátil, tableta y móvil.

1.3.5 ORGANIZACIÓN DE TAREAS

A continuación se muestra la relación de todas las tareas llevadas a cabo durante el desarrollo del TFC, con

sus correspondientes fechas de actuación y duración en horas.

Tabla 2. Organización de tareas

Nº NOMBRE DE LA TAREA FECHA INICIO FECHA FIN

DURACIÓN (horas)

1 Plan de trabajo (PEC1) 29/02/2012 13/03/2012 36

1.1 Inicio PEC1 29/02/2012 29/02/2012 0

1.2 Descarga de documentación 29/02/2012 29/02/2012 1

1.3 Lectura de documentación 29/02/2012 02/03/2012 6

1.4 Buscar bibliografía 02/03/2012 03/03/2012 3

1.5 Redactar índice 03/03/2012 05/03/2012 3

1.6 Instalación de OpenProj 03/03/2012 03/03/2012 2

1.7 Planificar tareas con OpenProj 03/03/2012 08/03/2012 11

1.8 Redactar contenido 05/03/2012 08/03/2012 9

1.9 Entrega de borrador (hito I) 08/03/2012 08/03/2012 0

1.10 Corrección de borrador 09/03/2012 12/03/2012 7

1.11 Entrega de PEC1 (hito II) 13/03/2012 13/03/2012 0

2 Estudio de SIG y exploración de plataformas (PEC2) 13/03/2012 10/04/2012 72

2.1 Inicio de PEC2 13/03/2012 13/03/2012 0

2.2 Estudio de conceptos de SIG (SIG y Geotelemática, UOC) 13/03/2012 16/03/2012 8

2.3 Búsqueda de otros textos sobre SIG y Neogeografía 13/03/2012 16/03/2012 9

2.4 Lectura sobre mashups, computación en la nube 16/03/2012 20/03/2012 9

2.5 Explorar Quantum GIS con los conceptos aprendidos 21/03/2012 22/03/2012 5

2.6 Explorar exhaustivamente Google Earth 22/03/2012 24/03/2012 5


Página 9 de 60

2.7 Redacción de resumen sobre SIG y Neogeografía 24/03/2012 29/03/2012 11

2.8 Búsqueda de plataformas y de información básica sobre ellas 29/03/2012 02/04/2012 7

2.9 Elaboración de un catálogo de plataformas 02/04/2012 05/04/2012 9

2.10 Entrega de borrador (hito III) 06/04/2012 06/04/2012 0


2.12 Entrega de PEC2 (hito IV) 10/04/2012 10/04/2012 0

3 Análisis de plataformas y selección para diseño de prototipo (PEC3)

10/04/2012 15/05/2012 81

3.1 Inicio de PEC3 10/04/2012 10/04/2012 0

3.2 Análisis de necesidades del medio informativo 10/04/2012 12/04/2012 6

3.3 Establecimiento de criterios de comparación de plataformas 12/04/2012 13/04/2012 5

3.4 Estructuración de una tabla comparativa exhaustiva 12/04/2012 13/04/2012 6

3.5 Búsqueda y/o elaboración de datos geográf. y mapas de prueba 13/04/2012 14/04/2012 4

3.6 Para cada plataforma 16/04/2012 01/05/2012 37

3.6.1 Alta de usuario en la plataforma, y configuración inicial 16/04/2012 16/04/2012 1

3.6.2 Prueba detallada de la plataforma 16/04/2012 27/04/2012 27

3.6.3 Vías de carga de datos, opciones capas base 16/04/2012 27/04/2012 27

3.6.4 Funcionalidades, usabilidad, estilo y representación 16/04/2012 27/04/2012 27

3.6.5 Difusión en redes sociales, seguridad y estándares 16/04/2012 27/04/2012 27

3.6.6 Interoperabilidad y rendimiento 16/04/2012 27/04/2012 27

3.6.7 Capacidades multiplataforma y multidispositivo 16/04/2012 27/04/2012 27

3.6.8 Posibilidades de programación y tecnologías subyacentes 16/04/2012 27/04/2012 27

3.6.9 Modelo de negocio 16/04/2012 27/04/2012 27

3.7 Redacción ilustrada de características de cada plataforma 27/04/2012 01/05/2012 9

3.8 Recogida de características en la tabla comparativa 27/04/2012 01/05/2012 9

3.9 Elección de una plataforma y exposición de motivos 02/05/2012 03/05/2012 6

3.10 Descripción del uso de la plataforma en la organización 04/05/2012 05/05/2012 5

3.11 Pasos a seguir para la implantación 07/05/2012 09/05/2012 6

3.12 Diseño de un primer prototipo 10/05/2012 14/05/2012 9

3.12.1 Alta y configuración de un blog en WordPress.com 10/05/2012 10/05/2012 2

3.12.2 Confección de secciones con noticias, eventos, avisos… 10/05/2012 12/05/2012 6

3.12.3 Incorporación de entradas con mapas elaborados 10/05/2012 14/05/2012 7

3.13 Entrega de borrador (hito V) 11/05/2012 11/05/2012 1


3.15 Entrega de PEC3 (hito VI) 15/05/2012 15/05/2012 0

4 Entrega final (PEC4) 15/05/2012 11/06/2012 69

4.1 Inicio de PEC4 15/05/2012 15/05/2012 0

4.2 Desarrollo de prototipo funcional 15/05/2012 18/05/2012 9

4.3 Preparación de la memoria 19/05/2012 31/05/2012 27

4.3.1 Elaboración de un listado de problemas encontrados 19/05/2012 22/05/2012 7

4.3.2 Enumeración de posibilidades de mejora futuras 19/05/2012 22/05/2012 7

4.3.3 Revisión e integración de contenidos de las PECs 22/05/2012 24/05/2012 6

4.3.4 Integración, rotulación e índices de figuras y tablas 24/05/2012 25/05/2012 3

4.3.5 Redacción de conclusiones y apartados finales 26/05/2012 29/05/2012 8

4.3.6 Revisión de sintaxis y ortografía 30/05/2012 31/05/2012 3

4.4 Preparación de una presentación multimedia 31/05/2012 08/06/2012 21

4.4.1 Instalación de software de grabación de escritorio 31/05/2012 01/06/2012 3

4.4.2 Recopilación de imágenes, audio y capturas de pantalla 31/05/2012 02/06/2012 8

4.4.3 Elección de plantilla, fondos, colores, tipografía, etc. 31/05/2012 02/06/2012 8

4.4.4 Confección de la presentación de vídeo 04/06/2012 05/06/2012 3

4.4.5 Grabación de la pista de audio con narrativa y música 05/06/2012 06/06/2012 3

4.5 Entrega de borrador (hito VII) 07/06/2012 07/06/2012 1


4.7 Entrega de PEC4 (hito VIII) 11/06/2012 11/06/2012 0

5 Debate virtual (Tribunal del TFC) 27/06/2012 29/06/2012 6


Página 10 de 60

1.3.6 DIAGRAMAS DE GANTT

A continuación se muestran los diagramas de Gantt, que tienen como objetivo mostrar el tiempo de dedicación

previsto para las diferentes tareas o actividades que finalizan con la entrega del TFC.

Ilustración 2. Gantt. Fases 1 y 2. PEC1 y PEC2.

Ilustración 3. Gantt. Fase 3. PEC3

Ilustración 4. Gantt. Fase 4. Entrega final


Página 11 de 60

1.4 PRODUCTOS OBTENIDOS

Los entregables del TFC, una vez finalizado el trabajo, son los siguientes:

1.4.1 MEMORIA DEL TFC

Un documento de síntesis de 60 páginas (el presente documento), cumpliendo los objetivos marcados, y

estructurado de la siguiente forma:

Capítulo Título del apartado Objetivos Nº de páginas

Portada, Resumen e Índice No aplicable 4

1 Introducción E1 7

2 Los Sistemas de Información Geográfica G1,G2 6

3 La Neogeografía G1 3

4 La Computación en la nube G3 5

5 Plataformas para la publicación de información geográfica E2,E3 26

6 SIG tradicional vs SIG en la nube G1,G2,G3,G4 1

7 Caso de estudio y prototipo G4,E3,E4 5

8, 9 Líneas de continuación y Conclusiones finales G4,E3 1

10,11 Glosario y Referencias bibliográficas No aplicable 2

1.4.2 PRESENTACIÓN MULTIMEDIA

Una presentación en vídeo, publicada en el espacio Presenta, con sonido integrado y duración aproximada de

20 minutos sobre la presente memoria, donde se ilustran los conceptos aprendidos a lo largo del TFC y se

explica el funcionamiento y características de las plataformas analizadas y del prototipo implementado.

1.4.3 PROTOTIPO

Un blog realizado en Blogger.com, con noticias geolocalizadas referentes a un municipio, alojado en la

siguiente dirección: www.tierraynube.blogspot.com.


Página 12 de 60

2 LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA

“Los Sistemas de Información Geográfica ofrecen numerosas ventajas respecto a la cartografía convencional,

puesto que de forma automática permiten manejar datos espaciales internamente referenciados, producir

mapas temáticos y realizar procesos de información de tipo digital” (Conesa García, 1996).

2.1 UN INTENTO DE DEFINICIÓN

“Se puede afirmar que hay casi tantas definiciones como autores que escriben sobre el mundo del SIG”

(Gutiérrez Puebla y Gould. 1994).

Dependiendo del contexto en que los utilicemos, nos sentiremos más identificadas con unas u otras. Así,

mientras que para algunos los SIG son simplemente el medio para automatizar la producción de mapas, para

otros esta aplicación parece banal en comparación con su complejidad asociada a la solución de problemas

geográficos y el soporte a la toma de decisiones (Longley, 2005).

Dos de las definiciones más acordes a lo que actualmente se reconoce como un SIG, pueden ser las

siguientes, ordenadas cronológicamente:

“Sistema de hardware, software y procedimientos elaborados para facilitar la obtención, gestión,

manipulación, análisis, modelado, representación y salida de datos espacialmente referenciados, para resolver

problemas complejos de planificación y gestión.” (National Center for Geographic Information and Análisis,

1990)

“Conjunto integrado de medios y métodos informáticos, capaz de recoger, verificar, intercambiar, almacenar,

gestionar, actualizar, manipular, recuperar, transformar, analizar y mostrar datos espaciales referenciados a la

Tierra.” (Rodríguez Pascual, 1993).

En definitiva, podemos concluir que un sistema de información geográfica es un sistema que integra

hardware, software y datos para capturar, administrar, analizar y mostrar todas las formas de

información geográficamente referenciada. Los SIG nos permiten ver, comprender, cuestionar,

interpretar y visualizar los datos de muchas maneras revelando relaciones, patrones y tendencias en forma de

mapas, informes y gráficos.

2.2 HISTORIA DE SU DESARROLLO

El origen de los SIG se remonta a 1960, cuando un grupo de especialistas procesan volúmenes

considerables de datos geográficos para diferentes propósitos; desarrollan prototipos de SIG para generar e

imprimir mapas que funcionan en grandes equipos y precisan un gran número de instrucciones manuales.

En 1970 se afianza la denominación "Sistemas de Información Geográfica" y comienza su auge, dada su gran

capacidad para abordar problemas prácticos. En 1978 se pone en órbita el primer satélite GPS (Global

Positioning System - Sistemas de Posicionamiento Global)

Durante la década de los ochenta, aparecen avances técnicos en la captura, cuya expresión más

importante son los datos de teledetección por satélite y los de GPS, y en la visualización, gracias a periféricos

más precisos y veloces. También se gana velocidad y precisión en los procesos de cálculo, debido a los

avances en hardware y a la depuración de algoritmos.


Página 13 de 60

En los años 90, la tecnología SIG ofrece ya muchas soluciones para la gestión de datos geográficos, aunque

con algunas debilidades: los datos eran costosos, las fuentes de información eran desconocidas y a veces

inaccesibles, y los modelos y formatos físicos poco normalizados. Estas debilidades se vieron atenuadas en

1994 gracias a la aplicación de la filosofía de los sistemas abiertos a los SIG, impulsada por las

especificaciones definidas por el OGC. A finales de esta década se inicia la revolución de los SIG en red

(primero en intranets corporativas y posteriormente en Internet).

A partir del año 2000 entramos en la era de la explotación. El fuerte desarrollo de las tecnologías de la

información, Internet, las tecnologías móviles y los sistemas de posicionamiento, propician la expansión del

software SIG, la demanda de datos cartográficos y los servicios basados en la localización.

Los SIG evolucionan hacia la Web 2.0. Se empieza a hablar de las Arquitecturas Orientadas a Servicios (SOA),

mashups, Web 2.0 y de sindicación de servicios (posibilidad de que un servicio trabaje con la información de

otros servidores).

En la actualidad las tendencias que marcan el mundo SIG se sitúan en el entorno del Cloud Computing,

poniendo la información geográfica al alcance de los usuarios. Tanto la arquitectura, como las soluciones se

están basando en este modelo. Como ejemplo de esta tendencia podemos destacar la reciente inmersión de

Esri (Enviromental Systems Research Institute) en la “nube informática”, montando su ArcGIS como una

aplicación online, para que el usuario comparta cartografía y aplicaciones sobre múltiples plataformas.

2.3 UTILIDADES DE LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA

Los Sistemas de Información Geográfica surgen como una necesidad de conseguir mayor y mejor información

para facilitar la toma de decisiones; es por ello que las temáticas que pueden abordar están relacionadas

siempre con una necesidad de gestión.

La tecnología de estos sistemas puede ser utilizada en multitud de investigaciones científicas, evaluaciones de

impacto ambiental, emergencias y planes de contingencia por desastres, planificación urbana, arqueología,

cartografía, sociología, marketing, logística, gestión de recursos naturales, gestión de activos, entre otras.

2.4 FUNCIONAMIENTO DE LOS SIG. DESCRIPCIÓN TÉCNICA

Las funciones básicas de un Sistema de Información Geográfica son tres:

1. editar datos geográficos, pudiendo añadir, modificar o eliminar elementos geográficos, para lo cual el

sistema ha de ser capaz también de cargarlos desde ficheros en formatos de uso común, como los llamados

"shapefiles" o los ficheros KML. También ha de ser capaz de representarlos gráficamente en forma de

mapas, y de almacenar de nuevo la información geográfica seleccionada para su uso posterior o para su uso

en otros sistemas.

2. vincular datos de distinta índole y de diversas fuentes, por ejemplo provenientes de bases de datos, con

elementos geográficos mediante georreferenciación, que consiste en asociar datos no espaciales con

elementos geográficos, (posiciones, líneas o áreas) de forma que queden integrados en un mapa y puedan

ser representados conjuntamente con el resto de información geográfica de la misma zona.

3. analizar datos geográficos o georreferenciados, es decir, procesar la información geográfica y los

datos asociados a ella mediante algoritmos de cálculo implementados en el sistema, obteniendo como

resultado nuevos datos, geográficos o no, que a su vez podrán representarse y almacenarse.


Página 14 de 60

A éstas hay que añadir una funcionalidad que no era básica en principio, pero que cada día adquiere mayor

importancia, que es la publicación de información geográfica. No era básica porque en las décadas

anteriores no se solían usar los SIG con el fin de publicar, y menos mediante sitios web, sino que el resultado

del uso de SIG era mayoritariamente destinado a entregar a un cliente o a uso propio interno de una

organización.

Estas funciones han ido cambiando en forma con el uso intensivo de Internet. Originalmente estaban

restringidas a funcionar sobre una misma máquina, o en todo caso en máquinas estrechamente unidas

mediante una red local. Pero hoy en día es posible y relativamente frecuente que, respecto al primer punto, la

carga de información geográfica se haga desde servidores web, especialmente para obtener las llamadas

«capas base», que son las que definen el mapa sobre el que se van a representar, el resto de datos.

Respecto al segundo punto, también los datos no espaciales pueden tomarse de bases de datos remotas,

incluso desde distintos servidores no relacionados entre si.

Y con la llegada de la computación en la nube, la tercera función también es posible realizarla en equipos

externos, quedando la máquina local en ese caso solo para la representación de datos y mapas y para la

gestión del resto de funcionalidades mediante un panel de control consistente en menús, barras de

herramientas y ventanas de diálogo dentro de un navegador web.

A continuación se detalla la forma en que cada una de esas funcionalidades básicas se implementa y usa en

un SIG típico, como es Quantum GIS, con vistas a entender posteriormente la evolución hacia sistemas en que

tanto los datos como los procesos están distribuidos en nubes de computadores conectadas a la red global,

como son las plataformas web que se analizarán en este estudio.

2.4.1 CARGA, EDICIÓN, VISUALIZACIÓN Y ALMACENAMIENTO DE DATOS GEOGRÁFICOS

Hay dos aspectos importantes a destacar en este apartado, que son los diferentes sistemas de coordenadas y

proyecciones geométricas de la superficie de la tierra sobre un plano, y los dos tipos fundamentales de

almacenamiento y tratamiento de datos geográficos: raster y vectorial.

2.4.1.1 Sistemas de referencia espacial

La superficie de la tierra tiene forma elipsoidal, casi esférica pero un poco achatada, mientras que cualquier

representación de datos geográficos sobre una pantalla o una lámina es plana. La representación en un plano,

por tanto, nunca puede ser exactamente proporcional a la superficie real representada. La representación

plana de un trozo de superficie terrestre se llama proyección, y la relación entre la superficie real y su

representación se llama sistema de proyección.

Son posibles distintos criterios que dan lugar a distintos sistemas de proyección. A ello se añade que las

coordenadas con las que se identifica un punto en una proyección pueden tener distinto origen de

coordenadas y estar en diferentes unidades, existiendo también variedad de sistemas de coordenadas según

los países y organizaciones que los definan. Debido a ello, la variedad de sistemas de coordenadas usados es

enorme, y se hace necesario definirlos con rigor y transformar datos geográficos de unos a otros. Un sistema

de coordenadas, estándar y muy extendido, es el Universal Transverse Mercator (UTM).

Al conjunto de un sistema de proyección, un sistema de coordenadas y sus relaciones de transformación se le

llama sistema de referencia espacial, o sistema de referencia de coordenadas. El sistema de referencia

espacial que se ha convertido en el estándar mas usado es el WGS 84 (World Geodetic System 1984).


Página 15 de 60

Es importante conocer esto porque es lo primero que pide una aplicación como Quantum GIS cuando se quiere

crear una capa nueva.

2.4.1.2 Datos vectoriales y raster: capas y formatos de ficheros

La información geográfica en un SIG se estructura en capas, que son agrupaciones de elementos geográficos o

de atributos (descritos mas adelante) que se muestran u ocultan todos de una vez en un mapa. Pueden

mostrarse por encima o por debajo de otras capas (las inferiores quedan enmascaradas por las superiores), o

seleccionarse para ser usadas en un análisis. De esta forma se pueden agrupar elementos para definir, por

ejemplo, solo las calles de una población, o solo la red de tendido eléctrico, o solo las parcelas, etc., y

tratarlas como un solo elemento compuesto. Las capas han de ser raster o vectoriales, no pueden mezclarse

ambos tipos en una misma capa.

Hay dos formas posibles de representar y almacenar objetos geográficos en un plano.

a) La representación raster consiste en dividir el espacio plano en una cuadrícula, con un tamaño de celda a

elegir según la precisión que se requiera, y asignar a cada celdilla de esa cuadrícula un valor que defina

una propiedad del objeto a representar en esa posición. Por ejemplo, si se trata de representar una

carretera, se puede definir una cuadrícula con celdas de tamaño del orden de la anchura de la carretera, y

a cada celda por la que pase la carretera se

le asigna el valor 1, y al resto 0. Un

ejemplo típico y muy usado de datos en

formato raster son las fotografías aéreas y

de satélite.

b) En la representación vectorial, los

elementos geográficos básicos son de tres

tipos: puntos, líneas y polígonos (cerrados),

que son elementos de dimensión cero, uno

y dos respectivamente. Con ellos se puede

definir todo tipo de elementos más

complejos.

Ilustración 5. Diferencia entre un modelo vectorial y un modelo raster

Fuente: http://www.aulati.net/?tag=bases-de-datos-geograficas

Un elemento geográfico básico, ya sea una celda raster o un punto, línea o polígono vectorial, es

conceptualmente un registro en una base de datos. Si a ese registro se le añade o asocia un campo de

información no espacial, ese campo se llama atributo. Lo que representa ese atributo se llama tema, y como

puede ser representado sobre un mapa por estar asociado a elementos geográficos, al mapa resultante se le

llama mapa temático.

Las capas raster pueden almacenarse en formatos de fichero similares a los de imágenes de mapas de bits

pero que añaden información de georreferenciación, como GeoTIFF, basado en TIFF, y JPEG2000, basado en

JPEG, o formatos propietarios como MrSID o Esri grid. Si incluyen información de elevación en cada celda

hay otros formatos mas adecuados, como DEM (Digital Elevation Model).

Entre los formatos de almacenamiento vectorial, que son bastantes, merecen citarse Esri shapefile (SHP), que

es uno de los mas usados, KML, usado por Google Earth pero ahora estandarizado y muy popular para mapas

destinados a publicación por web, GML, estándar de OpenGIS basado en XML, y AutoCAD DXF, que no es


Página 16 de 60

originalmente un formato para SIG sino que es el formato nativo de AutoCAD, pero ha sido bastante usado

para intercambio de datos geográficos vectoriales.

2.4.2 ANÁLISIS ESPACIAL

Los procesos de análisis que se pueden realizar sobre información geográfica son muy amplios, pues el límite

es solo la capacidad de los programadores y la de computación de las máquinas. Pero hay algunas

necesidades de análisis que son más habituales y por eso se suelen incluir en los SIG avanzados.

Por ejemplo, si se dispone de la información de elevación de los puntos de un terreno (DEM o TIN) se puede

calcular la pendiente y la curvatura de cada punto, e incluso añadir sombreado y brillo mediante técnicas de

trazado de rayos. Si se dispone de alguna magnitud distribuida de forma continua sobre la superficie del

terreno, como puede ser la información de temperatura máxima o mínima de un período, se puede obtener un

mapa de contorno que represente las curvas con igual magnitud, y si además se dispone de esa información

en distintos períodos se puede obtener una secuencia animada de la evolución de los datos.

Se pueden calcular y representar qué elementos son adyacentes, cuáles contienen a otros, cuáles se

intersectan, o las distancias entre ellos. Se puede realizar un modelado de una red para optimizar, por

ejemplo, la distribución de electricidad en una urbanización. Igualmente, el modelado hidrológico es

importante para obtener direcciones de flujo y zonas de acumulación de cuencas, por ejemplo para

investigaciones de contaminación o de impacto ambiental.

Se pueden obtener nuevas capas vectoriales como superposición de varias capas obtenidas por diferentes

fuentes. Los datos no espaciales pueden ser procesados para estadísticas por zonas. Se pueden obtener

coordenadas geográficas a partir de direcciones postales, lo que se llama geocodificación, o viceversa.

Si se quiere realizar algún análisis no contemplado en las opciones de menú de un SIG se puede acudir al SDK

(Software Development Kit) correspondiente, que casi todos los sistemas SIG proveen alguno, y programar

uno mismo los algoritmos que necesite.

2.4.3 PUBLICACIÓN EN INTERNET, SERVIDORES DE MAPAS

Una capacidad de los SIG que cada vez adquiere mayor importancia es la preparación de datos geográficos

para producir mapas interactivos con el objeto de ser publicados en Internet. Un caso típico hoy en día es la

ayuda visual de una noticia o serie de noticias mediante la información mostrada en un mapa.

Podemos pensar, por ejemplo, en ilustrar el historial de las revueltas de la llamada Primavera Árabe de 2011

por países, representando sobre el mapa las fechas, el impacto económico, número de víctimas, y días de

duración en cada país o ciudad. Se esquematiza a continuación cómo se realizaría ese trabajo con Quantum

GIS, también llamado QGIS por brevedad, que se puede considerar un SIG tradicional, por contraposición a

las plataformas de publicación en la nube. De esta forma sirve como compendio de la operativa de un SIG y

como descripción de QGIS.

Quantum GIS, fue uno de los primeros ocho proyectos de la Fundación OSGeo. Es una aplicación de

escritorio de código abierto que intenta proporcionar posibilidades que anteriormente solo se encontraban en

aplicaciones comerciales de código cerrado, como ESRI ArcMAP o InteGraph GeoMedia.

En el afán de los diseñadores de QGIS por abarcar todas las funcionalidades posibles, QGIS incluye

características de cliente y de servidor. De hecho, existen cuatro aplicaciones QGIS:


Página 17 de 60

� QGIS Browser: es, como su nombre indica, un visualizador de datos geográficos, pero puede tomar esos

datos de lamáquina local, de otra máquina en la red local, o de un servidor WMS de Internet.

� QGIS Desktop: esta es la aplicación que normalmente se entiende por QGIS si no se especifica mas,

incluye las capacidades del visualizador, pero además se pueden editar los datos geográficos y modos de

presentación, así como realizar análisis avanzados.

� QGIS Server: es un servidor de datos geográficos que cumple con el estándar WMS 1.3, y puede ser

configurado mediante ficheros de proyecto de QGIS Desktop.

� QGIS Client: es un navegador de mapas basado en OpenLayers y GeoExt

Para el propósito planteado utilizaríamos QGIS Desktop para la preparación de los datos y QGIS Server para

su publicación. No necesitamos QGIS Browser porque sus funciones están incluidas en la versión Desktop. En

cambio, sí que podemos usar QGIS Client como sistema para comprobar el resultado publicado.

En primer lugar, buscamos en Internet un fichero con la geografía básica del norte de África, al menos con la

delimitación de fronteras y las ciudades principales. Lo cargamos en QGIS mediante la opción de menú Añadir

capa vectorial. Una vez cargado podemos cambiar las propiedades de esa capa, como colores o grosores de

líneas.

También podemos editar los atributos en forma de tabla, y añadir a cada país los datos que queremos,

obtenidos mediante otras fuentes, como hemerotecas de periódicos. O bien podemos preparar esos datos

como fichero CSV a partir de una hoja de cálculo e importarla a QGIS, teniendo cuidado previamente de que el

identificador de cada dato coincida con el del país correspondiente en los atributos geográficos.

Una vez unidos los nuevos datos a los datos geográficos de cada país afectado, modificamos las propiedades

de atributos para elegir la forma en que queremos representar esos datos en el mapa: símbolo, color, modo,

etc., hay mucha variedad de posibilidades.

Después de alguna operación como la de simplificación de datos, o algún análisis que creamos conveniente,

tendríamos el mapa preparado para publicación. Entonces simplemente bastaría con guardar el proyecto y

cargarlo en QGIS Server. Al ser dos componentes del mismo proyecto de código abierto QGIS, el formato de

almacenamiento que usan es el mismo, por lo que no hay que preocuparse por problemas de exportación e

importación de datos. Previamente debemos tener QGIS Server instalado en un servidor web Apache, pues

normalmente se ejecuta como un módulo CGI/FastCGI de éste. El mapa resultante publicado debería tener la

misma apariencia que en QGIS Desktop. Para comprobar que está correctamente publicado podemos usar

QGIS Client, y de esta forma habremos usado las distintas herramientas de QGIS para nuestro proyecto de

publicación web.


Página 18 de 60

3 LA NEOGEOGRAFÍA

En un intento de identificar el nuevo fenómeno social en el que personas sin experiencia cartográfica

participan en el significado y creación de mapas, se han acuñado varias denominaciones.

Destacan entre éstas las siguientes: Neogeografía (Turner: 2006), Digiplace (Zook y Graham: 2007), VGI

(Goodchild: 2007) y Where 2.0 (Seokchan: 2007).

Probablemente esta diversidad de enfoques se deba al hecho de que la geografía, a diferencia de otras

disciplinas, posee una dimensión práctica, cotidiana y local que la hace mucho más cercana. En cierto sentido

y a lo largo de nuestra vida, todos somos geógrafos y este conocimiento se modifica a partir de nuestras

experiencias espaciales.

De entre todas las denominaciones nos quedaremos con la de Neogeografía, siguiendo la definición de

Turner (2006):

“Neogeography means “new geography” and consists of a set of techniques and tools that fall outside

the realm of traditional GIS, Geographic Information Systems. Where historically a profesional

cartographer might use ArcGIS, talk of Mercator versus Mollweide projections, and resolve land area

disputes, a neogeographer uses mapping API like Google Maps, talks about GPX versus KML, and

geotags his photos to make a map of his summer vacation”.

La Neogeografía define una nueva etapa de la geografía, en la cual deja de ser especialidad de geógrafos

usuarios de SIG, para dar paso a una disponibilidad abierta de tecnología de construcción de mapas basadas

en el usuario no experto. Comenzó como una expresión de la Web 2.0 aplicada a los mapas.

En definitiva, combina las técnicas complejas de los SIG y las pone al alcance tanto de desarrolladores como

de usuarios finales. De alguna manera se está hablando de la socialización de la geografía, a partir de dos

hechos fundamentales: la construcción de mapas está al alcance de cualquier usuario con mínima práctica en

el manejo de herramientas de publicación digital y por otra parte, millones de personas pueden acceder a la

información y a los servicios.

3.1 LA SOCIALIZACIÓN DE LOS MEDIOS DE PRODUCCIÓN DE

INFORMACIÓN GEOGRÁFICA

Entre los hitos que más han contribuido a este proceso de socialización podemos destacar la liberalización de

la API de Google Maps, complementándose con iniciativas de software libre en materia de SIG y el desarrollo y

abaratamiento de la tecnología GPS, que ha podido ser integrada o conectada a los más diversos dispositivos.

3.1.1 LA NUEVA CARTOGRAFÍA. LAS APIS DE SERVICIOS GEOGRÁFICOS

Google pone a disposición de la comunidad de Internet un servicio de mapas online (Google Maps) y lo abre a

través de APIs para que cualquier usuario pueda desarrollar aplicaciones sobre él.

El lanzamiento de Google Maps y Google Earth supone un punto de inflexión en la capacidad de acceso y

manipulación de información geográfica por parte de los usuarios y simbolizan la “liberación” de una serie de

prácticas y actividades que, por diversos motivos, habían permanecido históricamente accesibles tan sólo a

colectivos reducidos en el ámbito profesional.


Página 19 de 60

De este modo el número de personas interesadas en Google Maps supera el de personas interesadas en los

SIG por lo que comienza una transformación de las prácticas cartográficas y de la geografía en general.

3.1.2 SERVICIOS WEB OGC

El Open Geospatial Consortium (OGC), creado en 1994, agrupa más de 300 organizaciones públicas y

privadas. Su objetivo es la definición de estándares abiertos e interoperables dentro de los Sistemas de

Información Geográfica y de la World Wide Web. Persigue acuerdos entre las diferentes empresas del sector

que posibiliten la interoperación de sus sistemas de geoprocesamiento para facilitar el intercambio de la

información geográfica en beneficio de los usuarios. Las especificaciones más importantes surgidas del OGC

son las siguientes: GML (Geography Markup Language), KML (Keyhole Markup Language), WFS (Web

Feature Service), WMS (Web Map Service), WCS (Web Coverage Service) y CSW (Web Catalogue Service).

3.1.3 EL DESARROLLO DE LA TECNOLOGÍA GPS

Una de las claves para entender cómo un grupo de usuarios inexpertos ha llegado a reemplazar en ocasiones

a profesionales especializados es la generalización del uso del los navegadores GPS y de otros

dispositivos con posicionadores, como los «smartphones». Aunque su uso requiere algunas habilidades,

cualquier usuario puede sacarle provecho sin conocimiento alguno de la compleja geometría que lo compone.

3.1.4 LA DISPONIBILIDAD DE DATOS GEOGRÁFICOS GLOBALES

Debido a la popularización de los dispositivos GPS, se ha hecho imprescindible la disponibilidad de datos

geográficos, especialmente de comunicaciones por carretera.

En este aspecto dos empresas han liderado el mercado, y son hoy en día los mayores proveedores de

información geográfica asequible a escala mundial: Navteq y TeleAtlas. La primera fue adquirida por Nokia en

2007, y la segunda por Tomtom un año después, aunque ambas funcionan de forma independiente. Además

de proveer datos para la mayoría de navegadores GPS, también son los principales proveedores de datos para

servicios web de mapas.

Basándose en la tecnología GPS –hoy democratizada- muchas comunidades de “neogeógrafos” han construido

cartografías con precisión geométrica parecida a la cartografía comercial. Entre las bases cartográficas creadas

de forma colaborativa y disponibles libre y gratuitamente destacan OpenStreetMap y Wikiloc.

3.2 LA WEB 2.0. DISTRIBUIDA, ABIERTA Y COLABORATIVA

Con este término, acuñado por O'Reilly Media en 2004, se describe el fenómeno social surgido a partir del

desarrollo de diversas aplicaciones en Internet. Así se establece una distinción entre la primera época de la

Web (donde el usuario era un sujeto pasivo que recibía la información o la publicaba, sin posibilidad de

interacción) y la revolución que supuso el auge de blogs, redes sociales y otras herramientas permitiendo a los

usuarios interactuar y colaborar entre sí como creadores de contenido en una comunidad virtual.

Podemos decir que la Web 2.0 es soportada fundamentalmente por cuatro estructuras:

- Los contenidos: herramientas que favorecen la lectura y escritura en línea.

- Las redes sociales: motor de comunicación mediante la Web. Desde hace un tiempo la Web 2.0 ha

tomado el control de Internet como lo demuestran redes sociales como Twitter, Tuenti, Facebook y otras

tantas que cuentan con miles de usuarios. En los últimos años se han popularizado distintas aplicaciones

que nos permiten compartir con nuestros conocidos fotos y vídeos (como "Google Latitude”, "Foursquare",


Página 20 de 60

o "lugares de Facebook"), además de facilitarles la información sobre el lugar geográfico en el que se han

obtenido estos documentos.

- La organización social e inteligente de la información: permitiendo el orden y almacenamiento de la

información con el fin de ser gestionada de forma más dinámica.

- Las aplicaciones y servicios (mashups): recursos creados para ofrecer servicios de valor añadido a los

usuarios. De su definición y su creación

3.3 LOS MASHUPS, APRENDER COMPARTIENDO

Se entiende por mashup una aplicación web híbrida que combina componentes y datos de más de una

fuente para crear un nuevo servicio. Por ello sus principales características son la combinación, la visualización

y la agregación.

Existen mashups de múltiples servicios: de mapas (Google Maps), de fotos (Flickr), de compras (Amazon), de

videos (Youtube), etc.

3.3.1 CREACIÓN DE UN MASHUP

Para crear un mashup básicamente se debe integrar los servicios web desarrollados y ofertados por empresas

u organismos, con desarrollos propios (programación) u otras herramientas.

Los servicios ofertados por terceros tienen normalmente un carácter general; gracias a los mashups podremos

obtener un producto con unos fines más concretos o específicos.

Una vez se acceda mediante el navegador, el resultado final es un producto fácil de usar y de carácter

práctico.

Los formatos habituales de origen de datos utilizados como fuente en los servicios web son RSS (Really

Simple Syndication), JSON (JavaScript Object Notation) o XML (eXtensible Markup Language) entre otros.

Para la programación lo más habitual es el uso de código web estándar HTML con abundancia de código

JavaScript incrustado.

Para que sea factible esta transferencia de información entre ambas plataformas es necesaria una

intercomunicación que se consigue gracias a las APIs

(Application Programming Interface). Este conjunto de

funciones y métodos permiten al programador de mashups

integrar ambas fuentes para obtener el producto deseado. El

resultado es interesante que pueda ser visualizado por la

mayoría de navegadores y en diferentes dispositivos

(sobremesa y móviles).

Tecnologías como AJAX (Asynchronous Javascript and XML),

disponibles ya en todos los navegadores, facilitan la

interoperabilidad. En la figura adjunta podemos ver las

diferencias entre un modelo de aplicación web clásico y un

modelo de aplicación web basado en Ajax.

Ilustración 6. Modelos de aplicación web

Fuente: www.maestrosdelweb.com


Página 21 de 60

4 LA COMPUTACIÓN EN LA NUBE

Este término se utiliza para designar un sistema informático basado en Internet y centros de datos remotos

con objeto de gestionar servicios de información y aplicaciones. La palabra “nube” se utiliza como una

metáfora de Internet (nube utilizada para representarla en los diagramas de red).

La computación en nube permite que los usuarios gestionen archivos y utilicen aplicaciones sin necesidad de

instalarlas en un servidor propio. Entre las ventajas de esta tecnología podemos destacar un uso mucho más

eficiente de almacenamiento, memoria, procesamiento y ancho de banda, al proveer solamente los recursos

necesarios en cada momento.

4.1 MODELO DE SERVICIO

La nube es un nuevo modelo para suministrar y consumir recursos de tecnologías de la información, como por

ejemplo recursos de computación, almacenamiento de datos, ancho de banda de red o, incluso, aplicaciones.

Este modelo incluye características como autoservicio bajo demanda, una rápida elasticidad, un servicio

medible (pago por uso), niveles de acuerdo de servicio, agrupación de recursos y amplio acceso a red. En este

modelo se delega en el proveedor de servicios de la nube aspectos delicados como la custodia, backup y

seguridad de la información, con sus ventajas e inconvenientes (recientemente Megaupload cerró por

problemas legales, quedando muchos terabytes de información “secuestrados” judicialmente).

Las aplicaciones de computación en la nube se componen de una serie de capas sobre las que se alojan

recursos distribuidos.

− SAAS. El software como servicio (Software as a Service) se encuentra en la capa más alta. Es un

modelo de distribución de software donde una empresa sirve el mantenimiento, soporte y operación que

usará el cliente durante el tiempo que haya

contratado el servicio.

− PAAS. La capa del medio es la plataforma como

servicio (Platform as a service). Es un modelo en

el que se ofrece todo lo necesario para soportar el

ciclo de vida completo de construcción y puesta en

marcha de aplicaciones y servicios web

completamente disponibles en Internet.

− IAAS. La infraestructura como servicio

(Infrastructure as a Service) se encuentra en la

capa inferior. Es un medio de computación en la

nube en el que el hardware está virtualizado. El

proveedor de servicio posee el equipamiento y el

desarrollador usa hardware virtual sobre el que crea

aplicaciones y servicios.

Ilustración 7. La computación en la nube

Fuente: http://dtechnocrat.blogspot.com.es/


Página 22 de 60

La Computación en la nube en el mundo SIG propicia la aparición de múltiples plataformas que permiten el

almacenamiento y publicación de información geográfica. Sus funcionalidades son analizadas en el siguiente

apartado.

4.2 PLATAFORMAS EN LA NUBE. FUNCIONALIDADES BÁSICAS.

Las plataformas colaborativas para el tratamiento de datos espaciales se sustentan fundamentalmente en

tres funcionalidades básicas: publicar, organizar y compartir la información que desarrollamos a

continuación. A estas funcionalidades podemos añadir otras secundarias como evaluar, comentar, responder,

enviar, etc.

Publicar. Una de las claves para entender los beneficios de la Neogeografía es la facilidad de publicación que

ofrecen las plataformas colaborativas. Publicar mapas es tan fácil como publicar artículos o fotos. En este

momento se dispone de la tecnología precisa para subir datos geográficos masivos a los servidores, desde

donde podrán ser consultados. Ocasionalmente pueden ser datos capturados con GPS por usuarios

individuales, aunque también pueden ser datos públicos o digitalizados a partir de fuentes públicas. En esta

línea, OpenStreetMap o Wikiloc permiten publicar rutas desde dispositivos GPS (waypoints) a una base de

datos común. Además de estos waypoints, esta función se puede extender a otros tipos de formatos abiertos,

como KML, CSV, SHP, etc.

Organizar. La clasificación de los datos mediante etiquetados no jerárquicos definidos por los usuarios de las

plataformas permite establecer vínculos al nivel de metadatos, conectando a los interesados en los mismos

temas y facilitando la labor de búsqueda de los mapas publicados.

Compartir. Otra función habitual en las plataformas online es la posibilidad de compartir los contenidos

publicados incrustándolos dentro de otras páginas o de servicios de valor añadido con código HTML, plugins,

etc. Por ejemplo para insertar un mapa de Google Maps en WordPress.com, debemos entrar en la dirección de

Google Maps en inglés, buscar la ubicación que queramos, pulsar en el enlace y copiar el HTML proporcionado

para posteriormente pegarlo en nuestro editor, en la pestaña HTML.

4.3 PLATAFORMAS DE PUBLICACIÓN DE INFORMACIÓN GEOGRÁFICA.

LISTA DE ASPECTOS A EVALUAR

En esta sección se describen brevemente las características técnicas que analizaremos para cada una de las

plataformas de publicación de información geográfica, como paso previo al análisis detallado que se realiza en

el siguiente capítulo.

4.3.1 VÍAS DE CARGA DE DATOS

Para construir un mapa temático, las plataformas objeto de análisis han de proporcionar mecanismos añadir

elementos geográficos a un mapa base y agregar datos a los elementos geográficos. Cabe además la

posibilidad de elegir mapas elaborados por otros usuarios, o por otras plataformas o aplicaciones, y sobre ellos

hacer modificaciones.

4.3.2 OPCIONES PARA LAS CAPAS BASE

Una de las características más interesantes de las plataformas de publicación de información geográfica es la

capacidad que tienen para que el usuario seleccione la cartografía base que van a utilizar en sus mapas.


Página 23 de 60

Normalmente esta cartografía no está limitada a un único servicio sino que cada una de las plataformas están

integradas con varios proveedores (GoogleMaps, OpenStreetMap, CloudMade, Esri, Microsoft, Metacarta, etc.)

para que las opciones a la hora de crear mapas sean lo más amplias posible.

4.3.3 VALORACIÓN DE FUNCIONALIDADES Y USABILIDAD

Analizaremos en este apartado las funcionalidades ofrecidas por cada plataforma que las hacen diferentes del

resto y su usabilidad, es decir la claridad y la elegancia con que se diseña cada una de ellas.

Una de las tareas más difíciles de conseguir es la de priorizar la sencillez de una herramienta frente a

desarrollar nuevas funcionalidades. Una aplicación usable debe ser de fácil manejo y aprendizaje, para que

el usuario no pierda mucho tiempo buscando cómo se realiza determinada tarea, flexible, tener varias

posibilidades de actuación para el usuario en cada momento y fiable, es decir, se deben detectar todas las

excepciones y diferentes tipos de errores que pueden llegar a surgir y solventarlos antes de que sucedan para

que el usuario experimente una navegación cómoda y sin molestas interrupciones.

4.3.4 CAPACIDADES DE ESTILO Y REPRESENTACIÓN EN LOS MAPAS

Dentro de este apartado se examinan las posibilidades de cada plataforma para añadir y modificar las

características visuales de los elementos geográficos, así como las formas posibles de representar datos no

espaciales sobre el mapa.

Para cada una de las plataformas estructuraremos las características de estilo en los siguientes tipos:

1. Estilos de elementos espaciales:

� marcas: formas, colores y tamaños de iconos, iconos personales

� líneas: tipo, anchura, color

� polígonos (áreas): textura, color, transparencia, borde (tipo, anchura, color)

2. Representación de atributos (datos asociados a elementos):

� etiquetas de texto

� coropletas (mapas de color)

� burbujas, o tamaño de iconos

3. Overlays (imágenes georreferenciadas)

4. Paneles de información contextual, desplegable o no: textos, HTML, tablas, imágenes

5. Representación de datos fuera del mapa: gráficos de tarta, barras o líneas

4.3.5 OPCIONES PARA LA DIFUSIÓN DE MAPAS EN REDES SOCIALES Y OTROS MEDIOS

EXTERNOS

Actualmente es muy habitual la utilización de redes sociales (Facebook, Twitter, etc), por lo que prácticamente

todos los servicios existentes en la Red proporcionan mecanismos de socialización: contactos o amigos,

compartir contenidos, votación y comentarios, etc.

4.3.6 POLÍTICAS DE SEGURIDAD: CONTROL DE ACCESO A LOS DATOS Y BACKUPS

Las políticas de seguridad se traducen en una serie de normas y protocolos donde se definen las medidas a

tomar para proteger la seguridad del sistema. Se analizará para cada plataforma si existen políticas de acceso

seguras y su capacidad de recuperación ante desastres.


Página 24 de 60

4.3.7 CUMPLIMIENTO CON ESTÁNDARES

Con esta característica se estudiará el grado de cumplimiento de cada plataforma con ciertas normas y

estándares (en especial el OGC), elaborados con el fin de garantizar la interoperabilidad entre elementos

construidos de forma independiente.

4.3.8 INTEROPERABILIDAD CON OTRAS PLATAFORMAS O SERVICIOS EXTERNOS

Estudiaremos la habilidad de cada plataforma para interactuar con otras aplicaciones o servicios con la

finalidad de obtener un mutuo beneficio.

4.3.9 RENDIMIENTO

Una de las ventajas de la nube es la capacidad elevada de proceso, siempre y cuando la economía lo permita.

Esto último es importante, una aplicación mal optimizada va a costar a largo plazo mucho más que una

aplicación que funcione correctamente, ya que en la nube se paga –entre otras cosas- por proceso.

Evaluar el rendimiento de cada plataforma a fondo exigiría realizar múltiples pruebas utilizando diferentes

herramientas de test o programar peticiones web de interés, lo cual excede los objetivos de este TFC.

Un indicador podría ser el tiempo de carga de un mismo lote de datos y en este caso analizaremos el

rendimiento de las cinco plataformas a partir de pruebas, destinadas a prever el comportamiento del sistema

bajo volúmenes de carga considerables. Para ello se cargará un fichero delimitado por comas (de 594 kB de

tamaño) con los 8112 municipios de España en el que ya se incluyen la latitud y la longitud, y se medirá el

tiempo que tarda cada plataforma en procesar la información desde el mismo ordenador y en las mismas

condiciones.

Otro indicador del rendimiento de las plataformas podría ser el tiempo medio de una exportación de datos al

mismo formato. En este sentido, el único formato de exportación común a las cinco plataformas es el KML.

Dadas las limitaciones de carga de algunas plataformas en las cuentas gratuitas, el volumen de datos que se

puede exportar no es suficiente para que la prueba sea significativa. De todos modos, se ha realizado una

exportación de un mapa al formato KML en las mismas condiciones. Todas las plataformas han respondido de

forma prácticamente inmediata, tardando menos de 3 segundos en completar todo el proceso.

4.3.10 CAPACIDAD DE TRABAJO EN MÚLTIPLES NAVEGADORES WEB Y TIPOS DE

DISPOSITIVO

Hoy en día, cualquier plataforma puede ser accedida desde múltiples navegadores en una gran variedad de

dispositivos. Para desarrollar este apartado se ha chequeado cada plataforma en ordenadores personales y en

dispositivos móviles.

Se han testeado las cinco plataformas sobre dispositivos de escritorio y portátiles utilizando los

navegadores Opera, Safari, Explorer, Firefox y Chrome. En estos casos todas las plataformas permiten los

controles de movimiento y zoom sobre el mapa, y muestran el recuadro desplegable al hacer clic sobre la

marca de posición, es decir funcionan correctamente.

El número de personas que utilizan dispositivos móviles para navegar en Internet está creciendo rápidamente.

Una página web debería poder visualizarse de manera atractiva en los dispositivos móviles más populares. En

la actualidad puede resultar muy útil optimizar un sitio web para su uso desde móviles. Esto permite

asegurarse de que el texto es legible y el sitio fácil de navegar.

Hay 2 maneras de implementar una versión móvil de un sitio web.


Página 25 de 60

− Mobile CSS: permite cambiar la forma de organizar y visualizar un sitio web en los dispositivos móviles.

− Redirección móvil: permite crear un sitio web totalmente diferente para los espectadores móviles.

Muchas veces, cuando se desarrolla una web multi-dispositivo, nos encontramos con el problema de que no se

adapta a las diferentes resoluciones de los dispositivos móviles. Para solucionar este problema, existe un

meta-tag HTML, el meta-tag viewport, gracias al cual podremos adaptar el contenido de la web de “escritorio”

en los dispositivos móviles (siempre que el diseño de la web lo permita).

Los móviles de Apple están creciendo de forma increíble por todo el mundo. Puede resultar útil configurar un

Apple icon para un sitio web, de forma que cuando alguien acceda desde algún móvil Apple salga el icono

definido por defecto.

Según el último análisis de StatCounter (servicio web de estadísticas), el navegador más utilizado es el

navegador de Android, seguido por Opera y por Safari de Apple en tercer lugar; mucho más abajo Nokia y

luego BlackBerry.

Siguiendo estas tendencias, se han chequeado las plataformas sobre los siguientes dispositivos móviles:

− Tableta con sistema operativo Android 4.0.3, sobre los navegadores de Android y Opera Mobile.

− Tableta con sistema operativo iOS 5.1 sobre el navegador Safari.

En estos casos todas las plataformas permiten los controles de movimiento y zoom sobre el mapa, pero

algunas de ellas sobre algunos dispositivos y/o navegadores no muestran el recuadro desplegable al hacer clic

sobre la marca de posición; entonces diremos que no funcionan correctamente. Esto se irá detallando sobre

cada una de las plataformas.

4.3.11 VALORACIÓN DE LA API PARA PROGRAMADORES: LENGUAJES, DOCUMENTACIÓN

Y EJEMPLOS

Con esta característica valoraremos para cada plataforma su interfaz de programación de aplicaciones o API;

estudiaremos el conjunto de funciones y procedimientos que ofrecen desde el punto de vista del programador,

así como la calidad de la documentación y los ejemplos ilustrativos.

4.3.12 TECNOLOGÍAS SUBYACENTES

En este apartado se estudiará el lenguaje sobre el cual está implementada cada una de las plataformas así

como las tecnologías que soporta.

4.3.13 MODELO DE NEGOCIO

Un modelo de negocio es un mecanismo gracias al cual un negocio busca generar ingresos y beneficios. Es un

resumen de cómo una compañía planifica servir a sus clientes. Implica tanto el concepto de estrategia como el

de implementación.


Página 26 de 60

5 ANÁLISIS TÉCNICO DE PLATAFORMAS DE PUBLICACIÓN

En este capítulo se han seleccionado cinco plataformas de publicación de información geográfica en la nube.

Por orden alfabético: CartoDB, Geocommons, Google Fusion Tables, ikiMap y ScribbleMaps.

Se analizan a fondo las características técnicas de cada plataforma como paso previo a la selección de la más

adecuada al caso de estudio. Igualmente, se expone una pequeña ficha técnica de cada una de ellas que sirve

como presentación e identificación.

Una tabla comparativa, producto de este análisis, aparece detallada al final de este capítulo.

5.1 CARTODB. BASE DE DATOS GEOESPACIAL PARA EL DESARROLLO DE

APLICACIONES WEB

Plataforma Open Source cuya finalidad es facilitar la creación de aplicaciones geolocalizadas y mapas, a partir

de la gestión y procesamiento de datos, poniendo énfasis en la gestión de los estilos de representación.

5.1.1 FICHA BÁSICA

Tabla 3. CartoDB. Principales características

Nombre, versión y URL CartoDB (versión 1.0) http://cartodb.com/

Autores, año y país de origen Vizzuality. 2008, España

Está también en español No

Entradas en Google 4.920

Número de visitas (SEO, cuwhois) 15.270/mes

Foros de discusión / Ayuda blog, tumblr, twitter /

https://groups.google.com/forum/?fromgroups#!forum/cartodb

5.1.2 ANÁLISIS DETALLADO

A continuación se analiza el comportamiento de la plataforma para cada uno de los aspectos técnicos descritos

en el capítulo anterior.

5.1.2.1 VÍAS DE CARGA DE DATOS

La gestión de los datos comienza con el panel de control, donde se pueden ver y editar todas las tablas

creadas, así como borrar y crear tablas nuevas. También proporciona información acerca de las cuotas que

están siendo utilizadas por el usuario.

Para la creación de tablas se puede elegir cualquiera de las siguientes opciones:


Página 27 de 60

a) Crear una tabla vacía. Para insertar los datos a mano o mediante programación se puede crear una tabla

nueva en blanco con las columnas predeterminadas de CartoDB y los índices en su lugar.

b) Subir un archivo. CartoDB soporta un número creciente de formatos de archivo y tipos de datos. Entre los

formatos aceptados están: valores separados por coma o tabulador (.CSV, .ZIP, .GZ, .TAR.GZ, .TGZ),

ESRI Shape File (.ZIP *), Keyhole Markup Language (.KML y .KMZ), hoja de cálculo Excel (.XLS, .XLSX),

GeoJSON (.GEOJSON, .JSON), GPS eXchange Format (.GPX), Open Street Map (.OSM, .BZ2), hoja de

cálculo OpenDocument (.ODS) y GeoTIFF (.ZIP)

c) Importar desde una URL.

CartoDB permite convertir los campos lat/lon o descripciones textuales en geometrías; junto a la columna que

desea referenciarse geográficamente debe seleccionarse “Georreferenciación”. A continuación, se puede

seleccionar la primera opción: “Esta es una columna de latitud / longitud”, o la segunda: “Elegir o crear una

columna de dirección”. Con la segunda opción, se puede combinar una o más columnas para describir la

ubicación de un registro, por ejemplo se pueden combinar tres columnas, ciudad, estado y país en una única

cadena delimitada por comas, buscándose su correspondiente latitud y longitud.

5.1.2.2 OPCIONES PARA LA CAPA BASE

Las opciones actuales utilizan Google Maps para la capa base y son cuatro: Roadmap, Satelite, Terrain y

Custom Tiles.

5.1.2.3 VALORACIÓN DE FUNCIONALIDADES Y USABILIDAD

Funcionalidades. CartoDB tiene funcionalidades avanzadas como la geocodificación, la utilización de un

lenguaje de estilo llamado CartoCSS, un editor de SQL para la gestión de tablas y la posibilidad de realizar

análisis geoespacial (por ejemplo, crear un punto a partir de la longitud y la latitud, calcular áreas de

polígonos o medir distancias) y análisis avanzado (encontrar los registros asociados a un punto, consultar

registros dentro de un área, unir los datos de dos tablas u ordenar registros por distancia a un punto, etc.).

Usabilidad. El interfaz de usuario es muy básico, por lo que para acceder a la mayoría de funcionalidades de

esta plataforma se debe usar el lenguaje CartoCSS. Por eso no se puede considerar que esté dirigida al gran

público, sino que requiere un mínimo aprendizaje de ese lenguaje, solamente usado por CartoDB y MapBox.

5.1.2.4 CAPACIDADES DE ESTILO Y REPRESENTACIÓN

CartoDB incluye una serie de controles básicos que permiten las características de estilo habituales para los

elementos geométricos: tipos, colores, tamaños, etc.

Además de los métodos anteriores, CartoDB proporciona acceso al lenguaje de estilo de Mapbox llamado

Carto, similar al CSS. Este lenguaje permite asignar estilos a los elementos del conjunto de datos en función

de sus valores. Combinado con la potencia de las sentencias SQL, se pueden hacer visualizaciones avanzadas

de datos.

CartoDB permite visualizar los datos usando varias técnicas de cartografía temática, tales como coropletas de

puntos (cambio de color) y mapas de burbuja (cambio de tamaño).

Las ventanas de información (Infowindows) generadas por defecto por CartoDB contienen todas las columnas

de la tabla asociada al elemento seleccionado, pudiendo cambiarse los valores por defecto activando o

desactivando cualquiera de los atributos.


Página 28 de 60

No hay límites en la cantidad de filas a visualizar en un mapa. No hay límite en el número de vértices por

“tile”.

CartoDB no permite representación en forma de gráficos de datos desde el panel de usuario (dashboard).

Tampoco permite imágenes raster overlay.

5.1.2.5 OPCIONES PARA LA DIFUSIÓN DE MAPAS EN REDES SOCIALES Y MEDIOS EXTERNOS

Todas las cuentas CartoDB (excepto las gratuitas)

permiten tablas privadas, que pueden ser vistas por un

usuario autenticado en la cuenta. Estas tablas privadas

no se pueden compartir hasta que se hagan públicas, es

decir disponibles al público por URL.

Ilustración 8. Compartir con CartoDB

Fuente: http://cartodb.com/

Existen dos formas de compartir un mapa en CartoDB:

- Enlace directo. Permite pasar una URL a un colaborador o compartir en línea. Es la única forma de difundir

un mapa en las redes sociales.

- Código HTML. Proporciona un marco mediante el tag <iframe> para incrustar el mapa en un sitio web o

blog.

El sitio web es bastante popular en las Redes Sociales. Tiene una Cuenta Twitter @cartoDB registrada, que

enlaza a la página web con 848 seguidores.

5.1.2.6 POLÍTICAS DE SEGURIDAD: CONTROL DE ACCESO A LOS DATOS Y BACKUPS

La plataforma proporciona un almacenamiento seguro de los datos. En todas las cuentas, los datos son

personales a la hora de escribir o modificar. En los niveles de suscripción se ofrece la posibilidad de alojar

tablas privadas, en las que el propietario será la única persona capaz de leer sus datos; en las cuentas

gratuitas las tablas son siempre públicas (visibles al resto).

CartoDB refuerza el acceso seguro a la API para todas las tablas privadas y para la escritura en tablas

públicas, requiriendo la autorización a las consultas a través de la utilización de una clave secreta; es

necesario, por tanto generar una clave en el panel de control. El acceso a esta API está asegurado por SSL y

OAuth. CartoDB ofrece servicios de backup en cualquier nivel de hosting.

Ilustración 9. Permisos en CartoDB

Fuente: http://cartodb.com/

5.1.2.7 CUMPLIMIENTO CON ESTÁNDARES

En general CartoDB se centra en las características de los usuarios y desarrolladores que pueden crear

visualizaciones y aplicaciones con los datos de localización. Los estándares de OGC no son una prioridad en su

diseño; para cubrir estos aspectos se recomienda utilizar otros servicios conjuntamente. Por ejemplo se puede

instalar GeoServer junto con CartoDB con el fin de disponer de estos servicios.

Algunos de los estándares que cumple la plataforma son los siguientes:


Página 29 de 60

- Normas OGC: KML, no soporta WMS ni CSW.

- Normas W3C: HTML5.

- Normas ISO: SQL.

5.1.2.8 INTEROPERABILIDAD CON OTRAS PLATAFORMAS O SERVICIOS EXTERNOS

Los formatos de exportación que soporta CartoDB son: CSV, KML, SHP, y SQL.

Integración con Leaflet. Leaflet es una librería Javascript opensource desarrollada por CloudMade, muy ligera,

para trabajar amigablemente desde móviles con mapas interactivos en OpenStreetMap. Está pensada para

trabajar en plataformas móviles HTML5 y CSS3.

Integración con Google Maps. Es fácil de usar CartoDB con Google Maps v3 mediante Javascript. CartoDB ha

creado una biblioteca para agregar tablas al mapa, refrescarlas, y proporcionar interactividad al hacer clic en

los polígonos. La biblioteca se basa en WAX, de MapBox.

Integración con WhirlyGlobe, un motor 3D de código abierto para el iPad. WhirlyGlobe puede recuperar los

datos de CartoDB y presentarlos para la interacción en su mundo 3D.

5.1.2.9 RENDIMIENTO

El rendimiento es muy bueno ya que usa la nube de computación de Amazon.

Cuando se carga el fichero .csv con los 8112 municipios de España, CartoDB responde casi inmediatamente

(del orden de 2 o 3 segundos) pero sólo carga y visualiza las 301 primeras

filas. Como se puede observar en la figura, corresponden a los municipios

de la comunidad autónoma de Andalucía (primera en cargar por orden

alfabético).

Este límite es un límite impuesto a la cuenta gratuita. De hecho, Vizzuality

confirma que se han hecho pruebas con servidores dedicados y se ha

llegado a los 15 millones de filas visualizadas o incluidas en consultas.

Ilustración 10. Rendimiento en CartoDB

5.1.2.10 CAPACIDAD DE TRABAJO EN MÚLTIPLES NAVEGADORES WEB Y TIPOS DE

DISPOSITIVO

Sobre dispositivos fijos es recomendable usar la última versión de los siguientes navegadores: Opera, Safari,

Explorer, Firefox, Chrome.

Sobre dispositivos móviles, CartoDB no funciona adecuadamente sobre Opera Mobile; en cambio su

comportamiento sobre Android y Safari es correcto.

La plataforma está muy optimizada para dispositivos móviles. Usa meta tag Viewport y redirección móvil. Sin

embargo no dispone de mobile CSS ni de Apple icon.

5.1.2.11 VALORACIÓN DE LA API PARA PROGRAMADORES

CartoDB ofrece dos formas principales para acceder a los datos y servicios.

Primero, la API de SQL, que es una especie de servicio WFS más flexible. Permite realizar consultas, recuperar

datos y autenticarse para programar la escritura, actualización y eliminación de datos.


Página 30 de 60

En segundo lugar, la Maps API, que es una versión muy limitada de WMS (en realidad es una especie de

servicio Web Map Tile). Permite la combinación de grandes volúmenes de datos para su transferencia y

visualización.

La combinación de estas dos API ofrece un potente motor geoespacial para el desarrollo de aplicaciones.

CartoDB proporciona librerías para diferentes lenguajes de programación: Ruby, JavaScript, PHP, Python, Java

y .Net. En la dirección http://developers.cartodb.com/documentation/cartodb-apis.html se ofrece amplia

documentación acerca de esta API.

5.1.2.12 TECNOLOGÍAS SUBYACENTES

Los componentes de CartoDB son los siguientes: una interfaz de usuario para cargar, crear, editar, visualizar y

exportar datos geoespaciales, una base de datos geoespacial basada en PostgreSQL y PostGIS 2.0, una API de

SQL para ejecutar consultas SQL a través de HTTP con resultados formateados usando GeoJSON y KML, un

generador de mapas que soporta SQL y estilos de visualización utilizando CartoCSS, autenticación por medio

de OAuth.

CartoDB está implementado en lenguaje Ruby y usa las siguientes tecnologías: Mapnik 2.0, NodeJS 0.4.10 +,

PostGIS 2.0, Postgres 9.1.x, Redis 2.2 +, Varnish 3.0 +, Ruby 1.9.2 + y HTML5.

Está basado internamente en PostGIS 2.0, y sobre él está desarrollado en Node.js, Ruby y un poco de Python.

Para la visualización usa Mapnik. CartoDB proporciona una interfaz

para importar y visualizar datos geoespaciales y una serie de APIs

para acceder a los datos mediante sentencias SQL y Tiles. Soporta

datos raster, búsquedas por proximidad basadas en índices y nuevas

funciones para trabajar utlizando GeoJSON. Se ha desarrollado la

tecnología VisualRaster para la visualización de datos raster en el

navegador utilizando HTML5.

Ilustración 11. Arquitectura de CartoDB

Fuente: http://www.sigte.udg.edu/jornadassiglibre2012/uploads/presentaciones_12/p46.pdf

Con la reciente versión 1.0 se pueden crear visualizaciones interactivas utilizando HTML5, mapas en tiempo

real y reconocimiento de ubicación de las aplicaciones móviles. Vecnik, una biblioteca JS, permite representar

las características de CartoDB utilizando HTML5 sobre Modestmaps. La ventaja sobre Mapnik es que es más

rápido ya que se ejecuta en el cliente, en vez de ejecutarse en el servidor.

5.1.2.13 MODELO DE NEGOCIO

CartoDB se basa en el modelo SaaS (Software as a Service). Es Open Source. Es un producto freemium.

Ofrece cuatro planes de contratación que varían en el número y tamaño de tablas, forma de atención al

usuario, privacidad de datos y publicidad (http://cartodb.com/pricing). Es fácilmente escalable.

CartoDB ofrece sus servidores como alojamiento de las bases de datos para aplicaciones de forma gratuita

aunque limitada a un máximo de 5 tablas y 5 MB. También ofrece soluciones más potentes en diversas

modalidades de suscripción de carácter mensual.

Público objetivo: Desarrolladores expertos en sistemas de información geoespacial y usuarios con

conocimientos informáticos y cierto dominio del idioma inglés.


Página 31 de 60

5.2 GEOCOMMONS. TODO SOBRE ANÁLISIS ABIERTO, DATOS Y MAPAS

Plataforma pionera en el ámbito de la Neogeografía, que permite la creación de mapas complejos y la

realización de múltiples operaciones de análisis espacial, de forma accesible a usuarios no familiarizados con

las tecnologías SIG.

5.2.1 FICHA BÁSICA

Tabla 4. Geocommons. Principales características

Nombre, versión y URL GeoCommons (versión 2.0) http://geocommons.com

Autores, año y país de origen FortiusOne Inc. 2005, EEUU




Foros de discusión https://getsatisfaction.com/geocommons/, Blog, Facebook, Twitter, Vimeo





Hay varias opciones para añadir datos a un mapa. Al añadir una capa se abre directamente el buscador

permitiendo una serie de opciones: cambiar el mapa base, encontrar capas para añadir a un mapa y subir

datos desde el propio ordenador.

Así pues, se puede elegir cualquiera de las siguientes opciones:

1. Utilizar el motor de búsqueda de la aplicación en el repositorio público de la plataforma. De esta forma se

puede ver qué datos comparten otros usuarios y utilizarlos para crear el mapa.

2. Cargar ficheros desde el propio ordenador. Geocommons admite la carga de datos desde distintos tipos de

fuentes de datos: hojas de cálculo, archivos KML, “Shape File”.

3. Añadir un enlace URL desde la web a servidores de bases de datos con soporte espacial, servicios OGC

como WMS y TMS.

Todos los datos que se suban a la aplicación o que se generen en ella forman parte del directorio público, por

tanto son accesibles para toda la comunidad de usuarios. En el visor la información se puede organizar

mediante capas.


Página 32 de 60

Geocommons permite recuperar coordenadas de longitud y latitud a partir de archivos CSV basados en la

localización. En la actualidad, el geocodificador está en desarrollo y sólo funciona en los Estados Unidos; en el

futuro se tiene la intención de ampliarlo para hacerlo extensible al resto de la geografía mundial.


Los mapas base disponibles son muy variados; tiene los tipos comunes como el topográfico, callejero, satélite

y además incorpora uno propio llamando <<Acetate>>. Geocommons permite crear mapas empleando como

cartografía base cualquiera de las siguientes trece opciones: Acetate, Acetate Terrain, OpenStreetMap (Road),

Google (Aerial, Hybrid y Road), MapQuest, Microsoft (Aerial, Hybrid y Road), Nasa Blue Marble, OSM

GeoCaché (EPSG:4326) y VMAP GeoCaché (EPSG:4326).


Funcionalidades. Geocommons tiene funcionalidades avanzadas como la geocodificación, la gestión de tablas y

la animación temporal. Permite realizar análisis de datos espaciales; para ello proporciona algunas funciones

como: Addition, Subtraction, Custom Equation, Merge, Aggregation, Dynamic Aggregation, Buffer, Filter by

Distance, Intersection, Simplify, Create your own analysis tool, Predict within a dataset, y Predict across

datasets.

Usabilidad. La interfaz gráfica de la aplicación es muy intuitiva, es fácil crear mapas atractivos en poco tiempo.

Las herramientas y menús no están visibles de forma permanente por lo que dejan todo el espacio para el

mapa. La aplicación tiene un alto grado de usabilidad y la organización de la información es muy buena.

Además, permite al usuario olvidarse de los cambios de proyección de los datos, ya que la plataforma los

reproyecta automáticamente en función del mapa base.


La simbolización de los objetos en el mapa se hace mediante métodos de clasificación cartográfica, lo que para

algunos puede suponer un “handicap”. No tiene funcionalidades para editar o crear geometrías en pantalla. Sí

que se pueden modificar los atributos alfanuméricos asociados a ellas.

GeoCommons permite crear mapas de referencia y mapas temáticos.

Los mapas de referencia muestran la ubicación de las características geográficas usando símbolos geométricos

sencillos como puntos, chinchetas o líneas discontinuas para mostrar los elementos que se encuentran.

Los mapas temáticos utilizan formas o símbolos para mostrar los valores asociados a las ubicaciones. Con

GeoCommons puede optarse por mostrar los datos a través de colores o formas:

� Mapas de color (también conocido como mapas de coropletas): Si los datos van asociados a áreas, tales

como municipios o países, puede representar los valores utilizando los colores para cada valor, por ejemplo,

visualización de la población de cada Comunidad Autónoma mediante una secuencia de color claro a oscuro.

� Mapas de tamaño (también conocido como mapas de símbolos proporcionales o graduado): Si los datos van

asociados a zonas o puntos, puede utilizar el tamaño de los símbolos para representar los diferentes

valores, por ejemplo, visualizar los aforos máximos de salas de conciertos.

Geocommons permite la representación de gráficos de datos. No permite imágenes raster overlay.


Todas las visualizaciones son fáciles de compartir en Facebook (Send to Facebook) y en Twitter(Tweet this);

existen botones específicos en el panel de control. Los mapas creados con GeoCommons pueden ser


Página 33 de 60

fácilmente integrados en otros sitios web o de colaboración. Para incrustar un mapa, se debe hacer clic en el

botón About cuando se visualiza el mapa que se desea incrustar, lo cual no es nada intuitivo.

Existe la opción de compartir con más de 300 aplicaciones a través del servicio externo AddThis. Además se

dispone de la opción “Embed this map in your

website”. Al hacer clic en este enlace se muestran dos

cuadros de texto que tienen un código HTML que

puede ser copiado y pegado. Se puede elegir entre

usar un tag <iframe> o no usarlo.

La web es muy popular en las Redes Sociales. Tiene

una cuenta Twitter registrada, @geocommons, que

enlaza a la página web con 4236 seguidores.

Ilustración 12. Compartir con Geocommons

Fuente: http://geocommons.com/


GeoIQ Enterprise incluye un conjunto completo de permisos y controles de acceso de los datos. Se puede

limitar el acceso y modificar los roles de usuarios, grupos u organizaciones. Geocommons permite decidir el

nivel de privacidad deseado para el conjunto de datos. Hay tres niveles de permiso: Edit, Access y Find. Puede

elegirse a quién se le permite editar el conjunto de datos, quién puede acceder o quién puede encontrar la

base de datos (ver los datos, pero no asignar o descargar el programa), incluido el permiso de acceso a los

grupos de los que se forma parte.

Ilustración 13. Permisos en Geocommons

Fuente: http://geocommons.com/


GeoIQ utiliza estándares web abiertos y de uso común que permiten un intercambio fácil de datos entre

organizaciones. Actualmente trabaja en el desarrollo de nuevas normas que respondan a las necesidades

emergentes.

Algunas normas pertinentes que GeoIQ utiliza y ofrece a los usuarios son las siguientes:

- Normas OGC: KML, WMS, TMS, CSW

- Normas W3C: microformatos, JavaScript, RSS, GeoRSS

- Normas ISO: PDF, metadatos


Los formatos de exportación soportados son: SHP, CSV, KML, GeoRSS Atom, Spatialite y JSON.

Usando GeoIQ Connect se puede integrar Oracle, MySQL, PostgreSQL, ESRI, MongoDB, y almacenes de datos

y otras API con el resto de las características de GeoIQ.


Página 34 de 60

GeoIQ se ha asociado con Appcelerator para proporcionar una plataforma cruzada de desarrollo móvil y

geoseguimiento de las aplicaciones móviles. Se ofrecen servicios en la nube, así como máquinas virtuales.

5.2.2.9 RENDIMIENTO

Desde la versión 2.0 Geocommons tiene un motor de visualización más

potente, pudiendo manejar grandes conjuntos de datos a una velocidad

mayor, lo que permite a los usuarios registrados cargar y visualizar decenas

de miles de datos en segundos.

De hecho cuando se carga el fichero delimitado por comas con los 8112

municipios de España, la velocidad de carga y procesado es muy alta: todas

las filas son procesadas en menos de 5 segundos.

Ilustración 14. Rendimiento en Geocommons


DISPOSITIVO

Gracias al soporte para HTML5 y Flash, GeoCommons es soportado por la mayor parte de los navegadores

web. La suite permite trabajar con múltiples versiones de reproductores Web de Flash y aplicaciones de

navegación en Internet. No obstante, para trabajar a pleno rendimiento es necesario un sistema actualizado,

funcionando con un reproductor de Flash y un explorador apropiados. La siguiente es una lista de versiones

mínimas para Flash y navegadores compatibles:

Flash: Windows (10.1), Mac (10.1), Linux (9).

Navegadores: Chrome (12), Firefox (3.6), Internet Explorer (7) y Safari (5.1).

Sobre dispositivos móviles, Geocommons no funciona adecuadamente sobre Opera Mobile; en cambio su

comportamiento sobre Android y Safari es correcto.

La plataforma está optimizada para dispositivos móviles. Usa redirección móvil. Sin embargo no dispone de

meta tag Viewport, ni mobile CSS ni Apple icon.


GeoIQ incluye una interfaz de programación de aplicaciones bastante completa que proporciona capacidad de

carga y descarga de datos, búsqueda de datos y mapas, construcción, incorporación, y tematización de

mapas, así como gestión de usuarios, grupos y permisos.

La API GeoIQ consiste en una API REST y una API de JavaScript. Una API REST se accede a través de

direcciones web o URLs en las que se envía los datos de una consulta. Como respuesta se obtienen datos en

diferentes formatos, como pueden ser texto plano, XML, JSON, etc.

En la dirección http://developer.geoiq.com/api/, se incluyen varias secciones con métodos específicos,

ejemplos e ilustraciones.


GeoCommons está construido sobre la plataforma GeoIQ utilizando la API REST y JavaScript. Utiliza

herramientas open source como Ruby, Rails, Mapnik, JQuery, ModestMaps, Python, ImageMagick, Yajl, GEOS,

GDAL y PROJ4, además de otros paquetes disponibles a través de Red Hat y los repositorios CentOS.


Página 35 de 60

Ilustración 15. Arquitectura de Geocommons

Fuente: http://www.slideshare.net/ajturner/geoiq-stack-where-2012


Geocommons.com aglutina la comunidad pública de usuarios que usan de forma gratuita la plataforma GeoIq,

que usa tecnología open-source. Es un servicio gratuito para datos públicos y mapas, permitiendo a cualquier

persona compartir datos, visualizaciones y análisis de forma rápida y sencilla.

Sin embargo existen algunas restricciones de uso en la cuenta gratuita. Los usuarios están limitados en su

número de descargas simultáneas y en las descargas totales por día. Esto queda determinado a través de una

serie de indicadores internos.

El modelo de negocio GeoCommons implicará un servicio de pago a los usuarios que quieran usar datos

privados o funciones más avanzadas.

Público objetivo: Desarrolladores y usuarios con conocimientos informáticos y cierto dominio del idioma inglés.


Página 36 de 60

5.3 GOOGLE FUSION TABLES. REÚNE, VISUALIZA Y COMPARTE TUS DATOS ONLINE

Plataforma de Google, diseñada como un gestor de base de datos en el que las operaciones se realizan

directamente sobre tablas, pudiendo combinar tablas de distinta procedencia, aplicar filtros y realizar algunas

operaciones de análisis básicas. Permite manejar grandes volúmenes de datos y, a través de la

geocodificación, visualizarlos en forma de mapa.

5.3.1 FICHA BÁSICA

Tabla 5. Google Fusion Tables. Principales características

Nombre, versión y URL Fusion Tables (versión beta) http://www.google.com/fusiontables/

Autores, año y país de origen Google Inc. 2011, EEUU




Foros de discusión @GoogleFT on Twitter https://groups.google.com/a/googleproductforums.com/forum/#!categories/google-

fusion-tables





Google Fusion Tables permite importar hasta 100 MB de los siguientes tipos de fichero: textos separados por

comas (.csv), otros ficheros de texto delimitados (.tsv), ficheros KML, hojas de cálculo (.xls, .xlsx, .ods) y

hojas de cálculo de Google Docs. Para representar los datos en forma de mapa, éstos deben contener

referencias espaciales, ya sean coordenadas o direcciones. Para ubicar direcciones postales usa el algoritmo

de geolocalización disponible en la API de Google Maps.

Permite subir información en formato *.shp gracias a la herramienta Shpescape, respetando su estructura

interna de datos. También dispone de Fusion Tables Builder, herramienta que nos permite elaborar mapas

personalizados, integrando listados y mapas de estilos de Google Maps.

La cartografía debe tener proyección WGS84.


Google Fusion Tables permite crear mapas empleando como cartografía base cualquiera de las siguientes tres

opciones: Mapa, Mapa (Relieve) y Satélite.


Página 37 de 60


Funcionalidades. Permite el procesamiento avanzado en bloques de datos, la aplicación de filtros para usar

sólo el subconjunto deseado (selección), la combinación de tablas de datos de diferentes usuarios para ver

toda la información en un solo lugar (fusión), la agrupación de datos para aplicar operaciones estadísticas

(agregación) y la representación de gráficas. También posibilita la geocodificación.

Usabilidad. La interfaz gráfica de la aplicación es muy intuitiva. Es un sistema de gestión de datos moderno y

una aplicación de publicación web que facilita alojar, gestionar, colaborar, visualizar y publicar tablas de datos

en línea. Sin embargo la gestión se realiza siempre directamente sobre las tablas y no sobre el mapa.


Fusion Tables puede representar los datos de una tabla en forma de gráficos y en forma de mapas con estilos

personalizables. A cada uno de los elementos geográficos (puntos, líneas o polígonos) se les puede aplicar un

estilo propio. Hay tres formas de especificar este estilo:

� Fijo. Especificar un estilo único que se utiliza para todos los elementos en el mapa

� Columna. Proporciona una especificación para la visualización de las filas en una de las columnas de datos

de las tablas. Se debe seleccionar esta columna como la fuente del estilo. Esta opción proporciona un

control más específico sobre la representación de atributos en el mapa.

� Cubos. Especifica dos o más rangos de números, y da a cada rango un estilo. Este estilo se asigna a cada

fila en función del valor de una columna de datos numéricos.

Se puede dar estilo con "Column" a:

a) un icono de marcador. Los marcadores básicos disponibles presentan dos tamaños: pequeño (amarillo,

verde, púrpura y rojo) y grande (azul, amarillo, verde y púrpura). Hay además 200 marcadores

adicionales reconocidos por Fusion Tables.

b) polígonos y líneas. Se puede especificar el color de relleno, el color y el ancho del borde para todos los

polígonos que aparecen en el mapa, o por columnas dentro de la tabla. Para las líneas, pueden

especificarse su color y su ancho. También se puede cambiar el color y la opacidad del relleno de

polígonos, del borde o la línea en una columna de la tabla. La anchura de las líneas y bordes de polígonos

se pueden especificar en una columna de tipo numérico.

Si la especificación de estilo no se encuentra o no se reconoce, las ubicaciones y geometrías se muestran con

el icono, color, y ancho de línea por defecto.

También ofrece la posibilidad de crear “mapas de calor” (“Heat maps”) para identificar zonas con más alta

concentración de objetos, y “mapas de intensidad”.

No permite imágenes raster overlay.

Fusion Tables Builder es una herramienta que facilita la elaboración de mapas personalizados, integrando

listados y mapas de estilos de Google Maps.


Los mapas y tablas elaborados se pueden compartir, modificar por bloques y ser utilizados online de forma

muy sencilla. Hay varias maneras de compartir los datos: se puede compartir la propia tabla como una URL o

enlace incrustado, compartir un mapa mediante una dirección URL del navegador, mediante un enlace


Página 38 de 60

incrustado para su inclusión en una página web, como una copia estática del mapa o mediante un vínculo

dinámico para Google Earth.

Sólo se pueden compartir los datos de uso público o restringido, por lo que se necesita cambiar la

configuración de acceso si la tabla es privada. Si se quiere incrustar un mapa mientras se mantiene la tabla

como privada hay que utilizar el API de Google Maps for Business mediante la opción "Get embeddable link".

Si se desea identificar de dónde vienen los datos existe una casilla de verificación pero sólo está disponible

para visualizaciones que no sean mapas. Se copiará el código HTML que se muestra en el cuadro y se pegará

en el sitio web o en el editor HTML del sitio web.

Los usuarios que ven los datos pueden dejar comentarios por columna, fila o celda. Las discusiones guardan

un seguimiento de quién dijo qué y cuándo.

El sitio web es bastante popular en las Redes Sociales. Tiene una Cuenta Twitter @googlelabs registrada, pero

no es solo para Fusion Tables, sino para todos los productos que Google mantiene en lo que llama Labs, por lo

que el número de usuarios registrados no nos resulta útil para este estudio.


Dispone de un sistema de control de acceso a los datos similar al resto de Google Docs. De forma

predeterminada, las nuevas tablas se establecen como privadas; sólo las personas que han sido invitadas

específicamente tendrán acceso a ellas. Las visualizaciones incrustadas y otros enlaces a Google Earth no

serán capaces de acceder a los datos.

Las distintas opciones permitidas para controlar el acceso a la tabla son:

� poner la tabla como no exportable

� compartir sólo determinadas columnas (crear una vista)

� hacer la tabla de uso público o restringido (cualquier persona que tenga el enlace)

� mantener la tabla privada

La plataforma no tiene la opción de backup, pero en cambio hace seguimiento de control de cambios,

registrando cada cambio que haga todo usuario con su fecha-hora, por lo que el usuario siempre puede

recuperar una versión anterior, o recuperar datos eliminados por error.

Para el control acceso de Fusion Tables en aplicaciones web se usa OAuth 2.0


Algunos de los estándares que cumple la plataforma son:

− Normas OGC: KML, WGS 84

− Normas ISO: country codes


Fusion Tables está integrado con otros servicios de Google, especialmente Google Docs, por lo que puede

tomar datos dinámicamente de documentos de Google Docs, y al contrario, servir resultados, gráficos y

mapas para que formen parte de otros documentos. Para interactuar con otras aplicaciones y servicios web, se

puede hacer mediante código de incrustación, mediante exportación de ficheros KML o CSV, o también

mediante la URL a formato KML. En este último caso puede actuar como servidor de mapas, por ejemplo para

usar desde Google Earth y desde cualquier servicio o aplicación que admita KML desde una URL.


Página 39 de 60

5.3.2.9 RENDIMIENTO

El motor de visualización de Fusion Tables permite procesar y visualizar 8112 filas en algo más de 30

segundos. En realidad hay una limitación: solo pueden ser visualizadas o incluidas en consultas las primeras

100.000 filas de datos de una tabla. Además hay un límite de 500 vértices por polígono.

Ilustración 16. Rendimiento en Fusion Tables


DISPOSITIVO

Para dispositivos fijos Google Fusion Tables puede ser accedido prácticamente desde cualquier navegador.

La plataforma no está optimizada para dispositivos móviles. No dispone de redirección móvil, meta tag

Viewport, mobile CSS o Apple icon. Sin embargo, Fusion Tables funciona correctamente tanto sobre Opera

Mobile como sobre Android y Safari.


Google Fusion ofrece una API REST que permite manejar las tablas (crear, borrar), gestionar filas de datos

(insertar/actualizar/eliminar), y consultar la tabla para todas las filas que coincidan con las condiciones

especificadas. Los resultados de las consultas pueden volcarse en un archivo delimitado por comas o ser

utilizados en la API de Google Maps o en Google Chart Tools.

Asimismo se puede usar Fusion Tables con otras API:

- API de Google Maps. Los datos que se pueden asignar en Fusion tables pueden ser una capa de un mapa

de Google. Se puede usar la API de Google Maps para incrustar una FusionTablesLayer dentro de una

aplicación web.

- Herramientas de Google Chart. Fusion Tables es una fuente de datos para Google Chart Tools.

En la dirección https://developers.google.com/fusiontables/, se ofrece una completa guía para

desarrolladores. La plataforma proporciona librerías para los lenguajes de programación PHP y Python.

Además, se proporcionan enlaces a ejemplos básicos para cada uno de los lenguajes anteriores y a múltiples

ejemplos de especial interés para la API. Se incluyen artículos y vídeos relacionados y una lista de soluciones a

problemas relativos a esta API.

El equipo de Fusión Tables actualiza periódicamente la API con nuevas características, corrección de errores y

mejoras de rendimiento. Las actualizaciones se muestran por fecha. También existe un Grupo de Usuarios

para la API creado para plantear cuestiones no técnicas acerca de la interfaz.


Página 40 de 60


Fusion Tables es un servicio construido sobre la infraestructura de Google.

No es de código abierto. Google maneja la red, el almacenamiento,

procesadores, sistemas operativos, tiempo de ejecución, los datos de

backend y el software. Google integra MySQL en el servicio de nube. Los

servicios de nube son compatibles con el protocolo JDBC de Java y la API

que puede ser utilizada por las aplicaciones Python. La mayoría de las

aplicaciones están programadas en C++, aunque también utilizan Python

y PHP.

Ilustración 17. Arquitectura de Fusion Tables

Fuente: http://www.cse.ohio-state.edu/~agrawal/788-au10/Papers/Oct28/google-fusion-socc10.pdf


Google Fusion Tables es otro SaaS que Google pone a disposición de sus usuarios. Google se reserva el

derecho de incluir publicidad en sus mapas, y, obviamente, no es de código abierto.

“El principal negocio para nosotros será siempre la publicidad, seguido por la venta de enterprise software y

suscripciones a servicios/apps. No puedo garantizar esto, por que toda empresa tiene que estar preparada

para evolucionar y Google no esta exento de ello”.

Eric Schmidt – Anterior CEO (Chief Executive Officer) de Google.

Público objetivo: Usuarios no expertos, gracias a la accesibilidad a análisis espaciales y de datos

proporcionados por la plataforma, con ciertos conocimientos del idioma inglés.


Página 41 de 60

5.4 IKIMAP. LA PLATAFORMA SOCIAL DE LA CARTOGRAFÍA

Plataforma geoespacial de fuerte componente social diseñada para crear y difundir información geográfica de

forma sencilla, orientada a todo tipo de usuarios.

5.4.1 FICHA BÁSICA

Tabla 6. ikiMap. Principales características

Nombre, versión y URL ikiMap (versión beta) http://ikimap.com/

Autores, año y país de origen Sixtema. 2011, España

Está también en español Si



Foros de discusión Blog, twitter, Facebook





La gestión de los datos comienza con la página de bienvenida de ikiMap desde donde se puede acceder a los

mapas e ikiMapas recientes, los más votados o los más visitados. También aparece un listado de mapas e

ikiMapas agrupados por categorías. Además se pueden realizar búsquedas por cadenas alfanuméricas.

Desde la pantalla de edición de mapas es posible realizar búsquedas de lugares mediante geocodificación. De

este modo, en cualquier momento se puede escribir el nombre de un país, ciudad, lugar, calle, o incluso unas

coordenadas, y automáticamente la plataforma hará zoom sobre esa zona concreta.

Existen dos vías para añadir nuevos mapas a partir de la opción Crear mapa:

a) Dibujar un mapa. Se pueden utilizar herramientas de edición para crear puntos, rutas y polígonos

directamente y aplicarles estilos. El editor permitirá enlazar a cada elemento, contenido multimedia o

realizar cambios rápidos en los mapas sin necesidad de depender de programas externos.

b) Subir un archivo. Se puede añadir un mapa ya creado subiendo un archivo o escribiendo su URL (en el

caso de provenir de un servidor de mapas). Los formatos soportados son: KML, KMZ, SHP, GPX.

No existen opciones de geocodificación para enlazar entidades alfanuméricas y geométricas.


Página 42 de 60


ikiMap, además de presentar la opción de elegir un fondo vacío, soporta doce capas base agrupadas en cuatro

clasificaciones:

− Carreteras: Google, OpenStreetMaps Mapnik, OpenStreetMaps Osmarender, CloudMade Original,

CloudMade Midnight Commander, CloudMade Red Alert y Bing.

− Satélite: Google.

− Híbrido: Google.

− Físico: Google, OpenStreetMaps Cycle map y Metacarta.


Funcionalidades: Posibilita la creación de ikiMapas que integran varios mapas de distintos usuarios en uno

solo, así como la creación de canales, una lista de favoritos, y el etiquetado de mapas para facilitar la

clasificación y las búsquedas.

No proporciona herramientas de análisis ni geocodificación.

Usabilidad. Permite la creación de información geográfica mediante el uso de sencillas herramientas de edición

de mapas, sin olvidar la componente social.


Existe un módulo de edición de mapas que permite modificar o ampliar la información que contienen. Es

posible modificar tanto la geometría como el estilo (color, opacidad y grosor) de un polígono, una línea o un

punto, dando la posibilidad de que coexistan en un mismo mapa gran variedad de iconos, cada uno con su

propia simbología. En un mismo mapa cada elemento puede tener un estilo totalmente distinto; por ejemplo,

pueden combinarse polígonos rojos con líneas verdes e iconos azules.

Existen dos funcionalidades adicionales en la edición de mapas que añaden expresividad, accesibles desde la

barra de herramientas de la edición de mapas.

� Las etiquetas (labels) permiten añadir texto directamente sobre los mapas. Se puede modificar alguno de

sus atributos como el tamaño o color, lo que nos facilita personalizar su apariencia. De este modo se

pueden añadir indicaciones, comentarios y anotaciones a los mapas.

� Las imágenes (overlays) permiten superponer fotografías, mapas rasters, etc. a la cartografía base. Las

imágenes que se añadan deben estar accesibles en Internet mediante una URL. Una vez añadida, se puede

modificar su transparencia, tamaño o ángulo de rotación hasta lograr el ajuste deseado.


ikiMap está diseñada en si misma como una red social de compartición de mapas, por lo que proporciona

funcionalidades de socialización como la de hacer amigos al estilo de Facebook o Twitter, guardar y compartir

mapas favoritos o compartir mapas de temática común en canales. Así, por ejemplo es posible seguir la

actividad de un usuario que crea contenido de interés para otro, haciendo seguimiento de uno de sus canales,

sabiendo cuándo crea un nuevo mapa, qué mapas ha votado, qué ha marcado como favorito o incluso quienes

le siguen a él.

La plataforma se integra con otras herramientas de carácter social. En esta línea ikiMap permite compartir la

información en Facebook o Twitter. Asimismo se hace uso de la API de Facebook a la hora de votar. Es decir,


Página 43 de 60

si se está logueado en Facebook el voto actuará como un “Me gusta” en dicha red social, si se está logueado

en ikiMap el voto se registra en la base de datos de ikiMap, y si se está logueado en las dos el voto contará

para ambas.

Ilustración 18. Compartir con ikiMap

Fuente: http://ikimap.com/

La forma de incrustar contenido es muy sencilla, simplemente hay que copiar el código "Embebido" que

aparece en el panel "Descripción" y pegarlo en el editor HTML del sitio web o blog de destino.

El sitio web es bastante popular en las Redes Sociales.


Desde la ventana de gestión de permisos podemos decidir qué usuarios pueden ver y/o editar los mapas. Las

opciones, tanto para la edición como para la visualización, son:

− Solo yo: el propietario es la única persona que puede editar el mapa.

− Todos: todos los usuarios pueden editar el mapa.

− Personas específicas: sólo los usuarios concretos que el propietario decida pueden editar el mapa.

La búsqueda de usuarios puede realizarse a través del nombre de usuario en ikiMap, a través de la dirección

de correo electrónico, o entre el listado de amigos. En el caso de que la persona a la que queremos añadir

para ver o editar el mapa no sea previamente usuario de la plataforma, se le enviará automáticamente una

invitación a su dirección de correo electrónico.

Ilustración 19. Permisos en ikiMap

Fuente: http://ikimap.com/



- Normas OGC: KML, GML

- Normas W3C: JavaScript, GeoRSS


Página 44 de 60


Integración con OruxMaps. OruxMaps es una aplicación gratuita para dispositivos basados en Android que

pemite crear, navegar y editar mapas, con bastante éxito dentro de su categoría. A partir de la versión

gratuita 4.81, es posible enviar los mapas creados directamente a una cuenta de ikiMap. Algunas de sus

funcionalidades son: visualización de mapas online y offline, creación de nuevos mapas, soporte a GPS

externos y pulsímetros, análisis de rutas, tracking en vivo, soporte de mapas vectoriales, etc.

5.4.2.9 RENDIMIENTO

Primero se ha tenido que convertir el fichero .csv al formato .kml (7867 kB) ya que ikiMap no permite cargar

ficheros delimitados por comas. Para la subida de ficheros existen las siguientes limitaciones:

- Tamaño máximo de fichero: 3MB

- Número máximo de elementos: 700

- Número máximo de coordenadas: 50.000

Dado que el tamaño del fichero supera el máximo permitido, a los 7 minutos salta un error indicando: “Error

en servidor al subir el fichero”.


DISPOSITIVO

Sobre dispositivos fijos es recomendable usar las últimas versiones de uno de los siguientes navegadores:

Opera, Firefox, Chrome, Explorer o Safari.

Se han desarrollado aplicaciones para dispositivos móviles. Ha surgido la colaboración con otros proyectos

importantes del entorno del SIG libre, como la utilización del proyecto gvSIG Mini para la gestión de los mapas

dentro de la aplicación móvil desarrollada para Android.

ikiMap sobre dispositivos móviles no funciona de forma apropiada ni con Opera Mobile ni con Safari; sin

embargo sí funciona adecuadamente sobre Android.

La plataforma no está optimizada para dispositivos móviles. No dispone de redirección móvil, meta tag

Viewport, mobile CSS o Apple icon.


La API de ikiMap está en versión beta, y para tener acceso a ella y conocer mejor sus posibilidades, así como

los lenguajes y plataformas que se pueden utilizar, hay que solicitar una clave de desarrollo. No obstante ya

hay aplicaciones que están integradas con ikiMap a través de esta API, como por ejemplo OruxMaps

(http://www.oruxmaps.com/), un visor de mapas online y offline para Android.

Existe documentación (de momento incompleta) sobre esta API en la siguiente dirección:

http://www.ikimap.com/wikimapi/, donde se explican, agrupados por bloques, los distintos métodos que

proporciona. Existen 6 bloques en donde se aglutinan los métodos de la API de ikiMap: Usuarios, Mapas,

ikiMapas, Canales, Búsquedas y por último Comentarios, Favoritos y otros.

La API de ikiMap trabaja mediante estándares de comunicaciones (HTTP GET/POST y XML), sobre arquitectura

REST, de modo que pueda ser utilizado por aplicaciones en diferentes plataformas.

Para la salida de la información obtenida mediante los métodos se utilizan los formatos JSON o XML según se

solicite mediante parámetro, haciendo que el acceso a los datos de ikiMap se realice de una manera sencilla

desde cualquier tipo de cliente.


Página 45 de 60

Los servicios de API utilizan un mecanismo de autenticación, tanto para identificar las aplicaciones que usan la

API, como para la autorización de acceso a datos privados de usuario.

Ilustración 20. Arquitectura de la API de ikiMap.

Fuente: http://www.sigte.udg.edu/jornadassiglibre2012/uploads/articulos_12/art15.pdf


La plataforma ha sido desarrollada empleando exclusivamente software libre: PostgreSQL y PostGIS cómo

gestor de base de datos, y MapServer cómo servidor de mapas.

Para la presentación e interacción con mapas se utiliza la librería de Javascript OpenLayers, distribuida bajo

licencia BSD para proporcionar mapas interactivos con soporte a numerosos servicios de mapas: Google, Bing,

Yahoo, Cloudmade, OpenStreetMap, etc. Así mismo, OpenLayers proporciona soporte para la presentación de

información en diversos formatos (GML, GeoRSS, GeoJSON, etc), optándose en ikiMap por la utilización de

KML para el envío desde servidor.

Además, el desarrollo de la plataforma implicó el desarrollo de módulos intermedios de parseo empleando los

lenguajes de programación PHP y Javascript. Estos módulos están en fase de pruebas y, una vez superada y

hayan optimizado su rendimiento, está previsto liberarlos.

Dado el avance de los navegadores web actuales en cuanto a soporte de Javascript, así como las tendencias

actuales de optar por éste sobre otras tecnologías como Flash o Silverlight, se escoge Javascript para la

ejecución en cliente. Así mismo, se utiliza tecnología AJAX para la realización de peticiones asíncronas de

datos, obteniendo una comunicación cliente-servidor que proporciona una interacción más fluida para el

usuario.

A continuación se expone un esquema de la arquitectura de módulos de ikiMap.


Página 46 de 60

Ilustración 21. Arquitectura de ikiMap

Fuente: http://www.sigte.udg.edu/jornadassiglibre2012/uploads/articulos_12/art15.pdf


ikiMap es una plataforma gratuita de carácter social creada por la empresa Sixtema. Está basada en

soluciones de software libre: PostGIS, Mapserver y Openlayers, entre otras. El hecho de no tener que pagar

licencias de software permite poder dedicar más recursos al desarrollo.

Sixtema está calificada como Iniciativa de Emprego de Base Tecnolóxica (IEBT) por la Xunta de Galicia, por lo

que ha recibido fondos públicos para el inicio y desarrollo de su actividad, principalmente del Fondo Europeo

de Desarrollo Regional (FEDER), lo cual, junto con premios de organismos públicos, parecen ser de momento

su principal fuente de financiación. Así se desprende de la información proporcionada en:

http://www.ikimap.com/wikimapi/index.php?title=Proxecto_cofinanciado_con_fondos_p%C3%BAblicos,

http://sixtema.es/Fondos02.htm, http://sixtema.es/Reconecementos.htm.

Igualmente, Sixtema ofrece desarrollos y servicios comerciales en las áreas de Sistemas de Información

Geográfica y Consultoría informática, por lo que ikiMap sirve como una plataforma de presentación y

publicidad para la captación de nuevos clientes.

Público objetivo: Usuarios que pretendan compartir sus mapas e interactuar con otros a través de votaciones,

amigos, canales, comentarios, etc.


Página 47 de 60

5.5 SCRIBBLE MAPS. ANOTACIONES VISUALES SOBRE MAPAS

Plataforma geoespacial diseñada especialmente para realizar múltiples tipos de anotaciones gráficas sobre

mapas de forma sencilla, así como personalizar su visualización.

5.5.1 FICHA BÁSICA

Tabla 7. Scribble Maps. Principales características

Nombre, versión y URL Scribble Maps (version beta) http://scribblemaps.com/

Autores, año y país de origen 52 Stairs Studio Inc. 2009, EEUU

Está también en español Si, pero con una traducción bastante deficiente


Número de visitas (SEO, cuwhois) 1.972.020/mes

Foros de discusión groups.google.com/group/scribblemaps, Blog, twitter, Facebook





Dispone de un cuadro de búsqueda con cuatro pestañas, mediante las cuales se puede buscar una ubicación,

una indicación, un negocio o un mapa.

Permite importar archivos KML, CSV, XLS y SHP. Solo permite importar ficheros con datos geográficos en el

sistema de referencia de coordenadas definido por el EPSG:3857, por lo que es necesario procesar primero los

ficheros para poder incorporarlos al mapa. Los ficheros de Excel deben tener campos con las coordenadas

latitud y longitud en el anterior sistema de referencia para poder ser incorporados como puntos de interés.

Un punto fuerte de Scribble Maps es la creación de objetos geométricos: varios tipos de líneas, polígonos,

círculos, marcadores de posición, textos o incluso imágenes georreferenciadas. A todos ellos se les puede

añadir un título y una descripción en HTML.

No hay opciones de geocodificación para enlazar entidades alfanuméricas y geométricas.


Scribble Maps soporta un gran abanico de mapas base, hasta un total de veinte: Google (White y Custom),

Scribble Maps (White y Custom), OpenStreetMap (Mapnik, Osmarender y Cycle Map), CloudMade (Original,


Página 48 de 60

Fine Line, No names y Tourist), CloudMade Plus (Midnight, Pale, Fresh y Red Alert), Astral (Night Sky), Esri

(Satellite, Map, Physical y Topo).


Funcionalidades. Scribble Maps permite personalizar la visualización, así como administrar capas (clasificar en

carpetas, cambiar su orden de presentación, etc.). No dispone de herramientas de análisis GIS ni de

geocodificación.

Usabilidad. La solución es fácil de usar por lo que es muy adecuada para crear mapas sencillos y compartirlos

de forma rápida. No obstante, su sistema de interfaz de usuario es a veces un poco confuso; no tiene un

buen sistema de ayuda, por lo que a veces el usuario tiene que adivinar para qué sirve un diálogo o un botón.


Scribble Maps posee un amplio repertorio de herramientas de edición. Existe la posibilidad de personalizar los

elementos de los mapas base.

La versión básica incluye herramientas de dibujo (líneas, áreas, inserción de fotos, texto, iconos, etc.), de

medida y rotaciones.

Scribble Maps Pro soporta también funcionalidades adicionales de estilo “Custom Styling”, pudiéndose

modificar el color y la opacidad en marcas de posición, líneas y polígonos. Posibilita imágenes overlay.

También muestra información desplegable en viñetas de HTML, así como etiquetas.

No admite representación temática ni posibilita gráficos de datos.


Permite incrustar código en una página web a través de la opción Widget/Embed (recientemente se ha

desarrollado un plugin para Wordpress).

Proporciona botones específicos para

compartir mapas en Blogger, Twitter,

Facebook o correo electrónico.

Finalmente, si se está dado de alta, se

pueden guardar los mapas del usuario.

El sitio web es muy popular en las Redes

Sociales.

Ilustración 22. Compartir con Scribble Maps

Fuente: http://scribblemaps.com/


Scribble Maps usa un sistema muy básico de privacidad, que consiste en permitir bloquear un mapa mediante

la introducción de una contraseña. El desbloqueo del mapa permitirá a otros usuarios modificarlo si saben la

contraseña asignada.



- Normas OGC: KML.

- Normas W3C: JavaScript.


Página 49 de 60


Se pueden exportar datos mediante los formatos KML o GPX.

ScribbleMaps proporciona botones para ver el mapa desde Google Maps o desde Google Earth. El resto de

interacción con servicios externos ha de ser mediante ficheros de intercambio o mediante el código de

incrustación que genera.

5.5.2.9 RENDIMIENTO

Dispone de una buena velocidad de renderizado de los mapas pero a la hora de visualizar el mapa la

plataforma informa que el conjunto de datos tiene más de 1000 puntos, lo que puede tener un gran impacto

en el rendimiento del mapa, recomendando el formato SHP para conjuntos de datos con una gran cantidad de

puntos. Scribble Maps es capaz de procesar 8112 filas en aproximadamente 45 segundos.

No obstante se producen bastantes fallos en la interfaz gráfica; el foro tiene numerosas entradas al respecto.


DISPOSITIVO

Sobre dispositivos fijos es recomendable usar las últimas versiones de uno de los siguientes navegadores:

Opera, Firefox, Chrome, Explorer o Safari.

Sobre dispositivos móviles, Scribble Maps no funciona adecuadamente sobre Opera Mobile; en cambio su

comportamiento sobre Android y Safari es correcto. La plataforma no está optimizada para este tipo de

dispositivos. No dispone de redirección móvil, meta tag Viewport, mobile CSS o Apple icon.


En la actualidad la API está en construcción. La funcionalidad inicial será muy básica, en principio permitir la

recuperación de archivos KML y GPX, y el acceso básico a su infraestructura.


El motor está escrito en C# y basado en el FrameWork .Net 2.0. Para la interfaz gráfica de usuario utiliza

flash. Usa la API de Google Maps, así como tecnología propia y expande los servicios proporcionados por

Google My Maps con herramientas y funciones adicionales.


Las dos versiones de Scribble Maps son gratuitas pero la versión Pro requiere un usuario registrado.

En un intento de encontrar una forma óptima de mantener la plataforma completamente gratis y a la vez

obtener ingresos para apoyar futuros desarrollos y costes de alojamiento, la plataforma ha optado por añadir

anuncios a los widgets, ofreciendo la posibilidad de eliminarlos con un coste adicional.

Público objetivo. Educación. Sus usuarios mayoritarios son profesores y estudiantes.


Página 50 de 60

5.6 TABLA COMPARATIVA ENTRE PLATAFORMAS

CARACTERÍSTICAS CartoDB GeoCommons Google Fusion Tables ikiMap Scribble Maps

Vías de carga de datos

� crear tabla (geolocaliza columnas)

� URL a servidor WMS � .CSV, Shape File, .KML,

.KMZ, .XLS, .XLSX, GeoJSON, .GPX, GPS, .OSM, .BZ2, .ODS, GeoTIFF

� capas publicadas � URL a servidor WMS � KML, Shape File, .CSV

(geolocaliza para EEUU)

� crear tabla (geolocaliza columnas)

� tablas publicadas � .csv, .tsv, KML, Shape

File, hojas de cálculo (.xls, .xlsx, .ods)

� crear geometrías � editar atributos � mapas publicados,

busca texto o geolocalización

� KML, KMZ, SHP, GPX

� crear geometrías � mapas publicados � KML, CSV, TAB, XLS,

Shape File

Opciones para las capas base 4 opciones: Google Maps (Roadmap, Satelite, Terrain y Custom Tiles)

13 opciones: Acetate, Acetate Terrain, OpenStreetMap, Google (x3), MapQuest, Microsoft (x3), Nasa Blue Marble, OSM GeoCache y VMAP GeoCache

3 opciones: Google Maps (mapa, relieve, satétite)

12 opciones: � Carreteras (x7) � Satélite, � Híbrido, � Físico (x3)

22 opciones: � Google Maps (x4), � Scribble Maps (x2), � OpenStreetMap (x3), � CloudMade (x4), � CloudMade Plus (x4), � Astral, � Esri (x4)

Valoración de: 1. funcionalidades 2. usabilidad

1. Alta: análisis avanzado, geocodificación, gestión de tablas, etc.

2. Baja: requiere aprendizaje de CartoCSS y SQL

1. Alta: análisis avanzados muy automatizados, no hay edición

2. Alta: interfaz sencillo e intuitivo

1. Media: no es GIS, sino BD

2. Media: manejo directo de las tablas

1. Baja: ni tablas ni análisis

2. Muy alta: muy sencillo de aprender y usar

1. Baja: ni tablas ni análisis

2. Alta: similar a aplicaciones de dibujo vectorial

Capacidades de estilo y representación en los mapas

� estilos básicos � cartografía temática � viñetas en texto plano � lenguaje de estilos

� estilos básicos � cartografía temática � viñetas en HTML y

campos � gráficos de datos

� estilos básicos � cartografía temática � viñetas en HTML y

campos, edición de plantilla

� gráficos de datos

� estilos básicos � viñetas en HTML � anotaciones de texto

� estilos básicos � viñetas en HTML � imágenes overlay � estilos de mapa base � anotaciones de texto,

dibujo y medidas

Opciones para la difusión de mapas en redes sociales y otros medios externos

� <iFrame> � enlace

� <iFrame> o <script> � enlace � envío a F, T, AddThis

� <iFrame> � enlace a tabla � enlace a mapa � comentarios por celdas

� <iFrame> � enlace � envío a B, F, T, � votos F, T, +1 � favoritos, canales

� <script> � enlace � envío a B, T, email, F � plugin WordPress

Políticas de seguridad: control de acceso a los datos y backups

� acceso OAuth y SSL � opción de tablas privadas � opción de backup

� permisos por roles � permisos por datasets � niveles de acceso: Edit,

Access, Find

� compartición de vistas (columnas elegidas)

� acceso público, privado o restringido

� control de cambios

� permisos por nombres de usuarios

� permisos para ver o para editar

Bloqueo de mapas por contraseña


Página 51 de 60

CARACTERÍSTICAS CartoDB GeoCommons Google Fusion Tables ikiMap Scribble Maps

Cumplimiento con estándares

� OGC: KML � W3C: HTML5 � ISO: SQL No está orientado a cumplir estándares

� OGC: KML, WMS, TMS, CSW

� W3C: microformatos, JS, RSS, GeoRSS,

� ISO: PDF, metadatos

� OGC: KML, WGS 84 � ISO: 3166 (country

codes)

� OGC: KML, GML � W3C: JavaScript,

GeoRSS

� OGC: KML � W3C: JavaScript

Interoperabilidad con otras plataformas o servicios externos

� exporta: CSV, KML, SHP, y SQL

� móvil: Leaflet (HTML5, CSS3)

� Google Maps v3: WAX de MapBox

� iPad: WhirlyGlobe

� exporta: SHP, CSV, KML, GeoRSS Atom, Spatialite y JSON

� móvil: Appcelerator � BD: Oracle, MySQL,

PostgreSQL, ESRI, MongoDB

� exporta: KML, CSV � Google Docs � servidor KML dinámico

� exporta: KML � Android: OruxMaps � servidor MapServer

exporta: KML, GPX

Rendimiento bueno muy bueno bastante bueno regular lento

Capacidad de trabajo en múltiples navegadores web y tipos de dispositivo

� mal: Opera Mobile � bien: Android, Safari � Metatag Viewport � Redirección móvil

� mal: Opera Mobile � bien: Android, Safari � Redirección móvil

� mal: � bien: Opera Mobile,

Android, Safari

� mal: Opera Mobile, Safari

� bien: Android,

� mal: Opera Mobile � bien: Android, Safari

Valoración de la API para programadores: 1. lenguajes; 2. documentación; 3. ejemplos

1. SQL, Ruby, JavaScript, PHP, Python, Java, .Net

2. bien 3. bien

1. HTTP, JavaScript 2. bien 3. bien

1. SQL, HTML, JavaScript, PHP, Python

2. bien 3. bien

1. JavaScript 2. incompleta 3. no hay ejemplos

1. JavaScript (en desarrollo)

2. no 3. no

Tecnologías subyacentes

Mapnik, NodeJS, PostGIS, Postgres, Redis, Varnish, Ruby, HTML5, GeoJSON, Vecnik

Ruby, Rails, Mapnik, JQuery, ModestMaps, Python, ImageMagick, Yajl, GEOS, GDAL y PROJ4, OpenSearch, SQLite

Google Cloud, MySQL PostgreSQL, PostGIS, OpenLayers, MapServer, PHP, JS, AJAX

Google Maps API, Sharp Map, .Net 2.0 C#

Modelo de negocio - Gratuita para tablas públicas - planes de pago

- límites de uso gratuito - servicios adicionales

- Gratuita - publicidad a Google

- Gratuita - financiación pública - publicidad a Sixtema

- Gratuita con publicidad


Página 52 de 60

6 SIG TRADICIONAL VS SIG EN NUBE

Una vez estudiado en detalle cómo funciona un SIG tradicional y analizadas las características técnicas de las

plataformas de publicación de información geográfica en la nube, las comparamos con los SIG tradicionales

para detectar hasta qué punto una plataforma online sustituye o complementa al enfoque tradicional SIG en

el ámbito de la publicación y difusión de mapas.

Ventajas de las plataformas de publicación de información geográfica en la nube:

Estas plataformas constituyen un autoservicio bajo demanda ya que no es necesario interactuar con el

personal del proveedor de servicios en la nube, proporcionan un acceso amplio desde la red a los recursos de

la nube, los sistemas físicos y virtuales se asignan de forma dinámica según sea necesario y existe una

elasticidad rápida para la suministración de recursos. Proporcionan fiabilidad, ahorro de costes y un

mantenimiento y actualización muy simplificados.

Además constituyen un servicio medido ya que al cliente se le puede cobrar en base a una métrica conocida,

como la cantidad de almacenamiento, el número de transacciones, el ancho de banda, etc.

Otras ventajas, no menos importantes, son su facilidad de utilización y especialmente de publicación,

compartición y difusión.

Inconvenientes de las plataformas de publicación de información geográfica en la nube:

El almacenamiento de tipo empresarial está bajo el control de un sistema interno y puede soportar búsquedas

de alta velocidad; en la nube es posible almacenar grandes volúmenes de datos pero los costes aumentan si

se requieren conexiones con gran ancho de banda y líneas de respaldo que garanticen la continuidad.

Cuando hay que transferir conjuntos grandes de datos se pueden producir cuellos de botella en la red. En un

SIG tradicional, las operaciones que se llevan a cabo dentro de las organizaciones usan LAN, que dispone de

más capacidad para albergar transferencias que las conexiones WAN que emplea la nube.

Para garantizar la privacidad de datos en la nube, son necesarios métodos de seguridad adicionales tales

como cifrado privado, VLAN, cortafuegos, entre otros.

Otra limitación viene impuesta por las exigencias de las leyes y normativas de las Administraciones Públicas,

que las plataformas web no suelen contemplar. Por ejemplo, en España es obligado que toda referencia

geográfica dirigida a un organismo oficial esté expresada en coordenadas UTM, mientras que las plataformas

en la nube no suelen admitir esa opción.

Conclusión final. Las ventajas de la nube son más patentes en el caso de organizaciones pequeñas. Las

grandes organizaciones pueden soportar personal especializado en SIG y esfuerzos de desarrollo que pongan

en práctica soluciones de software personalizadas, creadas pensando en las necesidades de los clientes.

Aunque las aplicaciones en la nube ya destacan en tareas de procesamiento a gran escala y aportan gran

facilidad para la publicación, si nuestra aplicación necesita grandes volúmenes de transferencia de datos,

altos niveles de seguridad o necesidades específicas de análisis y procesamiento, la computación en la nube

podría, no ser de momento, el modelo más adecuado.


Página 53 de 60

7 CASO DE ESTUDIO Y PROTOTIPO

El estudio detallado de plataformas realizado en el apartado anterior tiene por principal objetivo encontrar la

plataforma idónea para publicar noticias georreferenciadas en una pequeña organización sin los medios

técnicos ni el presupuesto necesarios para explorar opciones costosas.

7.1 ESPECIFICACIÓN DE REQUISITOS

La organización objeto de nuestro estudio es un medio de comunicación local que pretende desarrollar un

sitio web informativo en el que poder ubicar en un mapa las noticias que suceden en el municipio (eventos

culturales, mapas de obras, etc.), además de permitir la participación ciudadana (quejas al ayuntamiento,

objetos perdidos, etc.) y lograr la difusión de sus mapas en redes sociales y blogs.

Se debe tener en cuenta que los editores no poseen conocimientos informáticos avanzados, por lo que se

necesitará una interfaz amigable y sencilla.

Normalmente no se necesitará manejar grandes volúmenes de datos ni realizar análisis geoespacial. Los

gráficos de sectores o de barras tampoco son habituales en periódicos locales, sólo en prensa un poco más

especializada.

En cambio se necesitará expresividad, poder hacer anotaciones, especialmente de texto, sobre el mapa,

poner iconos que representen simbólicamente lo que se quiere, dibujar trayectos por las que ha transcurrido

algún suceso, etc.

7.2 ANÁLISIS DE REQUISITOS

En base a los requisitos anteriormente especificados analizaremos la idoneidad de cada plataforma.

CartoDB. Lenguaje de estilo + Lenguaje de datos, orientado a scripts.

Presenta grandes ventajas en cuanto a la entrada de datos; permite crear una tabla vacía e ir añadiendo filas,

subir un archivo desde un buen número de tipos de fuente de datos o importar desde una URL. Permite

visualizar los datos usando técnicas de cartografía temática. Tiene funcionalidades avanzadas como la

geocodificación o el análisis geoespacial.

Sin embargo no permite la edición de elementos geográficos (líneas o áreas); la interfaz de usuario es muy

básica; para acceder a la mayor parte de sus funcionalidades hay que usar CartoCSS. No tiene demasiadas

opciones para las capas base. Está muy limitado el número de tablas para las cuentas gratuitas y los niveles

de suscripción más baratos. No admite HTML en la información desplegable, lo que implica que no se pueden

mostrar imágenes o enlaces.

Está más orientado a desarrolladores expertos.

Geocommons. Análisis y procesamiento fácil y potente.

Posee una interfaz gráfica muy intuitiva. Es una plataforma geoespacial muy potente para la gestión,

visualización y análisis de datos para su uso por usuarios tanto expertos como inexpertos. Permite visualizar

los datos usando técnicas de cartografía temática. Los mapas base disponibles son muy variados. En cuanto a

la entrada de datos permite cargar ficheros desde numerosos tipos de fuentes de datos. Puede trabajar con

puntos, líneas y polígonos, también permite añadir un enlace URL desde la web. Muestra bien la información


Página 54 de 60

desplegable, con una pestaña para HTML y otra para campos de datos. Proporciona botones para difusión en

redes sociales.

Sin embargo no permite edición de tablas ni de elementos espaciales; además sólo geocodifica en Estados

Unidos.

Fusion Tables. Trabajo colaborativo, segmentación e integración de datos.

La interfaz gráfica de la aplicación es bastante intuitiva. Permite visualizar los datos usando técnicas de

cartografía temática. Los mapas base disponibles son escasos, aunque es la única de las plataformas

analizadas que permite su selección desde un mapa incrustado. En cuanto a la entrada de datos, permite

cargar ficheros desde numerosos tipos de fuentes de datos. Puede trabajar con puntos, líneas y polígonos.

Permite editar tablas y posibilita la geocodificación. Muestra bien la información desplegable, tanto HTML

como campos de tablas, pudiendo gestionar qué se muestra y cómo mediante plantillas.

Sin embargo no tiene herramientas de edición manual sobre el mapa; sólo modificando tablas. No está

diseñado como un gestor de SIG. No proporciona botones para difusión en redes sociales distintas a las de

Google.

De su nombre y su documentación se desprende que está más pensado para trabajo con tablas y poco para

anotaciones, edición o publicación en redes sociales (que no sea la propia de Google, +1).

IkiMap. Red social basada en compartición de mapas.

La interfaz gráfica de la aplicación es muy sencilla y por lo tanto bastante intuitiva. Hay una gran variedad de

mapas base disponible. En cuanto a la entrada de datos permite dibujar un mapa utilizando herramientas de

edición para crear puntos, rutas y polígonos. Permite cargar ficheros desde el propio ordenador desde varios

tipos de fuentes de datos. Muestra bien la información desplegable en HTML, incluyendo imágenes y enlaces.

Proporciona botones para difusión en redes sociales.

Sin embargo no se incluye como posibilidad el cargar un fichero .csv, ni permite visualizar los datos usando

técnicas de cartografía temática. No incluye opciones de análisis.

Scribble Maps. Anotaciones visuales sobre mapas: dibujos, textos e imágenes.

Tiene la facilidad de crear y editar elementos espaciales y hacer anotaciones (dibujos, texto, iconos) sobre el

mapa. Es la única en la que se pueden insertar imágenes overlay georreferenciadas. Dispone de buenas

opciones para la difusión en redes sociales. Muestra bien la información desplegable en HTML.

Sin embargo la interfaz gráfica de la aplicación no es demasiado intuitiva. Presenta defectos de

funcionamiento, falta de mantenimiento, lentitud, poca claridad en algunos diálogos. La documentación es

escasa. No permite geocodificación ni opciones de análisis.

7.3 SELECCIÓN DE UNA PLATAFORMA

Un requisito importante para la organización es que la plataforma permita el posicionamiento de marcas y la

creación de líneas y áreas por si misma, sin tener que acudir a herramientas externas. Eso limita las

plataformas candidatas a dos: ikiMap y Scribble Maps.

Si además consideramos como requisito imprescindible la posibilidad de participación ciudadana, se hace

obligatorio que cualquier usuario, y no solo el editor o periodista, pueda crear elementos geográficos con

texto adjunto, lo que fuerza a descartar las otras tres plataformas: CartoDB, GeoCommons y Fusion Tables.


Página 55 de 60

Conviene para ello que además el sistema de permisos de acceso sea robusto. Scribble Maps carece de un

sistema de gestión de permisos. El de ikiMap es básico pero suficiente, hasta el punto de ser el único que

permite otorgar permiso de edición de un mapa a todos los usuarios registrados (lo cual es una opción muy

aventurada, pues un usuario podría borrar lo que hizo otro).

ikiMap permite que los mapas creados por distintos usuarios se integren como capas de un solo ikiMapa, lo

cual si que puede ser un buen mecanismo para que los ciudadanos creen mapas, los compartan con el medio

informativo, y éste los integre en un ikiMap y los publique. Puede servir, por ejemplo, como sistema de

recogida de quejas por calzadas o mobiliario urbano en mal estado, así como para objetos perdidos u otras

necesidades de participación.

Por último, uno de los objetivos principales del medio informativo es lograr la máxima difusión de sus mapas.

Precisamente ikiMap está diseñada con ese objetivo como criterio primordial. Para ello proporciona tres tipos

de mecanismos.

Por una parte los mecanismos dirigidos a usuarios de la plataforma, que son un sistema de votación, la

posibilidad de agregar mapas a una lista de favoritos, la creación y seguimiento de canales al estilo de

YouTube, y la posibilidad de dejar comentarios en mapas de otros usuarios.

Por otra parte, proporciona, al igual que el resto de plataformas, un enlace URL para enviar y un código HTML

para incrustar en otros sitios web.

Y por último, más importante y efectivo para la difusión, incorpora botones para votar el mapa o ikiMapa en

Facebook («Me gusta»), en Twitter y en Google +1, así como para enviarlo directamente a Blogger, Facebook

y Twitter.

La carencia de ikiMap de adjuntar datos en tablas, hacer análisis o realizar cartografía temática, como mapas

de colores o de burbujas, no impide los requisitos principales, y al contrario, hace que la plataforma sea más

sencilla de usar y de entender, lo cual también es un requisito. Además siempre se puede acudir a

herramientas externas para tales fines e importar el resultado en Ikimap a través de ficheros KML.

Por todos estos criterios, la plataforma seleccionada para los objetivos del medio informativo local es

ikiMap.

7.4 IMPLANTACIÓN EN LA ORGANIZACIÓN

En primer lugar es necesario que la organización se registre como usuario de la plataforma ikiMap. Para ello

debe entrar en la página http://www.ikimap.com/registro.php e introducir un nombre de usuario, una

dirección de correo electrónico y una contraseña, y por último leer y aceptar las condiciones de uso. Se

presupone que la organización ya cuenta con un sitio web funcionando, sobre el que va a añadir nuevas

funcionalidades.

La implantación consistirá básicamente en definir una serie de mecanismos o procedimientos bien

diferenciados, asignarlos a diferentes roles dentro del personal de la organización y dar la formación

apropiada que les permita trabajar de forma autónoma en el futuro.

Entendiendo los roles como una agrupación lógica de procedimientos para maximizar la independencia entre

tareas, sin que ello signifique que sean puestos de trabajo diferentes, y poder hacer seguimiento de

responsabilidades, que sería obligatorio si existe o se quiere certificación de calidad ISO 9000, estos roles y

procedimientos son los siguientes:


Página 56 de 60

− Redactor. Se encarga de la confección de las noticias o eventos, asignando a cada una información de

geolocalización, bien por direcciones postales o bien por coordenadas geográficas. No necesita acceso a la

cuenta en ikiMap ni a la cuenta en el sitio web, aunque puede otorgársele si se considera que ello facilita

su labor. El producto, noticias geolocalizadas, lo entregará a un integrador de mapas. La información de

posición adjuntada servirá para elaborar un mapa desde el que podrán accederse las distintas noticias o

eventos. Si la noticia requiere más información geográfica que una simple posición, entregará la redacción

a un editor de mapas.

− Editor de mapas. En el caso de noticias que requieran representación geográfica más compleja que un

solo punto, se hace necesario un mayor dominio de las herramientas de edición de mapas proporcionadas

por la plataforma. Es necesario que tenga acceso a la cuenta de la organización en la plataforma ikiMap.

Entregará su producto, un mapa KML adjunto a una noticia en HTML, directamente al maquetador web.

− Integrador de mapas. Se encarga de recopilar la información de posición aportada por los redactores,

integrando varias noticias o eventos en un solo mapa. Además recoge los mapas aportados por los

ciudadanos, verifica que sean correctos y adecuados, y construye los ikiMapas correspondientes. Es

necesario que tenga acceso a la cuenta de la organización en la plataforma ikiMap. Entregará el producto

de su labor al maquetador web.

− Maquetador web. Su cometido es incrustar los mapas en el sitio web de la organización, a partir del

código de incrustación aportado por los integradores y los editores de mapas, de forma que aparezcan

correctamente integrados con el resto de elementos en el contexto de la noticia o sección donde se

incluyan. Es necesario que tenga acceso a la cuenta de usuario de la organización en su sitio web. En

cambio, no necesita acceso a la plataforma ikiMap, aunque puede otorgársele si se considera adecuado.

La división en roles es conceptual, pudiendo recaer más de un rol sobre una misma persona, lo cual sería

apropiado especialmente en el caso de una organización pequeña con poco personal y poco volumen de

publicación, como es el caso de nuestro ejemplo.

7.5 DESARROLLO DE UN PROTOTIPO FUNCIONAL

A los efectos de demostración del uso de la plataforma seleccionada sobre un blog de información municipal

se ha elaborado un prototipo sencillo que recoge las necesidades principales especificadas por la organización.

Para simular el sitio web informativo se ha elegido Blogger por tratarse de un sistema de gestión de contenido

sencillo con amplias funcionalidades y estilos visuales atractivos. Para ello se creó el subdominio

http://tierraynube.blogspot.com.es/ sobre el cual está alojado el prototipo.

La organización de la información se ha estructurado en varias secciones, cada una de ellas asociada a una

pestaña de menú.

− Noticias. En ella se da valor añadido a las entradas informativas mediante la incorporación de información

geográfica. Se hace uso de la importación de un fichero con varios campos de datos geolocalizados.

− Cultura y ocio. Se posibilita la búsqueda espacial de los eventos culturales del mes en el municipio. La

información de cada evento se muestra como texto enriquecido HTML sobre marcas de posición.

− Incidencias en la vía pública. Se muestra los posibles cortes al tráfico y otras incidencias. En este mapa se

recoge distintos tipos de elementos geográficos (marcas de posición y líneas), así como diferentes estilos.


Página 57 de 60

− Objetos y animales perdidos. Un ikiMapa recoge los mapas enviados por ciudadanos informando de sus

pérdidas en el área delimitada por un polígono. Muestra la posibilidad de interacción de los habitantes del

municipio con el medio informativo.

− Quejas al Ayuntamiento. Un ikiMapa recoge las quejas enviadas por los ciudadanos en forma de mapas.

Muestra la posibilidad de interacción de los habitantes del municipio con el medio informativo, en este

caso haciendo uso de imágenes overlay.

− Acerca de. Avisa de que el sitio web es un prototipo demostrativo.

En la siguiente figura se puede apreciar la estructura de Tierra y Nube.

Ilustración 23. Prototipo funcional del blog municipal

Fuente: http://tierraynube.blogspot.com/

8 LÍNEAS DE CONTINUACIÓN

Enfocado a la mejora de las prestaciones del blog, podrían considerarse las siguientes líneas de continuación:

- Proponer una segunda plataforma para incorporar nuevas funcionalidades avanzadas, por ejemplo de

análisis. Para ello la plataforma candidata es Geocommons.

- Desarrollar un mashup propio usando el API de la plataforma para incorporar funcionalidades no

proporcionadas por el mapa incrustado, por ejemplo para facilitar la participación ciudadana sin que el

ciudadano tenga que registrarse en ikiMap ni conocerlo, brindándole directamente un mapa donde pueda

incluir los elementos espaciales que necesite.

- Desarrollar la versión móvil del sitio web, en particular la visualización y manejo de sus mapas,

explorando las posibilidades de gvSIG Mini o de jQuery Mobile en combinación con OpenLayers.

- Conectar el sistema con otras fuentes de información externas, por ejemplo sindicación de contenido

geográfico (geoRSS).


Página 58 de 60

9 CONCLUSIONES

La realización de este Trabajo Final de Carrera, en el área de los Sistemas de Información Geográfica me ha

resultado muy gratificante ya que gracias a los conocimientos y destrezas adquiridos he experimentado una

evolución en mi manera de pensar y concebir la geografía.

Y lo más importante, creo que el fin de este trabajo supone el principio de una nueva vocación, que espero

seguir cultivando en el futuro, sin prisas, sin tensiones, sin entregas,…

Y estoy satisfecha porque el trabajo desarrollado me ha permitido conocer los fundamentos básicos de los

SIG (objetivo G1, capítulos 2 y 3) y la problemática de la gestión de información geográfica, en particular de

su proceso de publicación en Internet (objetivo G2, capítulo 2); he reflexionado sobre el concepto de

computación en la nube aplicado a la información geográfica y sus implicaciones en las organizaciones

actuales (objetivo G3, capítulo 4) y he aplicado los conocimientos adquiridos sobre las plataformas a la

resolución de las necesidades concretas de una organización (objetivo G4, capítulo 7).

La realización de este trabajo de investigación (objetivo E1) me ha permitido conocer y comparar cinco

plataformas de publicación de información geográfica en Internet (objetivo E2, capítulo 5) como paso previo

para ser capaz de seleccionar la más adecuada a un contexto específico (objetivo E3, capítulo 7).

Además, durante el proceso de prueba de las plataformas ha sido necesario manejar herramientas para la

visualización y gestión de datos geográficos como Google Earth y explorar un software SIG libre, el Quantum

GIS, para detallar sus funciones básicas desde el punto de vista de un SIG tradicional (objetivo E4, capítulos

2 y 5). Este estudio me ha capacitado para comparar los SIG tradicionales con los SIG en la nube (capítulo 6)

y argumentar ventajas e inconvenientes de ambos modelos.

Por último, el TFC me ha permitido desarrollar ciertas destrezas, adquiriendo una serie de competencias

básicas tales como aprender a realizar una correcta planificación con la elaboración de un plan de trabajo

previo a la investigación, gestionar un proyecto de análisis técnico de manera “casi autónoma” (con la ayuda

inestimable de mi consultor Víctor Velarde) y evaluar diferentes alternativas para elegir la idónea en base a

unos criterios especificados.

Todo ello ha desembocado en la redacción de este documento que he intentado que sea lo más objetivo,

riguroso y sintético posible.


Página 59 de 60

10 GLOSARIO

API. Application Programming Interface o Interfaz de Programación de Aplicaciones. Conjunto de funciones

y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca (o librería)

para ser utilizado por otro software como una capa de abstracción.

CSV. Comma Separated Values. Fichero de texto con valores separados por comas.

CSW. Web Catalogue Service (Servicio de Catálogo web). Define una interfaz común para la recuperación,

captura y consulta de metadatos referentes a datos, servicios y recursos geográficos

GML. Geography Markup Language o Lenguaje de Marcado Geográfico, descrito como una gramática en

XML Schema para el modelaje, transporte y almacenamiento de información geográfica

GPX. GPS eXchange format, formato XML para el intercambio de datos GPS (waypoints, tracks, routes)

entre aplicaciones. Hoy en día es el formato más empleado para el intercambio de información entre

dispositivos GPS.

KML. Keyhole Markup Language, Lenguaje XML utilizado inicialmente por Google Earth para representar

datos geográficos en tres dimensiones empleado masivamente en la red para compartir información

cartográfica, y que ya en 2008 se convirtió definitivamente en nuevo estándar aprobado por la OGC.

OAUTH. Open Authorization. Protocolo abierto que permite autorización segura de un API de modo estándar

y simple para aplicaciones de escritorio, móviles, y web. Proporciona a los usuarios un acceso a sus datos al

mismo tiempo que protege las credenciales de su cuenta.

OGC. (Open Geospatial Consortium). Organización internacional participada por empresas e instituciones

del sector de la información geográfica enfocada a la definición de estándares de interoperabilidad (datos y

procesos).

REST API. Representational State Transfer API, es una API, o librería de funciones, a la que se accede por el

protocolo HTTP, es decir, a través de direcciones web o URLs en las que enviamos los datos de nuestra

consulta. Como respuesta a la consulta sobre el REST API se obtienen datos en diferentes formatos, como

pueden ser texto plano, XML, JSON, etc.

SHAPEFILE. Formato de datos geográficos vectoriales de ESRI, formado por varios ficheros, siendo los

principales los siguientes: .shp (con las entidades geométricas), .dbf (atributos de los objetos) y .shx (índice

de entidades geométricas).

SIG/GIS. Sistemas de Información Geográfica / Geographic Information Systems

SSL. Secure Socket Layer. Protocolo que proporciona sus servicios de seguridad cifrando los datos

intercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico, y cifrando la clave de

sesión mediante un algoritmo de cifrado de clave pública.

WCS. Web Coverage Service (Servicio de Cobertura Web) proporciona una interfaz para realizar peticiones

de cobertura geográfica a través de la web utilizando llamadas independientes de la plataforma.

WFS. Web Feature Service, proporciona la información relativa a la entidad almacenada en una capa

vectorial (cobertura) que reúnen las características formuladas en la consulta.

WMS. Web Map Service, produce mapas en formato imagen a la demanda para ser visualizados por un

navegador web o en un cliente simple.

WPS. Web Processing Service. Servicio del OGC para la ejecución remota de geoprocesos.


Página 60 de 60

11 BIBLIOGRAFÍA

BOTELLA PLANA, A. Tendencias actuales en SIG. UOC (P07/89036/02932)

CAPEL, H. (2010). Geografía en red a comienzos del Tercer Milenio. Por una ciencia solidaria y en colaboración. Scripta Nova. Revista Electrónica de Geografía y Ciencias Sociales. [En línea]. Barcelona: Universidad de Barcelona, 1 de febrero de 2010, vol. XIV, nº 313 [ISSN: 1138-9788 1138-9788]. http://www.ub.es/geocrit/sn/sn-313.htm

CERDA SEGUEL, D. (2008). Tierra, sentido y territorio: La ecuacion geosemántica.

http://www.uazuay.edu.ec/bibliotecas/publicaciones/UV-49_Geomatica.pdf

CONESA GARCÍA, C. (1996). Papeles de Geografía, nº 23-24, pags. 101-115. Áreas de aplicación

medioambiental de los SIG. Modelización y avances recientes.

GOODCHILD, F. (2007) "Citizens as Sensors: The World of Volunteered Geography". Festival International

de Geographie, St-Dié-des-Vosges, France, Octubre 2007.

GUTIÉRREZ PUEBLA, J. Y GOULD, M. (1994) SIG: Sistemas de información geográfica.

LONGLEY, P. (2005). Geographic Information Systems and Science

LÓPEZ-GALIACHO, E. (2009) Mapas de las nuevas geografías. Fronterad revista digital [en línea]

http://www.fronterad.com/?q=mapas-galiacho&page=0,0

ORELLANA, D. y BALLARI, D. (2009). Camino hacia la GeoWeb. Un marco de análisis en tres dimensiones.

http://wu.academia.edu/DanielOrellana/Papers

RODRIGUEZ LLORET, J. y OLIVELLA, R. Introducción a SIG y geotelemática. UOC (P07/89036/02927).

Introducción a los Sistemas de Información Geográfica. UOC (P07/89036/02930).

RODRÍGUEZ PASCUAL, A. (1993). “Proposición de una definición profunda de SIG”. II Congreso de AESIG.

Los Sistemas de Información Geográfica en el umbral del S XXI. Madrid.

SÁNCHEZ DÍAZ, F. Mapas colaborativos en la web social [en línea].

http://www.iaph.es/Patrimonio_Historico/cd/ficheros/561/ph%2077-152.pdf

SEOKCHAN, Y. (2007) The User-participated Geospatial Web as Open Platform. Naples: The 11th

International Seminar on GIS

SOSINSKY, B. (2011). Cloud Computing Bible.

TURNER, A. J. (2006). Introduction to neogeography. O’Reilly Media, Inc.

VELARDE GUTIÉRREZ, V. (2011). Curso de experto en desarrollo y gestión de Sistemas de información

geográfica (31-EX-75). Universidad de Cantabria.

ZOOK, M. - M. GRAHAM. (2007). The Creative Reconstruction of the Internet: Google and the Privatization

of Cyberspace and DigiPlace. GeoForum

VI Jornadas de SIG Libre. Girona. (2012). [en línea]

http://www.sigte.udg.edu/jornadassiglibre2012/programa/jornadas

UOC (2012). Aula virtual. Tablón y foro del TFC. Enunciado del TFC “Análisis de plataformas para la

publicación de información geográfica en la nube.”

UOC. “Trabajos y Proyectos Finales de Carrera en Sistemas de Información Geográfica”. Repositorio O2 de la

Biblioteca Virtual de la UOC, <http://openaccess.uoc.edu/webapps/o2/handle/10609/36>

universitat oberta de catalunya -...

Documents