Blog

Transacción comercial en varias etapas con teléfono #Android y #NFC (simulación de un parquímetro)

Esto es una demo en la que se simula una transacción comercial (cliente en un aparcamiento) en varias etapas (negociación que concluye con un pago) mediante aplicaciones Android y mensajes en el estándar NFC. En general, este esquema se puede aplicar a situaciones en las que el usuario se encuentra físicamente en un lugar en el que hay un recurso asignable, una tarea a realizar, etc. Por ejemplo, lugares donde se obtiene un servicio o producto o lugares de trabajo, y existe algún dispositivo automático de venta o gestión de recursos o asignación de tareas, de modo que se puede establecer una negociación hasta llegar a un acuerdo.

En esta demo, tanto la aplicación del cliente como la del parquímetro se ejecutan sobre teléfonos Android aprovechando las funcionalidades de recepción de mensajes NFC y el sistema Android Beam que permite a su vez enviar mensajes NFC:

Aplicación que simula el parquímetro. NFC = Near Field Communication (Comunicación de Campo Cercano). Aplicación en el teléfono del conductor.

Este vídeo con subtítulos muestra una ejecución de las aplicaciones:

#gvSIG 2.1.0: Tables with and without PK in the GeoDB wizard

Si una tabla tiene declarado una clave primaria en la BD, el combo del asistente GeoDB solo muestra esa opción y por tanto no se puede cambiar. Si la tabla no tiene una clave primaria declarada, se muestran todos los campos de la tabla y el usuario es responsable de que el que elija cumpla la condición de no tener valores repetidos, de lo contrario la aplicación hará cosas raras (esto se avisa mediante un diálogo): If a table does have a declared primary key in the DB, the GeoDB wizard will show only that one, so the user will not be able to change it. If the table does not have a declared PK, all fields will be available in the combo box, so the user is responsible for choosing a field which has no repeated values, otherwise the application will behave in a strange way when dealing with that table (a warning dialog tells this):

Testing Leaflet + Markercluster and Arabic characters

Leaflet.markercluster es un plugin para Leaflet (librería Javascript para aplicaciones web de mapas) creado por Dave Leaver. En este pequeño vídeo estamos probándolo con topónimos en caracteres árabes: Leaflet.markercluster is a plugin for Leaflet (Javascript webmapping library) created by Dave Leaver. This short video shows a test with Arabic place-names:
En comparación con el uso de teselas vectoriales pre-calculadas que ha desarrollado Prodevelop, veo las siguientes ventajas:
  • Mayor facilidad de uso.
  • Mejores efectos gráficos.
Y estos inconvenientes:
  • El algoritmo de agrupación no está muy conseguido, ya que se intenta agrupar de manera incremental.
  • Es necesario cargar todos los puntos de interés al inicio (es decir se está descargando mucha información que probablemente no se va a usar)
Compared to Prodevelop's pre-cached vector tiles approach, I can see these advantages:
  • Easier to use.
  • Better graphic effects.
And these problems:
  • The clustering method is not working very well, probably because it tries to group the POIs as they come, which is a too simplified approach.
  • It is necessary to load all the POIs at the start, which means that a lot of unneeded data is being downloaded.

Fast estimation of distance/area from geodetic coordinates

Dado un par de coordenadas (lon, lat) en grados, obtenemos las coordenadas en Mercator Esférico con: Given the pair of coordinates (lon, lat) in degrees, we can get the Spherical Mercator coordinates with:
DEGREES_PER_RADIAN = 180.0 / Math.PI;
MERCATOR_EARTH_RADIUS = 6378137.0;
METERS_PER_EQUATOR_DEGREE = Math.PI * MERCATOR_EARTH_RADIUS / 180.0;

