Cómo lanzar un sitio web de mapas sin código

Un sitio web de mapas sin código combina un mapa interactivo, datos de ubicación estructurados, contenido explicativo, búsqueda y filtros, fichas de lugares y acciones para el cliente. Se ensambla mediante plantillas y configuración, no con código front-end a medida. La plataforma absorbe la implementación rutinaria, pero el editor conserva las decisiones que determinan el resultado: qué datos incluye el mapa, qué pregunta responde la interfaz y qué acción debe completar el visitante. Si esas decisiones encajan con el flujo de Kaleidr, comience en Kaleidr Studio, genere el mapa con una instrucción, perfeccione el diseño y publíquelo o insértelo. Use este artículo como la lista de producción que ninguna plantilla puede omitir.

Alcance y evidencia

«Sin código» describe un enfoque en el que las personas crean una aplicación con plantillas, formularios, controles visuales y componentes preconstruidos, en vez de escribir la mayor parte del código. No elimina el software, la infraestructura, el modelado de datos, las pruebas ni la responsabilidad técnica. El no-code depende de ajustes y componentes reutilizables; el low-code añade scripts, fórmulas, API o componentes limitados; el desarrollo personalizado ofrece control directo sobre arquitectura y código fuente.

La investigación disponible no demuestra que el no-code reduzca siempre el coste total o el plazo. Una revisión de 40 estudios publicados entre 2017 y 2023 sobre la adopción del desarrollo low-code y no-code documenta beneficios buscados y problemas encontrados. Otra revisión pregunta qué dice la investigación sobre la viabilidad del low-code. En conjunto describen una compensación y una decisión organizativa, no un beneficio automático de la herramienta.

Este artículo combina esa literatura con estudios de cartografía interactiva y normas oficiales sobre datos geográficos, accesibilidad, indexación, rendimiento, privacidad, seguridad de API y licencias. Cuando una afirmación es una inferencia, se indica. El marco trata decisiones de producción, no promesas comerciales.

Resumen ejecutivo

El no-code redistribuye el trabajo. La plataforma asume la implementación del front end, la integración de alojamiento, el diseño adaptable y el comportamiento de componentes; el equipo conserva el objetivo del usuario, la exactitud geográfica, las interacciones, las pruebas, la protección de información sensible y el mantenimiento.

Funciona mejor con patrones estables: guías de hoteles y destinos, mapas inmobiliarios, localizadores de tiendas, recintos, campus, turismo, eventos y directorios comunitarios. El enrutamiento complejo, grandes datos en tiempo real, autenticación especial, transacciones frecuentes o interfaces inusuales empujan hacia low-code o desarrollo personalizado. Las excepciones constantes convierten una solución no-code en una pila frágil de apaños.

Los mapas añaden coordenadas, límites, capas, zoom, agrupación, atribución, permisos de ubicación, vigencia, interacción móvil y alternativas no cartográficas. Una plantilla atractiva no corrige coordenadas erróneas, controles inaccesibles, renderizado lento ni una tarea confusa.

Qué es realmente un sitio web de mapas sin código

Se compone de lienzo cartográfico, navegación, búsqueda, filtros de categoría, marcadores, capas geográficas, tarjetas, páginas de detalle, formularios, eventos analíticos y secciones adaptables. El editor elige diseño y estilo, carga datos, asigna campos a títulos y descripciones, activa filtros, aplica la marca, conecta un dominio y publica. La plataforma convierte esas opciones en comportamiento; registra decisiones, no las toma.

El código, las bibliotecas de mapas, bases de datos, CDN, API, alojamiento y controles de seguridad siguen existiendo detrás de una interfaz superior. La reutilización reduce el coste de patrones comunes y limita los poco comunes. El no-code aporta valor cuando los requisitos caben en las capacidades existentes.

Sin código no significa sin trabajo técnico

