Constructor de mapas sin código frente a API de mapas

Por The Kaleidr Team · Publicado 7 de agosto de 2026 · 16 min de lectura

Un constructor visual de mapas sin código y un flujo para desarrolladores mediante API, conectados por capas de SDK e integración en un único producto cartográfico interactivo.

Un constructor de mapas sin código suele ser más rápido cuando un equipo necesita crear, diseñar, publicar y mantener un mapa interactivo sin operar toda la pila de la aplicación. Una API de mapas o un SDK resulta más adecuado cuando los desarrolladores necesitan controlar el estado del mapa, los datos privados, los permisos o el comportamiento personalizado del producto. Muchos equipos adoptan un enfoque híbrido: creación visual e integración mediante SDK, mientras la aplicación anfitriona conserva los usuarios, los datos privados y la lógica de negocio.

Las secciones siguientes comparan responsabilidades, criterios de ajuste, superficies progresivas de Kaleidr y un marco práctico para decidir. Encontrarás contexto de producto en Kaleidr Studio y en la documentación para desarrolladores. Confirma los límites del plan en Precios y planes antes de depender de claves de API o integraciones en producción.

Aspectos esenciales de la comparación

  • Primero, la responsabilidad: decide quién controla la creación, el renderizado, el estado de la aplicación, los datos privados y la publicación; no solo quién puede «hacer un mapa».
  • Contenido o producto: las experiencias publicadas suelen encajar en un constructor; los mapas vinculados al estado de la aplicación suelen necesitar una API o un SDK.
  • El SDK como capa intermedia: Viewer, Chat, Editor y Tiles conectan la creación visual con backends totalmente personalizados.
  • El híbrido como opción práctica: los creadores refinan visualmente la marca y el contenido; los ingenieros integran el comportamiento de ejecución en la aplicación anfitriona.
  • Credenciales: restringe las claves seguras para el navegador y conserva las credenciales de servidor en el servidor.

Un constructor visual de mapas sin código y un flujo para desarrolladores mediante API, conectados por capas de SDK e integración en un único producto cartográfico interactivo.

Constructor de mapas sin código y API de mapas: comparación rápida

La diferencia decisiva no es la cantidad de funciones, sino qué sistema controla cada capa del flujo cartográfico. Usa la tabla como mapa de responsabilidades antes de contar prestaciones, porque una lista extensa aún puede dejar el estado, los datos privados o la publicación en manos del sistema equivocado.

Zona de decisión Construcidor de mapas sin código API de mapa / SDK
Usuario principal Creador, vendedor, analista, operador, equipo de producto Desarrollador o equipo de ingeniería
Punto de partida Editor visual, prompt, plantilla, contenido importado Código, objeto de mapa, solicitud de API, SDK
Tiempo para el primer mapa Generalmente más corto Por lo general más largo
Logiana de aplicación personalizada Limitada a los controles documentados Alto
Estilo de mapa Visual y preestablecido Programático o impulsado por la especificación del estilo
Integración de datos Ideal para importaciones soportadas y flujos de trabajo de plataforma Ideal para bases de datos y servicios personalizados
Permisos de usuario Por lo general, a nivel de plataforma Puede integrarse con la autorización de la aplicación host
Flustos de trabajo privados Depende del soporte del producto Más fuerte con un backend anfitrión
Mantenimiento La plataforma maneja más infraestructura El equipo de ingeniería posee más implementación
Incorporación Compartir enlace, iframe, componente web o incrustar Biblioteca, SDK, componente personalizado o renderista nativo
Analítica Plataforma proporcionada o equipada externamente Totalmente personalizable, pero debe ser implementado
Mejor ajuste Publica y mantiene mapas rápidamente Crear mapas como una capacidad de producto central

Si el mapa es principalmente contenido, suele ganar un constructor. Si forma parte del estado de la aplicación y la lógica de negocio, una API o un SDK cobra mayor importancia. Los diseños híbridos quedan entre ambos extremos cuando los creadores necesitan control visual y la aplicación anfitriona sigue gestionando identidad, permisos y registros privados.

Diagrama de responsabilidad que compara los mapas sin código administrados por la plataforma, las aplicaciones API controladas por host y una arquitectura híbrida.

¿Qué es un constructor de mapas sin código?

