martes, 25 de abril de 2017

Viajes a medida por Europa


¿Por qué elegir Europa como nuestro destino para viajes de aventura organizados a medida?

La primera respuesta es sencilla, por la seguridad que nos ofrece y por la avanzada infraestructura turística con la que cuenta. Con una de las tasas más bajas de delincuencia del mundo y con la red de transporte más desarrollada del planeta, con trasportes por carretera, tren, barco, avión a cualquier punto del continente y en la mayoría de casos sin fronteras, sin visados y con plenos derechos como ciudadano de la Unión Europea y con un marco jurídico incomparable que nos permite viajar con tranquilidad por toda Europa como si nos encontráramos en nuestro propio país.

La vasta extensión de territorio que se extiende de norte a sur y de este a oeste nos deja claro la variedad de climas, ecosistemas, relieves y culturas que podemos encontrar dentro del marco geográfico europeo, desde los gélidos y espectaculares fiordos noruegos en el norte, cerca del círculo polar, hasta las playas de arena blanca y sol radiante de la costa onubense del sur de España.

Desde las Islas Madeiras portuguesas en pleno océano atlántico, hasta el oeste hasta las antiguas exrepúblicas soviéticas ahora convertidas en unos estados miembros más de la Unión Europea.

Si además eres un amante del turismo activo y de aventura, en Europa encontraremos una extensa oferta para realizar este tipo de turismo, con todo lo que necesites y en condiciones óptimas de seguridad.

Existen multitud de agencias de viajes especializadas en Europa, sin embargo, solo unas pocas de las que encontramos online se encargan de organizarnos un viaje a medida relacionado con el turismo activo y de aventura.

Debido a las características particulares del turismo activo y de los viajes a medida, existen una serie de cuestiones que todo viajero debe plantearse a la hora de organizar su viaje, o más bien a la hora de elegir al profesional o al equipo de profesionales que se encargará de organizar nuestro viaje.

A continuación, te explicamos algunas claves:

  • Debemos elegir a una agencia que tenga experiencia y conozca bien los destinos a los que nos dirigimos y el tipo de actividad o actividades que pretendemos desarrollar una vez lleguemos.

  • Es recomendable elegir a una agencia que disponga de personal cualificado capaz de comunicarse en nuestro idioma y a poder ser autóctono del país al que viajaremos.

  • También es importante contar con una persona de contacto de la agencia en el propio destino al que viajemos, de forma que podamos obtener su ayuda fácilmente en el caso de que surgiera algún tipo de problema.

  • Desconfía de los chollos, organizar un viaje a medida por Europa para hacer turismo activo, implica una serie de costes si queremos que nuestro viaje sea un éxito y no encontrarnos con sorpresas inesperadas.

En lo que se refiere a los viajes a medida por Europa, sin duda una de las mejores alternativas es senderismoeuropa.com.

Se trata de una agencia de viajes online especializada en la organización de viajes a medida por Europa, principalmente viajes de aventura, para hacer deportes en plena naturaleza.

Sus especialidades son el senderismo y trekking pero también ofrecen rutas en bicicleta de montaña, escalada, espeleología, descenso de ríos y viajes para la observación de Aves.

Su destino principal y sobre el que más rutas han organizado es Bulgaria y la zona de los Balcanes.

 Si prefieres viajar por libre, te recomiendo que utilices nuestras aplicaciones para Android "Rutas Senderismo" y "Rutas MTB".

Captura de pantalla en un móvil Android de la app Rutas Senderismo, con miles de rutas por Europa


Europa es un continente muy completo que con la ayuda de los profesionales adecuados puedes satisfacer las necesidades de ver nuevos lugares y de vivir aventuras de todo tipo de viajeros.

martes, 4 de octubre de 2016

SQL Espacial y PostGIS para apps móviles

SQL Espacial para aplicaciones móviles

El SQL espacial es la base para desarrollar aplicaciones basadas en la localización, que permitan a sus usuarios consultar elementos que se encuentren a su alrededor, o cerca de un lugar, expresado éste por su nombre (París, Parque Nacional de Ordesa, Francia, etc). Recientemente hemos publicado varias aplicaciones Android que precisamente hacen uso del SQL espacial.

En estas aplicaciones, como por ejemplo en "Rutas MTB", los usuarios pueden realizar dos tipos de búsquedas relacionadas con la localización:
  • Búsqueda "Cerca de tí".
  • Búsqueda de "elementos cerca de una referencia geográfica".