El esfuerzo pasa de la sintaxis a la configuración, preparación de datos, diseño de interfaz, gobernanza y control de calidad. Aunque el editor evita implementar estructuras, estado, biblioteca cartográfica y alojamiento, todavía debe preparar datos compatibles, asignar campos, elegir comportamientos, probar dispositivos, administrar permisos y comprobar lo publicado.

La deuda técnica cambia de forma: en una aplicación propia vive en el código y dependencias antiguas; en no-code, en ajustes sin documentar, nombres incoherentes, duplicados, integraciones sin gobierno, fórmulas específicas y procesos que solo una persona entiende. Documente fuentes, definiciones, funciones, integraciones, dominios, publicación, eventos analíticos y recuperación con disciplina de código.

Asigne también un responsable de negocio, datos, contenido y administración. Una persona puede asumir varios papeles, pero ninguno debe quedar implícito.

Elegir el modelo de entrega adecuado

La elección depende de interacción, control, integración y mantenimiento. Los cinco modelos no forman una escala de calidad; responden a problemas distintos. Lea primero la limitación.

Un mapa insertado añade contexto a una página; un sitio cartográfico organiza todo el recorrido alrededor del descubrimiento espacial. Mostrar una oficina turística requiere un embed; buscar atracciones, filtrar, comparar barrios, abrir detalles y planificar rutas requiere un sitio. Elija el modelo menos complejo que cumpla la tarea sin soluciones provisionales relevantes.

1. Defina la decisión del usuario antes de configurar el mapa

El mapa debe apoyar una decisión, no mostrar todos los registros. Un huésped elige dónde comer caminando; un comprador compara propiedades por barrio y transporte; un cliente encuentra la tienda más cercana con un servicio; un visitante localiza aparcamiento, entradas o rutas accesibles. Son productos distintos.

Resuma audiencia, decisión, geografía y resultado en una frase: «El sitio ayudará a huéspedes a identificar lugares cercanos según sus intereses y obtener indicaciones desde el hotel». De ella se derivan origen, lugares, categorías, distancia o ruta y acción de indicaciones; quedan fuera análisis GIS, cuentas y edición. Responda antes de configurar:

• ¿Quién usará el sitio?
• ¿Qué decisión debe apoyar el mapa?
• ¿Qué zona cubrirá?
• ¿Qué lugares, límites o rutas aparecerán?
• ¿Qué atributos determinan la idoneidad?
• ¿Qué acción sigue al descubrimiento?
• ¿Qué información cambia con frecuencia?
• ¿Qué información exige autenticación?
• ¿Qué métrica demuestra que la tarea se completó?

2. Cree una base fiable de datos de ubicación

La calidad del sitio no supera la de sus datos. Coordenadas incorrectas, duplicados, categorías incoherentes, horarios antiguos y enlaces rotos invalidan una interfaz pulida. Cada elemento necesita un identificador estable para distinguir registros, preservar enlaces, actualizar lugares, conectar analítica y evitar duplicación.

Un punto suele incluir nombre, categoría, latitud, longitud, dirección, descripción, estado, imagen, URL y fecha de actualización. Un polígono representa una propiedad, área de servicio, distrito, campus o evento; una línea, una ruta, sendero, corredor o tramo. Separe campos públicos de presentación de identificadores de origen, estado interno, fecha y notas de calidad.

RFC 7946 define GeoJSON y coordenadas WGS 84 en grados decimales. Un error frecuente: GeoJSON guarda longitud-latitud, no latitud-longitud. Invertirlas coloca el elemento en otro país o fuera del intervalo válido.

{
  "type": "Feature",
  "id": "location-001",
  "geometry": { "type": "Point", "coordinates": [-73.9857, 40.7484] },
  "properties": {
    "name": "Example Location",
    "category": "visitor-service",
    "status": "active",
    "address": "100 Example Avenue",
    "detail_url": "/locations/example-location",
    "updated_at": "2026-07-15T12:00:00Z"
  }
}