Un creador de mapas sin código permite a un usuario crear un mapa interactivo sin implementar el render, el sistema de estilo, la capa de publicación y la aplicación front-end desde cero. Un constructor capaz puede proporcionar creación de lenguaje natural, edición visual, marcadores y regiones, capas y conjuntos de datos, ajustes preestablecidos de estilo reutilizables, diseño de mapa base, terreno 3D o edificios, plantillas, publicación, intercambio, incrustación de sitios web, análisis e interacción de IA opcional. El principal problema que resuelve es el envío de un mapa útil; el principal problema que no resuelve es calcular, autorizar, sincronizar, persistir y mutar el comportamiento del mapa como parte de un flujo de trabajo de usuario personalizado.

Kaleidr Studio Actualmente sigue un flujo de trabajo de Prompt → Process → Refinar → Implementar flujo de trabajo. Un creador describe el concepto de mapa, Studio genera y organiza la estructura espacial, el creador refina el contenido, el diseño, el estilo y la interacción, y el mapa terminado se puede publicar a través de plataformas digitales. Los materiales de Public Studio también describen mapas base personalizados, capas reutilizables, capas de datos en tiempo real, tipografía, etiquetas, iconos, terrenos 3D y edificios extruidos. Las guías de destino, los mapas de eventos, los mapas del campus, los directorios de la comunidad y los mapas de campaña a menudo se ajustan a esta ruta cuando los no desarrolladores deben poseer actualizaciones de rutina sin una implementación para cada cambio de contenido.

¿Qué es una API de mapas?

Una API de mapas expone datos u operaciones geográficas mediante programación, como geocodificación, geocodificación inversa, lugares, rutas, tiempos de viaje, teselas, estilos, objetos espaciales, elevación, límites, búsqueda, imágenes o IA con contexto de ubicación. Los desarrolladores combinan estos servicios con un renderizador o un SDK. La vía de la API encaja cuando el mapa debe formar parte del código de la aplicación, no ser solo un recurso publicado. Maps JavaScript API de Google ofrece mapas 2D y 3D personalizables, marcadores, capas interactivas, estilos y servicios de ubicación (descripción general de Maps JavaScript API). Mapbox presenta su plataforma como API, bibliotecas, SDK y herramientas para crear experiencias de ubicación personalizadas (introducción a Mapbox). MapLibre GL JS es una biblioteca TypeScript de código abierto que renderiza mapas interactivos con teselas vectoriales y WebGL (introducción a MapLibre GL JS).

Utilizar una API de mapa no significa escribir un renderizador desde los primeros principios. La carga de la ingeniería depende de la cantidad de la pila que el equipo elija poseer. El estilo y los mosaicos, la recuperación de datos privados, la identidad, el análisis, la accesibilidad, la observabilidad y la respuesta a incidentes aún se encuentran fuera de una sola llamada de Maps.

¿Qué función cumplen los SDK entre el constructor y la API?

Los sonidos “No-code builder versus API” son más binarios que los sistemas de mapeo modernos. Un SDK puede proporcionar una interfaz de usuario reutilizable, autenticación segura para el navegador, administración del ciclo de vida del mapa, adaptadores de proveedores, eventos de mapa, acciones estructuradas, visores integrados, editores integrados, controles de chat, manejo de errores y contratos en versión. La plataforma de desarrolladores actual de Kaleidr utiliza un cargador versionado en https://cdn.kaleidr.com/embed/v1/kaleidr.js. El cargador instala window.Kaleidr y el elemento personalizado <kaleidr-map>; la documentación actual enumera chat, viewer, editor y tile como valores de producto compatibles (cominicio rápido). Por lo tanto, un equipo puede progresar de la creación visual a un mapa publicado, luego a la incorporación de visor o de componentes web, luego a Chat, mapas base diseñados o un editor integrado, luego a los flujos de trabajo de la API de la plataforma y una aplicación totalmente personalizada. Comience visualmente y profundice en el código solo donde el producto lo requiera.

¿Cuándo conviene más un constructor de mapas sin código?

