Geolocalización y mapas - Construcción de aplicaciones geoespaciales con Amazon Location Service y Amplify

Cuatro componentes de una aplicación de ubicación

Aplicaciones de transporte con conductor, reparto de comida, seguimiento logístico, búsqueda inmobiliaria y localizadores de tiendas. Aunque los usos sean distintos, las aplicaciones que manejan información de ubicación necesitan, en general, los mismos componentes. Dibujar un mapa en la pantalla; convertir direcciones y nombres de lugares en latitud y longitud (geocodificación); calcular la ruta y el tiempo de recorrido entre puntos; y registrar de forma continua la posición de los objetos en movimiento para detectar la entrada y la salida de una zona concreta. Esos son los cuatro. Si se intenta prepararlos por cuenta propia, la obtención de los datos cartográficos y la revisión de sus licencias, la generación y distribución de teselas, la implementación de la búsqueda de rutas sobre una red de carreteras y la operación de un almacén de datos que conserve el historial de posiciones pasan a ser, todas ellas, trabajo propio. Amazon Location Service ofrece este conjunto de componentes como servicio administrado y permite invocar como API de AWS el dibujo de mapas, la búsqueda de lugares, el cálculo de rutas, y el seguimiento de posiciones y las geovallas. El punto que hay que tener presente es que la forma de usar este servicio cambió de manera importante en noviembre de 2024. Antes era obligatorio crear recursos antes de empezar, pero en la generación actual ese paso ha desaparecido y basta con preparar una sola clave de API para hacer las llamadas. Este artículo parte de las API de la generación actual y recorre desde la forma concreta de invocarlas hasta el modo de entender los precios. Más adelante, en la parte final, se dedica también una sección a la migración para quienes mantienen aplicaciones creadas con la generación anterior.

El cambio de generación de noviembre de 2024: de la creación de recursos a las claves de API

Para entender el punto de entrada de la generación actual, lo más rápido es comprender primero qué ha desaparecido. En la generación anterior, para buscar direcciones había que crear primero un recurso llamado índice de lugares; para calcular rutas, una calculadora de rutas; y para mostrar mapas, un recurso de mapa; cada uno se creaba de antemano y después se hacía referencia a él por su nombre. El diseño consistía en elegir el proveedor de datos en el momento de crear el recurso, de modo que las llamadas posteriores quedaban vinculadas a ese recurso. El nuevo conjunto de API publicado en noviembre de 2024 eliminó esta premisa. En la explicación oficial también se afirma claramente que el paso de creación de recursos, antes obligatorio, ya no es necesario y que ahora se pueden usar las distintas API configurando una clave de API. Lo que se lanzó entonces fueron 10 API actualizadas y 7 API nuevas, en total 17 API nuevas o mejoradas. Al mismo tiempo, los espacios de nombres del SDK también se separaron. La búsqueda de lugares pasó a geo-places, el cálculo de rutas a geo-routes y la obtención de mapas a geo-maps, cada uno como una familia independiente, de modo que una aplicación puede incorporar solo las familias que necesita. Las claves de API se crean con CreateKey, y además están disponibles DescribeKey, ListKeys, UpdateKey y DeleteKey. El valor de la clave es una cadena que empieza por v1.public., y está pensado para incrustarse en el código del frontend. Precisamente porque se da por hecho que se incrustan, a las claves se les puede fijar una fecha de caducidad opcional y se puede limitar su ámbito de uso por el referente HTTP en la Web o por el identificador de la aplicación en móviles. Sin embargo, hay un límite en lo que se puede invocar con una clave de API. Las consultas de mapas, lugares y rutas se pueden invocar con una clave, pero operaciones como escribir posiciones en un rastreador, administrar geovallas o administrar las propias claves requieren autorización mediante IAM o Amazon Cognito. El diseño de la generación actual consiste en separar, cada una con su propio mecanismo de autorización, las consultas que se pueden hacer públicas sin problema de las escrituras y operaciones de administración que no lo son.

Places, Routes y Maps: tres familias de API y una primera llamada