CSV y hojas de cálculo también son habituales. Antes del primer importe, normalice nombres, valores, fechas, precisión y reglas de campos vacíos.

• Asigne un ID único a cada elemento.
• Valide intervalos de latitud y longitud.
• Normalice categorías y estados.
• Elimine duplicados antes de importar.
• Compruebe todas las URL públicas.
• Registre fuente y fecha de información operativa.
• Separe campos públicos, internos y sensibles.
• Pruebe límites inválidos o autointersecados.
• Haga una copia antes de actualizaciones grandes.
• Programe revisiones de registros sensibles al tiempo.

3. Diseñe la arquitectura de información

El sitio necesita organización espacial y web convencional. El mapa facilita explorar; la estructura facilita navegar, explicar, indexar, acceder y enlazar directamente. Suele incluir inicio, explorador, categorías, páginas de lugares, información corporativa, ayuda, privacidad y contacto o conversión.

No deje información importante solo en el mapa. Pop-ups, etiquetas en canvas y capas dinámicas tienen visibilidad y accesibilidad limitadas. Nombres, direcciones, servicios, descripciones y acciones también deben existir como texto y páginas. Una URL estable permite compartir, indexar, medir y dar soporte.

Una lista sincronizada ofrece una alternativa escaneable, admite teclado, reduce la dependencia del puntero y funciona si el mapa falla. Nombre categorías con el lenguaje del visitante —«Dónde comer»—, no con códigos internos.

4. Configure la interacción en torno a la tarea

La taxonomía empírica de Roth reduce la interacción a identificar, comparar, ordenar, asociar y delimitar. Su estudio posterior indica que la complejidad debe ajustarse a capacidad y motivación. Una interfaz desagradable puede hacer fracasar a alguien capaz.

Active solo los controles que sirven al objetivo. La extensión inicial debe mostrar el contexto pertinente. Comunique categoría y selección con forma, icono, etiqueta, contorno y tamaño, no solo color. Para puntos densos use agrupación, agregación, visualización por escala o filtrado en servidor.

Los filtros deben reflejar criterios reales: distancia, cocina, horario y accesibilidad para hoteles; precio, tipo, disponibilidad y transporte para propiedades. Incluya restablecer. La selección del marcador y la lista debe sincronizarse.

Active por defecto búsqueda, zoom, restablecer vista, categorías, recuento, detalles, leyenda, lista accesible, indicaciones cuando procedan y ubicación actual solo si se justifica. Añada dibujo, medición, consultas espaciales, varios mapas base, edición, coordenadas, tiempo o 3D únicamente cuando la tarea lo exija.

5. Comunique procedencia e incertidumbre

Un mapa parece autorizado aunque sus datos sean incompletos o antiguos. Una revisión de estudios sobre visualización de incertidumbre halló muchas técnicas nuevas pero poca evaluación empírica y recomienda pruebas centradas en la tarea. Por ello, ninguna técnica concreta debe presentarse como universal.

Identifique al responsable de los datos y muestre la fecha cuando la vigencia afecte la interpretación. Distinga propiedades disponibles, no disponibles y desconocidas; rutas temporales y cierres; recursos verificados y no verificados.

Evite precisión falsa. Un área aproximada no debe parecer un límite legal medido; una coordenada estimada no debe representarse como entrada confirmada. Un aviso breve y específico ayuda, pero no sustituye la calidad.

6. Personalice la marca sin reducir la legibilidad

Logo, tipografía, colores de página, botones, cabecera, pie, imágenes y CTA pertenecen a la marca web; mapa base, símbolos, colores de capas, estados, etiquetas y paneles, al diseño cartográfico. Un color corporativo puede funcionar en el logo y fallar sobre el mapa. No imponga toda la paleta a la cartografía.