rlat = lat / DEGREES_PER_RADIAN;
y = 0.5 * Math.log((1 + Math.sin(rlat)) / (1 - Math.sin(rlat)));
merx = METERS_PER_EQUATOR_DEGREE * lon;
mery = METERS_PER_EQUATOR_DEGREE * DEGREES_PER_RADIAN * y;
Como es sabido, la proyección esférica de Mercator usada por Google (llamada EPSG:900913 o EPSG:3857) conserva ángulos y proporciones localmente, y todos los paralelos miden lo mismo: As we know, the Spherical Mercator projection known as EPSG:900913 and also EPSG:3857 is conformal (keeps angles and shapes locally) and all parallels have the same length E:
R = 6378137 m
E = 2 * pi * R = 40075016.686 m
Pero sabemos que realmente cada paralelo mide aproximadamente P = E * cos(lat) así que al medir distancias o perímetros directamente en esta proyección, es necesario normalizar el resultado, multiplicándolo por un factor f = cos(lat). En el caso de Estocolmo (Suecia) por ejemplo: But we know that the true length of each parallel is approximately P = E * cos(lat), so if one wishes to measure distances, perimeters or paths directly on a map in EPSG:3857, it’s necessary to multiply the result by a factor f = cos(lat). In the case of Stockholm (Sweden), for example, we have:
lat = 60
f = 0.5
Esto es una piscina olímpica en Barcelona en Google Maps. Su latitud es 41.36573: This is an olympic swimming pool in Barcelona on Google Maps. Latitude is 41.36573:
Si medimos su longitud directamente en esa proyección: If we measure its length directly in that projection:
Longitud verdadera: True length:
L = 66.57 * cos(41.36573) = 49.96 m
En el caso de áreas, podemos imaginar un polígono arbitrario (por ejemplo el perfil de la cara de un hombre) dividido en infinidad de pequeños cuadritos. Si reducimos la imagen con un factor de 0.6, el área de cada cuadrito resultante será 0.36 veces el del cuadrito original: For areas, we can think of an arbitrary polygon (for example, the outline of a man's face) divided into little squares. If we scale down the image by a factor of 0.6, each resulting little square is 0.36 times the size of the original square:
Por tanto, si la magnitud unidimensional (longitud) se escala en un factor f, la magnitud bidimensional (área) queda escalada en un factor f^2. Esto quiere decir que un área calculada usando coordenadas de Mercator esférico debe ser normalizada con el factor [cos(lat)]^2. So if the 1-dimensional magnitude (length) is scaled by f, then the 2-dimensional magnitude (area) gets scaled by f^2. This means that the area computed using Spherical Mercator coordinates must be normalized by a factor of [cos(lat)]^2.

Using regular patterns to check clustering method performance

Este pequeño vídeo muestra el comportamiento de la aplicación de clusterización (agrupamiento de elementos cercanos) realizada por Prodevelop para generar archivos KML enlazados, de manera que el rendimiento de los clientes web sea óptimo sin perder validez en la ubicación de los elementos. Los pasos mostrados en el vídeo son:
  1. Explorar y editar la tabla original con gvSIG 2.1.0.
  2. Ejecutar la aplicación de clusterización sobre la misma tabla.
  3. Copiar la carpeta de archivos KML generada en una carpeta pública accesible desde internet.
  4. Obtener la URL del archivo KML raíz y visualizar el resultado en Google Earth.
This short video shows the behavior of the clustering application created by Prodevelop to create nested KML files. This approach ensures optimum performance by web clients without losing geographic information, regardless of the map scale. The steps shown in the video are:
  1. Exploring/editing the source table with gvSIG 2.1.0.
  2. Running clustering application on the same table.
  3. Copying resulting files to target web folder.
  4. Getting URL of root KML file and browsing final result in Google Earth.
Este es el código con el que se calcula la ubicación de cada agrupación de elementos, como una media ponderada en función del peso de los subelementos: This is the Java code which computes coordinates of cluster as an weighted average of the coordinates of its sub-elements:

Advanced labeling in gvSIG 2.1.0 with some improvements

El etiquetado avanzado se ha llevado a gvSIG 2.1.0 con alguna mejora. Se ha modificado ligeramente la colocación de etiquetas dentro de los polígonos para que aparezcan en la porción del polígono que es visible en la vista, es decir no quedan pedazos vacíos, tal como se ve en los sucesivos cambios de escala de este vídeo: Advanced labeling has been ported to gvSIG 2.1.0 with some improvements, such as the new behavior of the "place inside polygon" policy, which will place the label inside the section of the polygon which is visible in the current view, as can be seen in this short video. Labels conveniently approach the polygon border as we zoom in:
También se ofrece ahora la posibilidad de trazar un halo de cualquier grosor y color alrededor de cada etiqueta. Por supuesto, están dispobibles las opciones de filtrado, selección, expresiones, etc. It is also possible now to have an hallo added around each label, with user-defined width and color. Of course, all other potions (filters, on-selection, expressions, etc) are also available.

Under development: copy-pasting features in gvSIG 2.1.0 through the clipboard using WKT

Rápido ejemplo que muestra cómo se pueden copiar/pegar geometrías usando el portapapeles (clipboard) del sistema con el formato WKT. En este caso los campos toman valores por defecto ya que la información proviene de otra aplicación. Esta funcionalidad será descrita con más detalle en futuros artículos. A quick example showing how to copy-paste features by using the clipboard and the WKT format. In this case, attribute values are set to default values because the WKT comes from another application. This functionality will be explained in more detail in future posts.


GeoStore: parametrized creation of vector tiles in JSON/KML format from PostgreSQL/Oracle/MySQL databases

Prodevelop ha desarrollado, en el ámbito del proyecto GEOSTORE, una aplicación para la creación parametrizada de teselas (tiles) vectoriales en formato JSON y KML, a partir de tablas de PostgreSQL, Oracle o MySQL. In the context of the GEOSTORE project, Prodevelop has provided an application to create vector tiles in various formats (KML, JSON) from different databases (Oracle, PostgreSQL, MySQL).
Todos los parámetros que controlan el proceso se encuentran en un archivo .properties en el que se detallan: parámetros de acceso a la BD en la que se encuentran los datos, campos de la tabla a utilizar, nombre del campo geométrico o campos (longitud, latitud) en los que se encuentran las coordenadas asociadas a cada registro; el tipo de BD y el formato de salida, así como otros parámetros para ajustar los métodos de clusterización (agrupación) y división de los datos (teselado). Esta imagen muestra solo los parámetros más importantes: All the parameters involved in the process are set in a properties file: database access parameters, table fields to be used, name of field (if geometry is available) or fields (if longitude and latitude are available) where coordinates are to be found; type of database (currently supports PostgreSQL, Oracle and MySQL); output format (KML or JSON) as well as other parameters which determine how the tiling and clustering processes will work. This image shows only the relevant parameters of a typical properties file:
Aquí puede apreciarse el resultado al acercarse a un mapa en el que se han desplegado los archivos KML generados. Los clusters se expanden a medida que la escala de visualización lo permite: This image illustrates what happens when the user zooms in after the generated KML files have been deployed on a map. Clusters are expanded as zoom scale allows it:
Los archivos forman en disco un árbol de directorios similar al que se usa con las teselas de imágenes (Google Maps, OpenStreetMap, etc): Files are generated in a tree-like structure, similar to the one used by Google Maps or OpenStreetMap for their image tiles:
Esta otra captura de pantalla muestra un ejemplo similar con teselas JSON. En este caso, el cliente web estará probablemente escrito en Javascript: This screenshot shows a similar example using JSON tiles. In this case, the web client will typically be written in Javascript:
Finalmente, este vídeo muestra la creación y el uso de teselas KML desde una tabla Oracle y teselas JSON desde una tabla MySQL: This video shows the creation and use of KML tiles from an Oracle table and JSON tiles from a MySQL table:

Improved Map Sheets plugin for gvSIG 2.0 now available

Se ha publicado el plugin Map Sheets para gvSIG 2.0. Permite generar automáticamente series de mapas para un cierto área de interés. Incluye la mejora de poder rotar el marco asociado a cada hoja durante el ajuste. Pinche para ver imágenes completas y el vídeo: An improved version of the Map Sheets plugin for gvSIG 2.0 has been released. This plugin automatically creates series of maps for a given area of interest. It now allows rotation of frames associated with each sheet by using the adjustment tool. Click to see full sample images and video:
El marco de cada hoja puede rotarse arrastrando y manteniendo pulsada la tecla SHIFT (mayúsculas).
.
Descripción de algunos elementos del mapa final.
.
Vídeo demostrativo

gvSIG 2.0: Checking correctness of symbol and label sizes on printed maps without a printer

Al decidir la anchura o tamaño de puntos, líneas o bordes y el tamaño de las etiquetas, podemos elegir las opciones "tamaño en el mundo" (generalmente metros o kilómetros) y "tamaño en el papel" (generalmente milímetros).

Para comprobar la corrección del resultado sin imprimir el mapa, podemos usar PDFCreator, que funciona como una impresora virtual que genera archivos PDF:
When we decide the width or size of points, borders and lines and the height of labels in a printed map, we can choose the options "size in the world" (usually meters or kilometers) and "size on paper" (usually millimeters).

In order to check the correctness of the result without actually printing it, we can use PDFCreator, which acts as a virtual printer and produces PDF files:


Una vez creado el archivo PDF, debemos graduar el zoom del visualizador de PDFs hasta que el tamaño en pantalla coincida con el tamaño en mundo real: Once we have the resulting PDF file, we can tune the visualization zoom in the PDF viewer until the virtual sheet on screen matches the sheet in the real world, which I have placed on my laptop. Due to small differences in the dot density of monitors (DPI) we need to set the zoom to 92% to get the exact coincidence:


Ahora sabemos que en este visualizador de PDFs el zoom debe ser del 92% para que el tamaño en pantalla sea el del mundo real. Esto será así para cualquier tamaño de página (DIN A4, A3, etc.). Finalmente, podemos colocar una regla directamente sobre la pantalla para comprobar que la simbología y las etiquetas tienen el tamaño adecuado: Now we know that this particular PDF viewer on this particular laptop needs a 92% zoom to show the virtual sheet in its real-world size. That will be true for any page format (DIN A4, A3, etc). Finally, with a real-world ruler we can check that line widths, label heights, etc are as expected:

Distribuir contenido