Elija un constructor cuando el mapa necesite iniciarse rápidamente, cuando los no desarrolladores deben poseer actualizaciones, cuando el modelo de interacción ya se ajusta a los controles de plataforma compatibles, y cuando el mapa se comporta como una superficie de publicación en lugar de una base de datos operativa. Los ejemplos típicos incluyen guías de turismo, mapas de eventos públicos, mapas editoriales, escaparatis de desarrollo, guías del campus y directorios de recursos públicos. La selección de marcadores, los detalles de lugar, las capas, los filtros, un visor publicado, el chat de mapa de IA, los enlaces compartidos, los mapas base diseñados y las plantillas centradas en el mapa son ajustes de constructor fuertes cuando coinciden con los controles documentados.

Un constructor comprime la inicialización del mapa, la administración de capas, el estilo, la publicación receptiva, el alojamiento, el uso compartido y la entrega de incrustaciones en un solo flujo de trabajo. El equipo todavía tiene que validar el contenido, la accesibilidad, la atribución, la privacidad y los derechos de datos. No-code reduce el trabajo de implementación; no elimina la responsabilidad del producto. La separación de la creación de mapas de la ingeniería de aplicaciones también reduce la dependencia rutinaria de los desarrolladores cuando los vendedores, analistas, equipos de destino, operadores o editores necesitan agregar lugares, actualizar descripciones, cambiar etiquetas, reestilar categorías, ajustar la cámara inicial, publicar revisiones o administrar capas reutilizables.

¿Cuándo conviene más una API de mapas o un SDK?

Elija una API o SDK cuando el mapa sea parte del estado de la aplicación, cuando el producto utilice datos privados o con licencia, cuando los flujos de trabajo incluyan acciones comerciales personalizadas o cuando la experiencia esté altamente diferenciada. Los productos de propiedad, venta al por menor, mercado y movilidad a menudo sincronizan usuarios con inicio de sesión, búsquedas guardadas, inventario dinámico, límites de mapas, resultados seleccionados, clasificación del lado del servidor y permisos específicos de la cuenta. El SDK del mapa participa en ese estado; la aplicación host sigue siendo la fuente de la verdad.

El inventario privado, las existencias de la tienda, las direcciones de los clientes, los activos internos, los datos de la flota, la elegibilidad del servicio, los listados fuera del mercado y los incidentes operativos deben ser filtrados por el backend del host, por lo que el navegador solo recibe los registros requeridos para la vista actual. Las acciones personalizadas, como crear un lead, reservar un activo, asignar un controlador, actualizar un registro de propiedad, guardar un territorio o escribir en una base de datos privada, deben ser validadas y ejecutadas por la aplicación host incluso cuando el mapa las inicia. El estado sincronizado de lista y mapa, la agrupación personalizada, la animación a medida, el movimiento en tiempo real, el dibujo de geometría, el enrutamiento personalizado, las capas WebGL, los controles específicos del dominio y las superposiciones complejas refuerzan el caso para el control del desarrollador.

¿Cuándo resulta más sólida una arquitectura híbrida?

Muchos equipos no deberían elegir una sola vía. Una arquitectura híbrida separa la creación de contenido de la lógica de negocio en tiempo de ejecución: los creadores gestionan lugares, rutas, diseño visual, narrativas públicas y guías de marca con un constructor sin código; los desarrolladores insertan o amplían ese trabajo mediante Viewer o un SDK; la aplicación anfitriona conserva perfiles, reservas, inventario privado, recomendaciones por cuenta, anuncios en tiempo real, búsquedas guardadas, permisos, procesos comerciales, precios y estado operativo. Turismo, inmobiliario y comercio minorista suelen adoptar este modelo porque el contenido público convive con operaciones privadas.

La regla práctica es la propiedad progresiva. Mantenga el contenido editorial y el diseño de la marca donde los creadores puedan actualizarlos. Mantenga la identidad, la autorización, los datos privados y las acciones consecuentes en el sistema host. Reutilizar mapas base diseñados y mapas publicados como entradas de integración en lugar de reconstruir cada decisión visual en el código.

¿Cómo conecta Kaleidr los flujos sin código y de desarrollo?