Reserve el mayor énfasis para la acción principal y use etiquetas precisas: «Ver propiedad», «Comprobar disponibilidad», «Reservar», «Llamar a este lugar» o «Crear ruta». Diseñe con igual cuidado estados vacíos, de carga y error; allí se decide la confianza.

7. Diseñe para móviles y redes variables

Los mapas cargan código, estilos, geodatos, imágenes, fuentes, marcadores y servicios externos. Móvil no consiste en encoger escritorio: cambian tacto, espacio, orientación, rendimiento y red. El teléfono combina a menudo la página más pesada con la conexión más débil.

Google usa la versión móvil para indexar y clasificar y recomienda equivalencia de contenido y metadatos. Puede mover contenido a paneles o pestañas, pero no eliminarlo. Cargue título, explicación y controles principales antes o junto al mapa.

Core Web Vitals considera buenos LCP de 2,5 segundos, INP de 200 ms o menos y CLS de 0,1 o menos, en el percentil 75 y por móvil/escritorio. INP sustituyó a FID en 2024.

Una portada rápida no demuestra el rendimiento del mapa. Mida filtros, selección, desplazamiento, búsqueda, paneles y rutas en dispositivos reales o emulados, redes lentas, datos grandes y visitas iniciales y repetidas.

• Cargue solo capas iniciales.
• Pagina o recupere progresivamente resultados grandes.
• Simplifique polígonos con poco zoom.
• Agrupe puntos densos.
• Comprima imágenes y use tamaños adaptables.
• Almacene activos estables en caché.
• Reserve espacio para mapa y medios.
• Limite scripts externos.
• Mida usuarios reales después del lanzamiento.
• Fije presupuestos de rendimiento para cambios.

8. Trate la accesibilidad como requisito de lanzamiento

Los mapas concentran riesgo porque dependen de visión, puntero, color, arrastre, zoom y relaciones espaciales. WCAG 2.2 es el marco vigente del W3C. Una plantilla puede dar bases, pero no garantiza la conformidad después de añadir colores, imágenes, contenido, integraciones y conducta; la conformidad pertenece al producto publicado.

El teclado debe alcanzar búsqueda, filtros, resultados, detalles y acciones, con foco visible. Los iconos necesitan nombres accesibles. Arrastrar no puede ser el único método; WCAG 2.2 trata arrastre y tamaño de objetivos. El color no debe ser la única señal.

Una lista, tabla o vista estructurada debe permitir encontrar y usar los registros sin mapa. Anuncie cambios de resultados y errores a tecnologías de asistencia. Pruebe la tarea completa con teclado, lector, zoom, alto contraste, movimiento reducido y accesibilidad móvil; las herramientas automáticas solo detectan una parte.

• Título y jerarquía de encabezados significativos.
• Alternativas de texto para imágenes.
• Etiquetas para formularios y controles.
• Contraste suficiente y estado no dependiente del color.
• Teclado con foco visible.
• Objetivos táctiles adecuados.
• Lista o contenido alternativo accesible.
• Anuncios de recuentos y errores.
• Sin movimiento forzado.
• Prueba del flujo completo.

9. Genere visibilidad fuera del lienzo

Exponga la información mediante páginas rastreables, no solo marcadores, pop-ups y canvas. Google procesa JavaScript mediante rastreo, renderizado e indexación; el renderizado y errores pueden retrasar o impedir el descubrimiento. Publique tema, descripciones, servicios, categorías e información del cliente en HTML semántico y prefiera renderizado de servidor o prerenderizado para lo esencial.

Cada lugar importante necesita URL estable e indexable con título, descripción, dirección, atributos, texto propio y enlaces. Móvil debe conservar el contenido. Los datos estructurados LocalBusiness describen tipo, dirección, horas y departamentos, deben coincidir con la página y no garantizan resultados.

El sitemap ayuda, no garantiza indexación; la navegación debe tener enlaces rastreables. Para motores de respuesta, declare hechos, entidad y fecha, y separe evidencia de promoción. No genere cientos de páginas delgadas que solo cambian el nombre del lugar.