Las API de la generación actual se organizan en tres familias. Places, que se ocupa de los lugares, tiene siete operaciones. Son Geocode, que obtiene la latitud y la longitud a partir de una cadena de dirección; ReverseGeocode, que obtiene la dirección a partir de la latitud y la longitud; SearchText, para la búsqueda de texto libre; SearchNearby, para buscar instalaciones cercanas; Autocomplete y Suggest, para completar la entrada; y GetPlace, que obtiene los detalles a partir de un identificador. Completar la entrada se divide en dos porque devolver candidatos de dirección ya determinados y devolver candidatos del propio término de búsqueda son situaciones distintas. Routes, que se ocupa de las rutas, tiene cinco. Son CalculateRoutes, que calcula rutas; CalculateRouteMatrix, que crea una tabla de tiempos de recorrido de muchos a muchos; CalculateIsolines, que devuelve como superficie el área alcanzable dentro de un tiempo especificado; OptimizeWaypoints, que optimiza el orden de varias paradas; y SnapToRoads, que ajusta a las carreteras una serie de puntos GPS. La correspondencia es CalculateRouteMatrix y OptimizeWaypoints para la planificación de repartos, CalculateIsolines para el análisis de áreas comerciales y SnapToRoads para depurar historiales de conducción. Los valores del modo de desplazamiento varían según la operación. CalculateRoutes admite seis tipos, al añadir Transit para el transporte público e Intermodal para el transporte combinado a Car, Pedestrian, Scooter y Truck, mientras que las otras cuatro operaciones, como el área alcanzable y el ajuste a carreteras, admiten cuatro tipos: Car, Pedestrian, Scooter y Truck. En todos los casos, si no se especifica nada, el valor es Car, y Scooter se trata como una categoría que incluye las motocicletas. Maps, que se ocupa de los mapas, tiene cinco: GetStyleDescriptor, que devuelve la definición de estilo; GetTile, para las teselas vectoriales; GetGlyphs, que devuelve las fuentes para dibujar etiquetas; GetSprites, para las imágenes de iconos; y GetStaticMap, que devuelve el mapa como una sola imagen. Si solo se quiere insertar un mapa en un correo electrónico o un PDF, GetStaticMap basta por sí mismo. Lo práctico es comprobar la primera llamada con la CLI. Cuando se usa una clave de API no hace falta firmar, por lo que se añade --no-sign-request.

aws geo-places geocode \
  --query-text '東京都渋谷区神宮前 1-1-1' \
  --language ja \
  --key "$ALS_API_KEY" \
  --no-sign-request \
  --region ap-northeast-1

Para invocarlo directamente por HTTP, se envía la clave a POST /v2/geocode en el parámetro de consulta key y se ponen QueryText, Language y otros valores en el cuerpo como JSON. En la documentación oficial se indica que una solicitud requiere una clave de API o una firma SigV4 válida. La división es la autenticación de IAM habitual cuando se llama desde el servidor y la clave de API cuando se llama desde un navegador o una aplicación. Si se quiere validar un gran número de direcciones de una vez, en lugar de enviar las solicitudes de una en una, existe una vía que procesa de forma asíncrona archivos en Amazon S3 mediante Amazon Location Service Jobs. Además, el seguimiento de posiciones y las geovallas siguen utilizándose, incluso en la generación actual, tras crear recursos llamados rastreadores y colecciones de geovallas. Para ser exactos, lo que ya no requiere crear recursos son las consultas de mapas, lugares y rutas.

Renderizado de mapas e integración con el frontend

Del dibujo del mapa en sí se encarga MapLibre. MapLibre GL JS en la Web y MapLibre Native en móviles son los renderizadores recomendados oficialmente, y el papel de Amazon Location Service es suministrar las definiciones de estilo y las teselas. En la Web, la implementación funciona con solo pasar la URL del descriptor de estilo a la especificación de estilo de MapLibre.

import maplibregl from 'maplibre-gl';
import 'maplibre-gl/dist/maplibre-gl.css';

const region = 'ap-northeast-1';
const apiKey = import.meta.env.VITE_ALS_API_KEY;

const map = new maplibregl.Map({
  container: 'map',
  style: `https://maps.geo.${region}.amazonaws.com/v2/styles/Standard/descriptor?key=${apiKey}&color-scheme=Dark`,
  center: [139.7671, 35.6812],
  zoom: 14
});

map.addControl(new maplibregl.NavigationControl());