Antes de ver el detalle de como implementar estas búsquedas con SQL, hay que hacer una aclaración: los datos a consultar residen en un servidor. Desde la app móvil se envían peticiones a un servicio web que reside en el servidor, y éste es el que hace las consultas a la base de datos y envía a las aplicaciones el resultado en formato JSON.

La otra alternativa (datos en el móvil) haría que el tamaño de la aplicación para su descarga fuese excesivo.


Captura de pantalla de la app "Rutas Senderismo" de la búsqueda por referencia geográfica.

SQL para implementar la búsqueda "Cerca de tí".

Esta consulta es la más sencilla, pues tan solo necesitamos tener nuestros datos en una tabla, y que ésta tenga una columna geométrica. Supongamos que esta tabla se llame MAPAS, y la columna geométrica GEOMETRY. Nuestra posición nos la proporciona el dispositivo móvil (ya sea en Java, Javascript, o cualquier otra plataforma de desarrollo para dispositivos móviles). 
Si el GPS nos da la posición latitud = 41, longitud = 1, la consulta que se ejecutaría en el servidor sería:

SELECT  t.TITLE, t.DESCRIPTION, FROM MAPAS AS t WHERE MBRIntersects( t.GEOMETRY, GeomFromText('POLYGON((1 41, 1 41, 1 41, 1 41,  1 41))') 

Tan simple como una operación MBRIntersects entre la geometría de nuestros datos, y una geometría construída "al vuelo" con la coordenada que nos ha dado nuestro GPS.
 

SQL para implementar la búsqueda de "elementos cerca de una referencia geográfica".


En este caso, además de la tabla con los datos principales (MAPAS), necesitamos tener una tabla con la referencias geográficas (topónimos) que se vaya a usar como referencia. Para cada referencia geográfica, esta tabla tiene que tener un nombre (por ejemplo: Sevilla (España), Estados Unidos, Parque Nacional de Ordesa, etc), y una geometría. Por ejemplo, GEOGRAPHIC_REFERENCES, NAME y GEOMETRIA.

El proceso para realizar la búsqueda es muy simple: a partir del texto introducido por el usuario, localizamos la referencia geográfica que casa con dicho texto, cogemos su geometría, y hacemos una búsqueda espacial cruzando las dos capas.

El SQL que expresa estas condiciones es el siguiente:

SELECT SQL_CALC_FOUND_ROWS X.* FROM (SELECT  t.TITLE, t.DESCRIPTION FROM MAPAS AS t JOIN GEOGRAPHIC_FILTER AS g ON MBRIntersects( t.GEOMETRIA, g.GEOMETRIA )  WHERE g.name = 'Madrid' ) AS X


Es decir, hacemos una operación JOIN SQL entre las dos tablas (la de los datos y la de las referencias geométricas), usando como condición de unión que intersecten sus geometrías (ON MBRIntersects(g1,g2) ) y luego filtramos los resultados por el texto de búsqueda (WHERE g.name = "Madrid").

En este enlace podemos ver un ejemplo de esta consulta en funcionamiento, localizando rutas de mountain bike en el entorno de Barcelona (España)

Si queréis probar como funciona en la aplicación, podéis instalar alguna de las siguientes aplicaciones:

Rutas MTB

Rutas Senderismo

martes, 17 de mayo de 2016

El infierno de los campos TEXT en MySQL

¡CUIDADO CON LOS CAMPOS TEXT / BLOB en MySQL!

Esta semana nos hemos dado bastantes estocazos contra la pared por culpa de los campos Text en MySQL. El principal motivo es que MySQL no los carga en  memoria, de tal forma que si una consulta tiene tablas con campos Text, MySQL accede a disco para manipular cada una de las filas. Esto ralentiza mucho ciertas operaciones, además de que consume muchísima CPU.

La cosa se hace mucho más grave si encima en la consulta no hacemos uso de esos campos. ¡A MySQL le da igual! Si la tabla tiene campos Text, le da igual que tu no los vayas a manipular en tu consulta. Esto es así porque en la estructura interna de datos que emplea para manejar los registros de una tabla, si ésta tiene campos Text no almacena el valor del campo, sino un puntero a un recurso a disco. Es como si el campo Text fuera un fichero, y MySQL en sus registros internos lo que almacena es la URL / Path del fichero.

Ejemplos de este tipo podemos encontrar muchos:
  • Un sistema de blogging, en el que el contenido de los posts lo tengamos en campos Text, mientras que los metadatos (autor, fecha de creación, categoría de contenido) en campos estructurados.
  • etc

Moraleja: A la hora de diseñar tu tabla, si junto con los campos Text tienes otro tipo de campos, que vayas a utilizar de forma independiente, separalos en tablas distintas. Optimizarás mucho las operaciones que no involucren campos Text, hasta tal forma que te compensará hacer un JOIN cuando sí lo involucren.


martes, 7 de octubre de 2014

Textos completos en JQuery Mobile

Por defecto, cuando el framework Jquery Mobile detecta que un texto excede del tamaño reservado de la barra de título, lo recorta y pone unos puntos suspensivos.

Para evitar esto, hay que modificar el estilo CSS del emento html utilizado para el título, añadiendo la propiedad white-space:normal.
white-space: normal

lunes, 6 de octubre de 2014

Leaflet: la importancia de map.invalidateSize()

Ultimamente me he estado pegando más de la cuenta con Leaflet, así que comparto aquí el problema encontrado, y la solución, por si le puede servir de ayuda a alguien.

Origen del problema: tenemos un objeto javascript L.Map de Leaflet, al que hemos añadido una serie de elementos vectoriales (objetos de tipo L.Layer).

Si queremos cambiar la capa, y mostrar otra distinta, reutilizando el objeto mapa existente, tenemos que seguir estos dos pasos:

a) Eliminar los objetos "Layer" previamente cargados. En este caso lo más comodo es haberlos agrupado previamente en un contenedor denominado "LayerGroup".