10. Solicite ubicación solo cuando la tarea la necesite

La ubicación mejora localizadores, turismo, propiedades y rutas, pero crea obligaciones de privacidad. La especificación W3C Geolocation define la interfaz y consideraciones de permiso. Es un Candidate Recommendation Snapshot del 26 de marzo de 2026, no una Recommendation final.

No solicite ubicación precisa al llegar solo porque sea posible. Use un control iniciado por el usuario —«Usar mi ubicación»— y explique antes el propósito. Si se rechaza, dirección, ciudad, código postal o búsqueda deben lograr el mismo resultado.

Minimice recogida y retención. Un cálculo puntual no necesita guardar coordenadas; la analítica no debe registrar coordenadas brutas sin requisito y protección. Regiones aproximadas o bandas de distancia suelen bastar.

11. Proteja datos, API, formularios y administración

El no-code no elimina el riesgo: siguen conectados API, formularios, bases, analítica, geocodificación, rutas, pagos y cuentas. Separe datos públicos y restringidos antes de importar. Un campo «oculto» con clientes, notas internas o información confidencial sigue en el sitio; ocultar no es una frontera de seguridad.

Restrinja tokens visibles por dominio, alcance, cuota y entorno; los secretos del servidor nunca deben aparecer en código o archivos públicos. Revise las integraciones con OWASP API Security Top 10: autorización por objeto, autenticación, consumo sin límites, mala configuración, inventario e ingestión insegura de terceros.

Use acceso por funciones para que editar contenido no conceda facturación, dominios, seguridad, integraciones y usuarios. Los formularios necesitan validación, límites, endpoints protegidos y retención. Entregue a terceros solo lo necesario y revise acceso, transferencias, borrado, incidentes y terminación antes de conectar.

El NIST Privacy Framework estructura la gestión del riesgo. Mantenga además un inventario y elimine servicios obsoletos: los proyectos no-code acumulan complementos abandonados porque cada alta parece gratuita.

12. Verifique licencias, atribución y términos

Mapas base, datos, satélite, iconos, fuentes, fotos, lugares, geocodificación y rutas pueden tener reglas distintas. Los datos OpenStreetMap son abiertos, pero sus servidores públicos se rigen por una Tile Usage Policy separada: capacidad limitada, sin SLA y con bloqueo posible. Producción necesita un proveedor o alojamiento adecuado y la atribución correspondiente.

Los proveedores comerciales añaden cuotas, precio por solicitud, restricciones de visualización, tokens, caché, almacenamiento y atribución. Registre proveedor, producto, propietario de cuenta, plan, cuota, renovación, texto de crédito y usos permitidos. No recorte créditos por estética y verifique por separado derechos de fotos, logos, descripciones, materiales y datasets. Publicar mediante una plataforma no resuelve propiedad intelectual ajena.

Flujo práctico de publicación

Las doce decisiones se ordenan en diez etapas: datos antes de configuración, configuración antes de contenido y pruebas antes del dominio.

Use staging cuando exista. Editar producción arriesga datos rotos, diseños incoherentes e indexación accidental sin retorno. Registre fecha, versión de datos, cambios, responsable y punto de reversión. Publicar inicia la fase operativa de actualización, revisión, cuentas, rendimiento y soporte; un mapa se vuelve incorrecto más rápido que una página estática.

Control de calidad previo al lanzamiento

Antes de conectar el dominio, haga seis pasadas enfocadas:

Crear la experiencia con Kaleidr

Kaleidr conecta datos de ubicación, mapas interactivos, plantillas web, autoría en Studio, embeds e integraciones. Un proyecto puede combinar mapa, registros estructurados, sitio cartográfico, descubrimiento con IA y analítica. Lugares, zonas, servicios, rutas y contenido aparecen sobre un mapa real; la interfaz conversacional permite preguntar en lenguaje natural. Cómo los buscadores recomiendan negocios se explica en este artículo sobre descubrimiento local con IA.