El estilo se elige entre cuatro tipos: Standard, Monochrome, Hybrid y Satellite. El tono de color se puede cambiar entre Light y Dark con el parámetro color-scheme, y el valor predeterminado es Light. Este valor distingue entre mayúsculas y minúsculas, por lo que si se escribe dark no funciona. También se pueden controlar con parámetros añadidos a la URL del descriptor otras formas de representación, como los edificios en 3D, el sombreado del relieve, la densidad de las curvas de nivel y la superposición del estado del tráfico. Es decir, para cambiar el aspecto no hace falta reescribir el código de la aplicación; basta con cambiar cómo se construye la URL. Los nombres de host de los puntos de enlace tienen dos formatos. El formato tradicional, solo para IPv4, es service-code.geo.region-code.amazonaws.com, y el formato de doble pila, compatible con IPv4 e IPv6, es service-code.geo.region-code.api.aws. El service code es maps para los mapas, places para los lugares, routes para las rutas, geofencing para las geovallas, tracking para los rastreadores y metadata para la familia a la que pertenecen los trabajos de procesamiento por lotes. En entornos en los que la conexión por IPv6 es un requisito, se elige el segundo formato. Si se usa AWS Amplify con React, también existe la opción de mostrar el mapa con los componentes de UI de Amplify Geo.

import { MapView, Marker } from '@aws-amplify/ui-react-geo';
import '@aws-amplify/ui-react-geo/styles.css';

export default function StoreLocator() {
  return (
    <MapView
      initialViewState={{ latitude: 35.6812, longitude: 139.7671, zoom: 14 }}
    >
      <Marker latitude={35.6812} longitude={139.7671} />
    </MapView>
  );
}

Sin embargo, esta forma de escribirlo presupone los recursos de mapa que configura Amplify y la autorización de Amazon Cognito, y su manera de tratar las credenciales es distinta del método de claves de API explicado hasta aquí. Si se deja claro que esta opción sirve para añadir un mapa a una aplicación de Amplify existente y que, para usar directamente las API de la generación actual, se pasa a MapLibre la URL del descriptor con la clave, se evita que los diseños de autorización se mezclen a medias. Cuando se quiere controlar el ámbito que puede manejar cada usuario, o cuando se tratan operaciones que implican escrituras, en cualquiera de las dos configuraciones se acaba recurriendo a Cognito e IAM.

Migración desde las API de la generación anterior y el lugar de los procedimientos antiguos

Si una aplicación existente funciona con la generación anterior, el código tiene un aspecto bastante distinto. La geocodificación de la generación anterior consistía en especificar el nombre de un índice de lugares creado de antemano.

aws location search-place-index-for-text \
  --index-name MyPlaceIndex \
  --text '東京都渋谷区神宮前 1-1' \
  --language ja \
  --region ap-northeast-1

En esta forma, el proveedor de datos elegido al crear el índice determina los resultados de búsqueda a partir de entonces. Para cambiar de proveedor había que volver a crear el índice, y aunque solo se quisiera comparar la calidad de las búsquedas, la administración de recursos entraba en juego. Las API de la generación actual no tienen ningún parámetro equivalente a --index-name. Tampoco existen parámetros para el nombre de la calculadora de rutas ni para el nombre del recurso de mapa, por lo que el trabajo de migración consiste, en realidad, en «eliminar los puntos en los que se pasaban nombres de recursos y sustituir los destinos de llamada por los nuevos nombres de operación». Los valores del modo de desplazamiento también cambiaron. La generación anterior tenía cinco tipos: Bicycle, Car, Motorcycle, Truck y Walking. La generación actual se basa en Car, Pedestrian, Scooter y Truck, y solo para el cálculo de rutas (CalculateRoutes) se añaden Transit para el transporte público e Intermodal para el transporte combinado. Walking se sustituye por Pedestrian, y Motorcycle por Scooter. La generación actual no incluye ningún valor para bicicletas, por lo que las aplicaciones que devolvían rutas pensadas para bicicleta deben decidir, al migrar, cómo tratar ese caso. La documentación de la generación anterior no ha desaparecido; está reunida bajo docs.aws.amazon.com/location/previous/. Si un procedimiento encontrado en una búsqueda corresponde a la generación actual o a la anterior se puede distinguir por si la URL contiene previous. Cuando se quiere consultar el procedimiento antiguo durante la migración, ese es el lugar donde mirar. Para quienes migran desde una aplicación escrita con la API de JavaScript de Google Maps, existe una opción que publica AWS: el Amazon Location Migration SDK. Es una herramienta basada en la idea de intercalar una capa que imita la interfaz de llamadas de Google Maps y, sin reescribir en gran medida la lógica de negocio de la aplicación, ir sustituyendo el dibujo de mapas y la búsqueda de lugares por Amazon Location Service. En aplicaciones de un tamaño que no permite reescribirlas por completo de una vez, un enfoque práctico es comprobar primero con esta capa el alcance de la sustitución.