Kaleidr está estructurado en torno a la creación visual y la integración de desarrolladores. Studio utiliza el modelo de implementación de Prompt → Process → Desplegar para la personalización visual del contenido, el estilo, la interacción, los mapas base personalizados, las capas, los conjuntos de datos, los datos en tiempo real y la visualización 3D. Un mapa publicado puede incrustarse a través de Viewer por ID de compartir; el inicio rápido actual indica que un Visor publicado está asignado al enlace de uso compartido y no necesita una clave de API (Visor incrustado). Chat puede adjuntarse a un mapa de Mapbox, Google Maps, MapLibre o Leaflet en vivo compatible con una clave publicable mientras el renderizador existente mantiene la responsabilidad de la pantalla. El editor monta herramientas de creación de mapas dentro de un producto SaaS host cuando los usuarios deben crear sin salir del flujo de trabajo del producto. El acceso a la API de la plataforma en Pro y Enterprise admite claves publicables y de servidor para una lógica de lado de servidor personalizada más profunda (Precios y planes).

Ruta progresiva desde la creación de mapas visuales hasta el visor publicado y los componentes SDK hasta una integración de API de plataforma personalizada.

Un visor mínimo publicado coloca el elemento personalizado después de que el cargador versionado esté presente en la página. Reemplazar abcd1234 Con el ID de compartición del mapa publicado, y mantener una altura explícita para que el diseño no se colapse antes de que el mapa pinte. Prefiera el componente documentado sobre la construcción de una URL interna del visor que no sea parte del contrato público.

<kaleidr-map
  product="viewer"
  share-id="abcd1234"
  style="display:block; height:520px;">
</kaleidr-map>

El archivo adjunto de chat contra un mapa en vivo existente utiliza el montaje imperativo después de que el cargador esté disponible. Mantenga la clave publicable restringida a los alcances seguros del navegador, destruya el mango durante el desmontaje de SPA y deje la responsabilidad de la visualización del mapa con el renderizador del host. Confirme los contratos de productos actuales en el Documentación para desarrolladores Antes de cerrar una arquitectura.

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "kld_pk_live_REPLACE_ME",
  map: myMap
});

Una progresión práctica es: comience con Studio, publique a través de Viewer, agregue Chat o Tiles donde sea útil, incruste Editor cuando la creación perteneza al interior del producto y use la API de la Plataforma cuando el flujo de trabajo necesite una lógica de servidor personalizada. Trate cada paso como profundidad opcional en lugar de una escalera obligatoria. Los equipos que solo necesitan una experiencia publicada pueden detenerse en Viewer sin adoptar cada superficie posterior.

¿Cómo cambian los costes, la seguridad, la accesibilidad y la búsqueda?

El costo del constructor generalmente se concentra en suscripción, cargas de mapas, créditos de IA, colaboradores, almacenamiento, datos premium, publicación y soporte. El costo de la API se extiende a través de cargas de mapas, mosaicos, geocodificación, lugares, rutas, inferencia de IA, CDN, almacenamiento, ingeniería, observabilidad, seguridad, respuesta a incidentes y mantenimiento continuo. La parte cara de una arquitectura personalizada a menudo no es la llamada API en sí; es la ingeniería y las operaciones que la rodean. Kaleidr actualmente enumera gratis en $0, Pro a $29 por mes, y Enterprise con precios personalizados; Pro agrega acceso a la API de desarrollador, claves publicables y de servidor, e incorpora soporte. Compruebe el live Página de precios Antes de la compra, porque las asignaciones pueden cambiar.

Las responsabilidades de seguridad difieren por camino. Un constructor todavía requiere decisiones sobre la visibilidad pública versus privada, dominios de incrustación permitidos, campos expuestos, permisos de intercambio y datos confidenciales. Un flujo de trabajo de API personalizado agrega credenciales de navegador versus backend, restricciones de clave de API, autorización de inquilinos, CORS, límites de velocidad, rotación de claves, registro de auditoría y recuperación de datos privados. Google Maps Platform recomienda restringir las claves de la API por aplicación y API y separar el uso del lado del cliente y del servidor (Guía de seguridad de Google Maps Platform). Mapbox distingue los tokens de cliente público de los tokens secretos del servidor (Los tokens de acceso a Mapbox). Kaleidr distingue las claves de navegador publicables de las claves del servidor con capacidades de alcance. Una credencial visible para el navegador debe estar diseñada y restringida para el uso del navegador; una credencial de servidor debe permanecer en el servidor.