Kaleidr no toma las decisiones de fondo. La tarea, las coordenadas, la veracidad de atributos, la accesibilidad, la privacidad del permiso y los términos externos siguen siendo responsabilidad de la organización. Una buena plataforma elimina implementación; queda el criterio.

Conclusión

El no-code cambió quién puede publicar un sitio de mapas, no qué lo hace funcionar. Una plantilla entrega diseño, componentes, respuesta y alojamiento rápidamente; no puede decidir la pregunta, verificar coordenadas, mantener horarios, asegurar teclado ni leer términos. Esas decisiones eran el trabajo sustantivo antes y siguen siéndolo.

La prueba es si el modelo menos complejo satisface la tarea sin apaños. Si lo hace, no-code convierte semanas de implementación en configuración y libera esfuerzo para datos, contenido y pruebas. Si no, low-code o desarrollo propio es la respuesta honesta. La investigación aconseja examinar esa compensación antes de adoptar.

Preguntas frecuentes

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

Un mapa interactivo con datos estructurados, contenido, búsqueda, filtros, detalles y acciones, ensamblado con plantillas y configuración. La plataforma genera la base; el editor gestiona datos, contenido, marca y conducta.

¿No-code significa que no hay trabajo técnico?

No. El trabajo se desplaza a configuración, datos, interfaz, gobernanza y pruebas. Siguen siendo necesarios campos, comportamiento, dispositivos, permisos y mantenimiento.

¿Cuándo es una mala elección?

Cuando la experiencia no encaja en patrones reutilizables: rutas complejas, datos en tiempo real a gran escala, autenticación especial, transacciones frecuentes o interfaces inusuales.

¿Reduce coste y tiempo?

No siempre. La investigación informa beneficios y dificultades. La ganancia depende de que los requisitos estén dentro de las capacidades de la plataforma.

¿Qué formatos de datos acepta?

Muchas plataformas aceptan GeoJSON según RFC 7946, con WGS 84 y orden longitud-latitud. También son comunes CSV y hojas de cálculo.

¿Puede posicionarse en buscadores?

Solo mediante contenido rastreable. Use HTML semántico y URL estables por lugar; mantenga el contenido esencial en móvil porque Google lo indexa.

¿Qué objetivos de rendimiento debe cumplir?

En el percentil 75: LCP en 2,5 s, INP hasta 200 ms y CLS hasta 0,1. Mida además filtros, selección, movimiento y búsqueda.

¿Cómo se aplica la accesibilidad?

WCAG 2.2 se aplica plenamente: teclado, nombres accesibles, alternativas al arrastre y al color, y lista o tabla como vía no cartográfica.

¿Puede un sitio comercial usar OpenStreetMap gratis?

Los datos son abiertos, pero los tiles públicos tienen política separada, capacidad limitada y sin SLA. Use provisión adecuada y atribución visible.

¿Debe pedir la ubicación del visitante?

Solo cuando la tarea la requiera y desde una acción explicada. La experiencia debe funcionar si se rechaza y no debe guardar datos innecesarios.

Referencias