Elección del proveedor de datos y sus condiciones de uso

Los resultados de los mapas y de la geocodificación no los elabora AWS por su cuenta, sino que los suministran los proveedores de datos. A fecha de agosto de 2026, los proveedores son Esri, HERE y GrabMaps, este último orientado al Sudeste Asiático. En cuanto a las teselas de mapa, solo cuando se accede a través de los recursos de mapa de la generación anterior se pueden elegir, además, estilos derivados de Open Data. Open Data se usa para dibujar mapas, no para la búsqueda de lugares ni para el cálculo de rutas. Si se plantea como una elección entre dos proveedores, la opción para el Sudeste Asiático y las teselas de Open Data quedan fuera de la vista. En la selección, lo que pesa primero son las condiciones de uso, más que la calidad. Además, estas condiciones no se establecen en la documentación del servicio, sino en las Condiciones de servicio de AWS. Los datos de Esri no pueden usarse, salvo consentimiento por escrito de AWS, para el seguimiento de los activos empresariales propios (como vehículos de la empresa o instalaciones propias) ni para el cálculo de rutas con ese fin. Con los datos de HERE no se pueden almacenar resultados de Japón. GrabMaps es un proveedor para el Sudeste Asiático y las regiones en las que está disponible son limitadas. Además, las operaciones y los estilos que se pueden usar varían según la región. En ap-southeast-1 (Singapur) y ap-southeast-5 (Malasia), que cubren el Sudeste Asiático, no se ofrece Geocode, y los estilos de mapa se limitan a Standard y Monochrome. Lo fiable es comprobar, antes de empezar la implementación, en la lista de disponibilidad por región si en las regiones de la zona objetivo se ofrecen las operaciones necesarias. Que se puedan almacenar o no los resultados también repercute directamente en la facturación. La API de Places tiene un parámetro llamado IntendedUse, en el que se especifica SingleUse (uso único) o Storage (almacenamiento). Si las respuestas se guardan en una base de datos propia, hay que especificar Storage para cumplir las Condiciones de servicio, y en ese caso el precio unitario es más alto. Si solo se muestran en pantalla y no se guardan, se usa SingleUse. En lugar de zanjarlo con la idea general de que la información de ubicación no sale de AWS, lo práctico es comprobar dos puntos: las restricciones de almacenamiento de cada proveedor y la especificación de IntendedUse.

Precios de Location Service