La accesibilidad y la búsqueda no son automáticas en ninguna de las rutas. Pruebe el acceso al teclado, el enfoque visible, el tamaño de destino suficiente, las alternativas de texto, las vistas de lista sincronizadas, el contraste de color, los indicadores de estado no color, las etiquetas del lector de pantalla, el enfoque modal, el zoom, el diseño móvil y las alternativas al arrastre. Proporcione una copia de página rastreable, encabezados significativos, información importante del lugar fuera del lienzo donde sea útil, metadatos precisos y datos estructurados solo cuando coincida con el contenido visible. Evite ocultar todo el contenido significativo detrás de la interacción solo con el cliente y evite generar páginas delgadas para cada estado de coordenadas o filtros.

¿Qué errores de decisión deben evitar los equipos?

Error ¿Qué pasa Corrección recomendada
Elegir sin código solo porque no hay desarrolladores Requisitos de flujo de trabajo personalizados aparecen más tarde Definir el estado, los permisos, los datos y las acciones primero
Elegir API porque se supone que la costumbre es mejor El esfuerzo de ingeniería crece sin valor de usuario Comienzo del comportamiento del producto requerido
Tratar un mapa publicado como una base de datos operativa Hechos dinámicos se vuelven obsoletos Mantenga los sistemas de origen autorizados
Tratar una API de mapa como la aplicación completa La interfaz de usuario, el aut, la analítica y la accesibilidad están subestimados Presupuesto para el producto anfitrión
Coding cada mapa desde cero Los editores dependen de la ingeniería para las actualizaciones de rutina Autoría separada de la lógica de tiempo de ejecución
Ocultar todo el contenido dentro del lienzo del mapa Búsqueda y accesibilidad sufren Proporciona contenido accesible y rastreable de soporte
Exponer credenciales de servidor Acceso de backend se hace público Utilice claves seguras para el navegador y secretos del lado del servidor
Ignorar la migración La arquitectura de prototipo se vuelve permanente Defina una ruta de creación a API a API
Optimización solo para la velocidad de lanzamiento El mantenimiento sorprende al equipo Comparar la propiedad total
Optimización solo para la flexibilidad El equipo desarrolla capacidades no utilizadas Esquie la arquitectura para validar los flujos de trabajo

Árbol de decisiones que elige entre un generador de mapas sin código, una aplicación API o SDK y una arquitectura de mapa híbrido.

¿Cómo elegir entre constructor, API o modelo híbrido?

Elija un constructor de mapas sin código cuando la mayoría de estos son verdaderos: el mapa es principalmente una experiencia publicada; los no desarrolladores necesitan mantenerlo; el modelo de interacción se ajusta a los controles compatibles; los cambios de datos son editoriales o respaldados por la plataforma; la velocidad de publicación importa; el estado específico del usuario es limitado; y el equipo prefiere que la plataforma opere más infraestructura. Elija una API de mapa o un SDK cuando la mayoría de estos son verdaderos: el mapa es central para el comportamiento de la aplicación; la aplicación host posee el estado del usuario; se requieren datos privados o con licencia; las acciones comerciales ocurren desde el mapa; los permisos difieren según el usuario o el inquilino; el estado en tiempo real o las capas inusuales importan; y el mapa debe sincronizarse con otros componentes del producto. Elija un modelo híbrido cuando los creadores necesitan creación visual, los desarrolladores necesitan integración controlada, los datos públicos y privados deben coexistir, el diseño de la marca debe ser reutilizable y el equipo quiere un punto de partida simple con una ruta de integración más profunda.

Antes de confirmar, identifique al usuario principal del mapa, defina el rol de publicación versus la aplicación, documente las fuentes de datos, los datos privados y con licencia separados y nombre al propietario del contenido. Enumere las acciones de estado y de negocio específicas del usuario, confirme los requisitos de renderizador y diseño, y defina la publicación y la incorporación. Establezca los requisitos de accesibilidad y SEO, defina eventos analíticos, revise las credenciales del navegador y del servidor, estime el mantenimiento de la ingeniería y defina una ruta de migración desde el constructor hasta la API.

Veredicto final