if(currentLayer){
    if(currentLayer instanceof L.LayerGroup)
         currentLayer.clearLayers();
         map.removeLayer(currentLayer);
    }
}

b) Añadir la nueva capa (objetos Layer) agrupada en un contenedor.

 var lyrs = [];//array donde guardar las geometrias
var layerGroup = L.featureGroup(lyrs); 

c) Cambiar el nivel de zoom del mapa, para que se nos muestra la nueva "capa" que vamos a añadir.
map.fitBounds(layerGroup.getBounds());

Y ¡ojo! Aquí empiezan a aparecer los problemas. Es muy posible que el nivel de zoom que se nos muestre sea siempre el máximo,  y que el mapa (la capa de tiles con ortofoto, open street map, o lo que sea que hayamos querido cargar como capa de base) no aparezca centrado. ¿Cual es el motivo?

Si cambiamos nuestro código de cambio del nivel de zoom, por el siguiente:
var bounds = _layerGroup.getBounds();
var center = bounds.getCenter();
var zoomLevel = map.getBoundsZoom(bounds);

map.setView(center, zoomLevel, true);

Veremos que zoomLevel toma el valor 0.


 ACTUALIZACIÓN: En este bug reportado en la web del proyecto Leaflet se describe perfectamente el problema. No solo zoomLevel toma el valor 0, getSize() devuelve un objeto con valores w=0 y h=0.

En este punto es cuando entra en juego el método invalidateSize() del objeto map. Si lo hacemos así:

          var layerGroup = L.featureGroup(lyrs);
         map.invalidateSize();
         map.fitBounds(layerGroup.getBounds()); 

Nuestro mapa se dibujará sin problemas, mostrando la capa que acabamos de añadir.


Moraleja: map.invalidateSize() recalcula los parámetros del objeto map,parámetros que pueden cambiar con un cambio del área de visualización del dispositivo (horizontal a vertical en móvil, cambio del tamaño del navegador en desktop, etc) o con el "bounds" de las geometrías cargadas. Así que es conveniente siempre llamar a map.invalidateSize() antes de cambiar el nivel de zoom, si pensamos que se ha producido un cambio en la inforamación de estado del mapa.

martes, 29 de julio de 2014

Operaciones de mantenimiento sobre tablas MyISAM de MySQL sin bloquearlas

Actualmente lookingformaps tiene indexados en torno al millón de mapas, y aproximadamente 30 o 40 millones de puntos de interés. Esto ha hecho que la base de datos con la que gestiona la información haya alcanzado dimensiones considerables (en torno a 10 Gb. de información, incluyendo índices).