(A fecha de agosto de 2026; comprobado por separado en dos regiones: EE. UU. Este (Norte de Virginia) y Asia Pacífico (Tokio). El importe es el mismo en ambas regiones.) El precio de las consultas de mapas, lugares y rutas no depende del tiempo durante el que se mantienen recursos, sino del número de llamadas. En estas familias, que no requieren crear recursos de mapa ni de índice, no se generan costos fijos durante los periodos sin uso. Como se explica más adelante, solo las geovallas tienen un cargo por mantenerlas. Las teselas de mapa, con GetTile de la generación actual, cuestan $0.04 por cada 1,000 teselas, sea cual sea el estilo. Los precios unitarios por proveedor se mantienen para la obtención a través de los recursos de mapa de la generación anterior, donde solo los estilos de Open Data cuestan $0.035 por cada 1,000 teselas. GetStaticMap, que devuelve una sola imagen, cuesta $0.50 por cada 1,000 solicitudes. Hay que tener en cuenta que mostrar una sola pantalla obtiene varias teselas, y cuantas más operaciones de zoom y desplazamiento tenga la UI, más teselas se usan. La búsqueda de lugares cuesta, por cada 1,000 solicitudes, $0.50 en Core y $1.50 en Advanced. Las respuestas ligeras de Autocomplete y Suggest para completar la entrada tienen un bucket aparte llamado Label, que cuesta $0.20 por cada 1,000 solicitudes. Los usos que implican almacenamiento (llamadas que especifican Storage en IntendedUse) cuestan $4.00 por cada 1,000 solicitudes. Para validar direcciones en bloque se aplican precios unitarios escalonados. En Advanced, los primeros 100,000 registros cuestan $12.50 por cada 1,000; los 400,000 siguientes, $9.00; los 500,000 siguientes, $6.50; los 4,000,000 siguientes, $3.00; y la parte que supera los 5,000,000, $1.50. Core dispone de otra serie de precios escalonados que baja de $10.50 a $1.00. El cálculo de rutas (CalculateRoutes) cuesta, por cada 1,000 solicitudes, $0.50 en Core, $1.50 en Advanced y $4.00 en Premium. El nivel de los precios unitarios es común a las demás operaciones, pero los buckets que se pueden elegir varían según la operación. La tabla de tiempos de recorrido (CalculateRouteMatrix) solo tiene Core y Advanced, mientras que el área alcanzable, el ajuste a carreteras y la optimización de puntos de paso solo tienen Advanced y Premium. Por tanto, estas tres últimas operaciones no tienen el Core de $0.50, y su precio unitario mínimo es de $1.50 por cada 1,000 solicitudes. El seguimiento de posiciones no se determina por una cuota mensual por dispositivo, sino por el número de posiciones enviadas. Las escrituras de posición cuestan $0.05 por cada 1,000 en los primeros 500,000; $0.035 en los 4,500,000 siguientes; $0.025 en los 45,000,000 siguientes; y $0.0125 en la parte que supera los 50,000,000. La lectura de posiciones y la eliminación de dispositivos cuestan $0.05 por cada 1,000 cada una, y la evaluación de la integridad de las posiciones, $1.00 por cada 1,000. Si se ponen en marcha 100 vehículos que envían su posición cada 10 segundos, en un solo día se superan los 860,000 registros: el diseño del intervalo de envío se refleja directamente en el costo. Las geovallas son el único componente que, además del cargo por llamada, tiene un cargo por mantenimiento: $0.20 al mes por cada 1,000 geovallas registradas. La comparación de posiciones con geovallas (evaluación de posiciones) es escalonada: los primeros 250,000 cuestan $0.16 por cada 1,000; los 1,750,000 siguientes, $0.11; los 23,000,000 siguientes, $0.07; y la parte que supera los 25,000,000, $0.06. Además, las operaciones de administración, como crear o actualizar geovallas, se ofrecen a $0.05 por cada 1,000, y las previsiones de llegada, a $1.75 por cada 1,000. Que se facture como Core, Advanced o Premium depende de las opciones añadidas a la solicitud. El bucket aplicado realmente se devuelve en el campo PricingBucket de la respuesta, de modo que, si antes de elaborar una estimación se mide en qué bucket caen las solicitudes de desarrollo, se evitan desfases entre lo previsto y lo facturado. Para volúmenes de uso superiores a $5,000 al mes, la página oficial de precios ofrece información sobre descuentos por volumen. En cuanto a lo que se puede probar gratis, hay que saber que coexisten dos descripciones distintas. La capa gratuita de AWS para cuentas nuevas pasó a un modelo de créditos el 15 de julio de 2025: se reciben créditos por un valor de hasta $200, el plan gratuito se usa durante 6 meses y los créditos deben usarse en un plazo de 12 meses. Por otro lado, la página de precios de Location Service también incluye la tabla tradicional, con uso gratuito hasta cierta cantidad cada mes durante los primeros 3 meses. Como la que se aplica a cada cuenta depende de la fecha de creación, lo seguro es comprobar el saldo real en la pantalla de la capa gratuita del panel de facturación antes de elaborar la estimación.

Resumen

El Amazon Location Service de la generación actual no es un servicio que se use después de crear índices de lugares o calculadoras de rutas. Con una sola clave de API se pueden invocar las siete operaciones de Places, las cinco de Routes y las cinco de Maps. Cuando se encuentran artículos o ejemplos escritos con los procedimientos de la generación anterior, comprobar si la URL contiene previous evita confundir las generaciones. Los puntos que hay que tener en cuenta en el diseño se reducen a tres. El primero es la separación de la autorización: las consultas que se pueden hacer públicas sin problema van con la clave de API, y las escrituras y la administración, con IAM o Amazon Cognito. El segundo es el proveedor de datos: entre Esri, HERE, GrabMaps y Open Data para las teselas de mapa, se elige un proveedor cuyas Condiciones de servicio permitan el uso previsto, y si se guardan los resultados, se especifica Storage en IntendedUse. El tercero es la unidad de facturación: como el costo lo determinan el número de solicitudes y el bucket aplicado, es eficaz ajustar la forma de añadir opciones observando PricingBucket. El dibujo del mapa se deja a MapLibre, y el aspecto se cambia con los parámetros de la URL del descriptor de estilo. Con este reparto de funciones claro, se puede construir con el mismo planteamiento desde una pantalla pequeña, como un localizador de tiendas, hasta una configuración a la escala del seguimiento continuo de vehículos.