• Ajimati, M. O., Carroll, N., & Maher, M. (2025). Adoption of low-code and no-code development: A systematic literature review and future research agenda. Journal of Systems and Software, 222, 112300. https://doi.org/10.1016/j.jss.2024.112300
• Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., & Schaub, T. (2016). The GeoJSON Format (RFC 7946). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc7946
• Gao, D., Fagerholm, F., & Toivanen, V. (2026). What does current research say about the viability of low-code development? A systematic literature review. Journal of Systems and Software, 239, 112893. https://doi.org/10.1016/j.jss.2026.112893
• Google. Core Web Vitals. web.dev. Accessed 15 July 2026. https://web.dev/articles/vitals
• Google. Local Business (LocalBusiness) structured data. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/local-business
• Google. Mobile-first indexing best practices. Google Search Central. https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
• Google. Understand JavaScript SEO basics. Google Search Central. https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
• Kinkeldey, C., MacEachren, A. M., & Schiewe, J. (2014). How to assess visual communication of uncertainty? A systematic review of geospatial uncertainty visualisation user studies. The Cartographic Journal, 51(4), 372–386. https://doi.org/10.1179/1743277414Y.0000000099
• National Institute of Standards and Technology. NIST Privacy Framework. https://www.nist.gov/privacy-framework
• OpenStreetMap Foundation. Licence/Attribution Guidelines. https://osmfoundation.org/wiki/Licence/Attribution_Guidelines
• OpenStreetMap Foundation. Tile Usage Policy. https://operations.osmfoundation.org/policies/tiles/
• OWASP. (2023). OWASP Top 10 API Security Risks — 2023. https://owasp.org/API-Security/editions/2023/en/0x11-t10/
• Roth, R. E. (2013). An empirically-derived taxonomy of interaction primitives for interactive cartography and geovisualization. IEEE Transactions on Visualization and Computer Graphics, 19(12), 2356–2365. https://doi.org/10.1109/TVCG.2013.130
• Roth, R. E. (2015). Interactivity and cartography: A contemporary perspective on user interface and user experience design from geospatial professionals. Cartographica, 50(2), 94–115. https://doi.org/10.3138/cart.50.2.2427
• W3C. (2026). Geolocation (W3C Candidate Recommendation Snapshot, 26 March 2026). https://www.w3.org/TR/2026/CR-geolocation-20260326/
• W3C. (2023). Web Content Accessibility Guidelines (WCAG) 2.2 (W3C Recommendation). https://www.w3.org/TR/WCAG22/

@article{ajimati2025lcnc,
  title   = {Adoption of low-code and no-code development: A systematic literature review and future research agenda},
  author  = {Ajimati, Matthew Oladeji and Carroll, Noel and Maher, Mary},
  journal = {Journal of Systems and Software},
  volume  = {222},
  pages   = {112300},
  year    = {2025},
  doi     = {10.1016/j.jss.2024.112300}
}

@article{gao2026lowcode,
  title   = {What does current research say about the viability of low-code development? A systematic literature review},
  author  = {Gao, Dongmei and Fagerholm, Fabian and Toivanen, Vilma},
  journal = {Journal of Systems and Software},
  volume  = {239},
  pages   = {112893},
  year    = {2026},
  doi     = {10.1016/j.jss.2026.112893}
}

@article{roth2013primitives,
  title   = {An Empirically-Derived Taxonomy of Interaction Primitives for Interactive Cartography and Geovisualization},
  author  = {Roth, Robert E.},
  journal = {IEEE Transactions on Visualization and Computer Graphics},
  volume  = {19},
  number  = {12},
  pages   = {2356--2365},
  year    = {2013},
  doi     = {10.1109/TVCG.2013.130}
}

@article{kinkeldey2014uncertainty,
  title   = {How to Assess Visual Communication of Uncertainty? A Systematic Review of Geospatial Uncertainty Visualisation User Studies},
  author  = {Kinkeldey, Christoph and MacEachren, Alan M. and Schiewe, Jochen},
  journal = {The Cartographic Journal},
  volume  = {51},
  number  = {4},
  pages   = {372--386},
  year    = {2014},
  doi     = {10.1179/1743277414Y.0000000099}
}

@techreport{rfc7946,
  title       = {The GeoJSON Format},
  author      = {Butler, Howard and Daly, Martin and Doyle, Allan and Gillies, Sean and Hagen, Stefan and Schaub, Tim},
  number      = {RFC 7946},
  institution = {Internet Engineering Task Force},
  year        = {2016},
  url         = {https://www.rfc-editor.org/rfc/rfc7946}
}