Looking4Maps trabaja con la base de datos MySQL, por ser muy lígera, y estar muy extendida (trabajando con ella la casi totalidad de proveedores de servicios de hosting de Internet). Además, MySQL proporciona capacidades de gestión espacial básicas, con tipos geométricos, índices espaciales y operaciones espaciales básicas a nivel de rectángulos envolventes (bounding box).

Sin embargo, para poder trabajar con los tipos de datos geométricos, el motor de almacenamiento con el que trabaje deberá ser obligatoriamente MyISAM.

MyISAM es el motor más rapido en operaciones de lectura, pero cuando se van a realizar operaciones de escritura tiene un gran inconveniente: hace un bloqueo a nivel de toda la tabla, de tal forma que en muchas ocasiones ni siquiera permite que el resto de usuarios puedan realizar operaciones de lectura.

Muchas operaciones de MyISAM (INSERT, UPDATE, ALTER TABLE) realizan un bloqueo a nivel de tabla.


Esto hace que, operaciones tan simples como pueda ser modificar el esquema de la tabla para añadir un campo, pueda llegar a dejar inoperativo Looking4Maps mientras la base de datos termina de hacer sus operaciones internas para añadir el campo a la tabla, puesto que no permite realizar accesos de lectura para los nuevos usuarios.

Frente a esto, la mejor solución que he encontrado es mantener dos tablas sincronizadas: una de trabajo, que es con la que trabaja lookingformaps para proporcionar mapas a los usuarios, y otra de mantenimiento, que es la tabla sobre la que el motor de indexación realiza los volcados de los nuevos mapas que va encontrado, o sobre la que yo opero (previa interrupción del robot de búsquedas) para hacer modificaciones estructurales de la base de datos.

Para ello, MySQL permite hacer una copia instantánea de una tabla así:

CREATE TABLE COPIA_TABLA LIKE TABLA;
INSERT INTO COPIA_TABLA SELECT * FROM TABLA;



De tal forma que las operaciones que se realicen sobre COPIA_TABLA no estorban en absoluto al resto de usuarios, que pueden seguir trabajando ya que los accesos al sistema en producción se hacen contra TABLA, no contra COPIA_TABLA.


Una vez terminadas las operaciones sobre la tabla de escritura, se propagan a la tabla principal así:

RENAME TABLE TABLA TO TABLA_VIEJA;
RENAME TABLE COPIA_TABLA TO TABLA;
RENAME TABLE TABLA_VIEJA TO COPIA_TABLA;

Esta solución funciona para un sistema como Looking4Maps, pensado solo para la búsqueda e indexación, no para la creación de nuevos contenidos. Obviamente, llegado el caso de evolucionar Looking4Maps para que sea un sistema de creación de mapas, habrá que cambiar la arquitectura.







lunes, 28 de julio de 2014

Ríos que atraviesan Tokio: Sumida y Tama (隅田川,多摩川)

En las últimas dos semanas están llegando múltiples visitas a la web de  lookingformaps en busca de los ríos que atraviesan Tokio. Los dos ríos principales que atraviesan Tokio son el río Sumida y el río Tama. Se pueden localizar a través de la categoría Ríos_de_Tokio


Desembocadura del río Sumida en la bahía de Tokio.


El río Sumida (en japonés: 隅田川, Sumida-gawa) se origina en la bifurcación artificial del  río Arakawa en Iwabuchi, y desemboca en la bahía de Tokio. A su paso por Tokyo el rio es bastante caudaloso con lo que es navegable. A parte de pequeños barcos que navegan por sus aguas también existe, en Tokyo, una red de transporte por el rio con diversas paradas. Esta red es llamada 水上バス  (Suijō Basu) , que se podría traducir como autobuses acuáticos o de agua. Los principales embarcaderos de estas lineas son 4: Asakusa, Hama Rikyu, Hinode y Odaiba. Hay varias combinaciones que se pueden hacer pero la mas común suele ser la que va desde Asakusa hasta Odaiba o viceversa, esta ruta puede ser directa o con paradas en otros puertos.

El río Tama (多摩川 Tama-gawa) atraviesa Tokio, estableciendo la línea divisoria entre Tokio y Kanagawa. En Tokio es una zona muy popular para la práctica de deportes o simplemente para echar un día de campo, debido a los parques y pistas deportivas que existen a lo largo de la orilla a su paso por Tokio.