Un constructor de mapas sin código y una API de mapas resuelven capas distintas del mismo problema de producto. Elige un constructor de mapas sin código cuando el equipo necesite crear, diseñar, publicar y mantener un mapa interactivo con un esfuerzo de ingeniería mínimo. Elige una API de mapas o un SDK cuando el mapa deba intervenir profundamente en el estado de la aplicación, los datos privados, los permisos, la lógica de negocio o la interacción personalizada. Para muchos equipos, la arquitectura más sólida es progresiva: crear visualmente cuando sea posible, insertar componentes mantenidos, añadir código donde lo exija el flujo y conservar los datos oficiales y las acciones relevantes en el sistema anfitrión. Kaleidr Studio, Viewer, Chat, Editor, Tiles y Platform API siguen esa progresión para que la primera decisión de publicación no se convierta en la arquitectura permanente.

Empieza a crear mapas visualmente en Kaleidr Studio

Usa Kaleidr Studio para pasar de una descripción a un mapa interactivo refinado y coherente con tu marca. Amplía la integración mediante Viewer, Chat, Editor, Tiles y Platform API cuando el producto anfitrión lo requiera. Empieza a crear en Kaleidr Studio si el siguiente paso es una experiencia cartográfica publicada y no el esqueleto vacío de una aplicación.

Preguntas frecuentes

¿Qué es un constructor de mapas sin código?

Un constructor de mapas sin código es un producto visual o impulsado por avisos que permite a los usuarios crear, diseñar y publicar mapas interactivos sin implementar el renderizador y la pila de publicación ellos mismos.

¿Qué es una API de mapas?

Una API de mapa expone datos u operaciones geográficas de forma programática, como geocodificación, búsqueda de lugares, rutas, mosaicos, estilos o características espaciales.

¿Es mejor un constructor sin código que una API de mapas?

Ninguno de los dos es universalmente mejor. Un constructor es más fuerte para la creación y publicación visual. Una API es más fuerte cuando el mapa requiere estado personalizado, datos privados, permisos o lógica de negocio.

¿Puedo empezar sin código y usar una API más adelante?

Sí, cuando la plataforma proporciona una ruta de integración. Kaleidr separa la creación visual en Studio de las superficies de la API Viewer, Chat, Editor, Tiles y Platform.

¿Kaleidr Studio exige programar?

Kaleidr Studio se encuentra actualmente posicionado como prompt-first y visual. La codificación se vuelve relevante cuando un equipo necesita incrustación de SDK, integraciones privadas, estado de aplicación personalizado o flujos de trabajo de API de plataforma.

¿Se puede insertar un mapa sin código en un sitio web?

Sí, cuando el constructor admite la publicación e incrustación. El Visor actual de Kaleidr puede incrustar un mapa publicado por ID de compartir.

¿Cuándo debo usar un SDK en lugar de una API directa?

Utilice un SDK cuando desee mantener los componentes de la interfaz de usuario, la autenticación del navegador, el manejo del ciclo de vida, el archivo adjunto de mapa o los adaptadores de proveedor. Utilice una API en bruto cuando necesite orquestación de servidor personalizada o una interfaz completamente personalizada.

¿MapLibre es una API de mapas?

MapLibre GL JS es principalmente una biblioteca de representación de mapas de código abierto. El equipo de host proporciona o elige los estilos, teselas y servicios de datos utilizados por el renderizador.

Referencias

@misc{kaleidr_studio,
  title  = {Create Custom Maps with AI Map Maker},
  author = {{Kaleidr}},
  note   = {Accessed 7 August 2026},
  url    = {https://kaleidr.com/studio}
}

@misc{kaleidr_quickstart,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 7 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@misc{google_maps_js,
  title  = {Overview -- Maps JavaScript API},
  author = {{Google}},
  note   = {Google Maps Platform documentation; accessed 7 August 2026},
  url    = {https://developers.google.com/maps/documentation/javascript/overview}
}

@misc{google_maps_security,
  title  = {Google Maps Platform security guidance},
  author = {{Google}},
  note   = {Accessed 7 August 2026},
  url    = {https://developers.google.com/maps/api-security-best-practices}
}

@misc{mapbox_getting_started,
  title  = {Getting Started},
  author = {{Mapbox}},
  note   = {Accessed 7 August 2026},
  url    = {https://docs.mapbox.com/help/getting-started/}
}

@misc{maplibre_intro,
  title  = {Introduction -- MapLibre GL JS},
  author = {{MapLibre}},
  note   = {Accessed 7 August 2026},
  url    = {https://maplibre.org/maplibre-gl-js/docs/}
}