Lancer un site cartographique sans code

Un site cartographique sans code réunit une carte interactive, des données de localisation structurées, du contenu explicatif, la recherche et le filtrage, des fiches de lieux et des actions client. Il est assemblé par modèles et configuration plutôt qu’avec un front-end sur mesure. La plateforme prend en charge l’implémentation courante, mais l’éditeur reste responsable des décisions décisives : quelles données afficher, à quelle question répondre et quelle action faire accomplir au visiteur. Si le projet correspond au parcours Kaleidr, commencez dans Kaleidr Studio, générez la carte par instruction, ajustez son design, puis publiez-la ou intégrez-la. Cet article fournit la liste de contrôle de production qu’aucun modèle ne remplace.

Périmètre et éléments probants

Le no-code consiste à assembler une application avec des modèles, formulaires, commandes visuelles et composants préconstruits plutôt qu’à écrire l’essentiel de son code. Le logiciel, l’infrastructure, la modélisation des données, les tests et la responsabilité technique ne disparaissent pas. Le no-code s’appuie sur des réglages et composants réutilisables ; le low-code ajoute quelques scripts, formules, API ou composants ; le développement personnalisé donne un contrôle direct sur l’architecture et le code source.

La recherche ne démontre pas une baisse universelle du coût total ou des délais. Une revue de 40 études menées entre 2017 et 2023 sur l’adoption du low-code et du no-code décrit avantages recherchés et difficultés rencontrées. Une autre demande ce que la recherche dit de la viabilité du low-code. Ensemble, elles présentent un arbitrage et une question d’organisation, pas un gain automatique.

L’article rapproche ces travaux de la cartographie interactive et des normes officielles sur les données géographiques, l’accessibilité, l’indexation, la performance, la confidentialité, la sécurité des API et les licences. Les inférences sont signalées comme telles. Le propos porte sur la production, pas sur le marketing d’une plateforme.

Résumé

Le no-code ne supprime pas le travail : il le redistribue. La plateforme assume le front-end, l’intégration de l’hébergement, la mise en page adaptative et le comportement des composants. L’équipe garde l’objectif utilisateur, l’exactitude géographique, les interactions, les tests, la protection des données et la maintenance.

Il convient aux schémas stables : guides d’hôtels et de destinations, cartes immobilières, localisateurs de magasins, plans de sites et de campus, tourisme, événements et annuaires de ressources. Routage complexe, grands flux temps réel, authentification particulière, transactions fréquentes ou interface atypique orientent vers le low-code ou le sur-mesure. Des exceptions constantes transforment une réalisation no-code en empilement fragile de contournements.

Une carte ajoute ses propres exigences : coordonnées, limites, couches, zoom, regroupement, attribution, autorisation de localisation, fraîcheur, interaction mobile et solution non cartographique. Un beau modèle ne corrige ni coordonnées fausses, ni commandes inaccessibles, ni rendu lent, ni objectif flou.

Ce qu’est réellement un site cartographique no-code

Il assemble surface cartographique, navigation, recherche, filtres, marqueurs, couches géographiques, cartes de lieux, pages détaillées, formulaires, événements analytiques et sections adaptatives. L’éditeur choisit la mise en page et le style, importe les données, associe les champs, active les filtres, applique la marque, connecte le domaine et publie. La plateforme traduit ces choix en comportement ; elle les enregistre, elle ne les décide pas.

Le code, les bibliothèques de rendu, bases de données, CDN, API, hébergement et contrôles de sécurité restent présents derrière une interface de haut niveau. La réutilisation réduit le coût des besoins communs mais limite les besoins atypiques. Le no-code est rentable lorsque les exigences entrent dans les capacités existantes.

No-code ne signifie pas absence de travail technique

L’effort se déplace de la syntaxe vers la configuration, la préparation des données, le design, la gouvernance et l’assurance qualité. L’éditeur évite l’implémentation de structures, d’état, de bibliothèque et d’hébergement, mais doit préparer les données, associer les champs, choisir le comportement, tester sur appareils réels, gérer les droits et vérifier la publication.

La dette technique change de forme : complexité du code et dépendances vieillissantes pour une application sur mesure ; réglages non documentés, champs incohérents, doublons, intégrations non gouvernées, formules propres à la plateforme et processus compris par une seule personne en no-code. Documentez sources, définitions, rôles, intégrations, domaines, publication, événements et reprise comme vous documenteriez du code.

Nommez également les responsables métier, données, contenu et administration. Une personne peut cumuler plusieurs fonctions, mais aucune ne doit rester implicite.

Choisir le bon modèle de livraison

Le choix dépend de l’interaction, du contrôle, des intégrations et de la maintenance nécessaires. Les cinq modèles ne constituent pas une échelle de qualité ; ils répondent à des problèmes différents. Commencez par les limites.

Une intégration ajoute du contexte géographique à une page ; un site cartographique organise tout le parcours autour de l’exploration spatiale. Une adresse de bureau exige seulement un embed. Rechercher des attractions, filtrer, comparer des quartiers, consulter des détails et préparer des itinéraires exige un site. Choisissez le modèle le moins complexe qui satisfait la tâche sans contournement important.

1. Définir la décision utilisateur avant de configurer la carte

La carte doit soutenir une décision précise, pas montrer tous les enregistrements. Un client d’hôtel choisit un restaurant accessible à pied ; un acheteur compare des biens par quartier et transports ; un client trouve le magasin le plus proche proposant un service ; un visiteur localise parking, entrée ou parcours accessible. Ce sont des produits différents.

Résumez public, décision, territoire et résultat en une phrase : « Le site aide les clients de l’hôtel à trouver des lieux proches correspondant à leurs intérêts et à obtenir un itinéraire depuis l’hôtel. » Cette phrase impose une origine, des lieux, catégories, distances ou trajets et une action d’itinéraire ; elle exclut analyse SIG, compte et édition. Répondez avant toute configuration :

• Qui utilisera le site ?
• Quelle décision la carte doit-elle soutenir ?
• Quel territoire couvre-t-elle ?
• Quels lieux, limites ou itinéraires apparaissent ?
• Quels attributs déterminent la pertinence ?
• Quelle action suit la découverte ?
• Quelles informations changent souvent ?
• Lesquelles exigent une authentification ?
• Quelle mesure indique l’accomplissement de la tâche ?

2. Construire une base fiable de données de localisation

Le site ne peut dépasser la qualité de ses données. Coordonnées erronées, doublons, catégories incohérentes, horaires périmés et liens morts ruinent une interface soignée. Chaque objet géographique doit avoir un identifiant stable pour distinguer les enregistrements, préserver les liens, mettre à jour un lieu, relier les analyses et éviter les doublons.

Un point contient généralement nom, catégorie, latitude, longitude, adresse, description, état, image, URL détaillée et date de mise à jour. Un polygone représente propriété, zone de service, quartier, campus ou événement ; une ligne, itinéraire, sentier, corridor ou tronçon. Séparez les champs publics de présentation des identifiants source, états internes, dates et notes de qualité.

RFC 7946 définit GeoJSON et les coordonnées WGS 84 en degrés décimaux. Erreur fréquente : GeoJSON enregistre longitude puis latitude, et non l’inverse. Les permuter place l’objet dans le mauvais pays ou hors domaine valide.

{
  "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 et tableurs sont aussi fréquents. Normalisez avant le premier import noms, valeurs, dates, précision et traitement des champs vides.

• Attribuer un ID unique à chaque objet.
• Valider les plages de latitude et longitude.
• Uniformiser catégories et états.
• Supprimer les doublons avant import.
• Vérifier toutes les URL publiques.
• Enregistrer source et date des données opérationnelles.
• Séparer champs publics, internes et sensibles.
• Tester les limites invalides ou auto-intersectées.
• Sauvegarder avant toute mise à jour importante.
• Planifier la revue des informations temporelles.

3. Concevoir l’architecture de l’information

Le site nécessite organisation spatiale et web conventionnelle. La carte sert l’exploration ; la structure sert navigation, explication, indexation, accessibilité et liens directs. Elle comprend souvent accueil, explorateur, catégories, pages de lieux, présentation, aide, confidentialité et contact ou conversion.

Ne laissez pas l’information essentielle dans la seule carte. Pop-ups, labels canvas et superpositions dynamiques offrent peu de visibilité dans la recherche et créent des obstacles. Noms, adresses, services, descriptions et actions doivent aussi apparaître en texte et pages dédiées. Une URL stable permet partage, indexation, mesure et assistance.

Une liste synchronisée fournit une alternative parcourable au clavier et reste disponible si la carte échoue. Nommez les catégories avec les mots du visiteur — « Où manger » — plutôt qu’un code interne.

4. Configurer l’interaction autour de la tâche

La taxonomie empirique de Roth réduit l’interaction à identifier, comparer, classer, associer et délimiter. Son étude ultérieure conclut que la complexité doit correspondre aux capacités et à la motivation. Une interface déplaisante peut faire échouer un utilisateur pourtant compétent.

N’activez donc que les commandes utiles à l’objectif. L’emprise initiale doit montrer le bon contexte. Catégorie et sélection doivent être perceptibles par forme, icône, texte, contour et taille, pas seulement par couleur. Les points denses exigent regroupement, agrégation, affichage selon l’échelle ou filtrage serveur.

Les filtres doivent refléter les vrais critères : marche, cuisine, horaires et accessibilité pour un hôtel ; prix, type, disponibilité et transports pour l’immobilier. Ajoutez une réinitialisation. Marqueur et élément de liste doivent se sélectionner mutuellement.

Activez par défaut recherche, zoom, réinitialisation, catégories, nombre de résultats, détails, légende, liste accessible, itinéraire lorsque pertinent et position actuelle seulement si justifiée. N’ajoutez dessin, mesure, requêtes spatiales, plusieurs fonds, édition, inspection de coordonnées, chronologie ou 3D que si la tâche l’exige.

5. Communiquer provenance et incertitude

Une carte paraît autoritaire même avec des données incomplètes ou anciennes. Une revue systématique de la visualisation de l’incertitude observe de nombreuses techniques mais peu d’évaluations et recommande des tests centrés sur la tâche. Aucun procédé ne doit donc être considéré comme universel.

Identifiez l’organisation responsable et affichez une date lorsque la fraîcheur change l’interprétation. Distinguez biens disponibles, indisponibles et inconnus ; trajets temporaires et fermetures ; ressources vérifiées et non vérifiées.

Évitez la fausse précision. Une zone approximative ne doit pas ressembler à une limite juridique mesurée, ni une coordonnée estimée à une entrée vérifiée. Une limite claire et précise aide, sans remplacer la qualité des données.

6. Personnaliser la marque sans réduire la lisibilité

Logo, typographie, couleurs de page, boutons, en-tête, pied, images et appels à l’action relèvent du site ; fond de carte, symboles, couleurs de couches, états, libellés et panneaux de la cartographie. Une couleur de marque peut être efficace dans un logo et illisible sur la carte. N’imposez pas toute la palette à la représentation géographique.

Réservez l’accent principal à l’action centrale et nommez-la précisément : « Voir le bien », « Vérifier la disponibilité », « Réserver », « Appeler ce lieu », « Créer un itinéraire ». Concevez aussi chargement, absence de résultat et erreur ; ces moments déterminent la confiance.

7. Concevoir pour les mobiles et réseaux variables

Une carte charge code de rendu, styles, géodonnées, images, polices, marqueurs et services. Le mobile ne consiste pas à rétrécir le bureau : tactile, espace, orientation, puissance et réseau changent l’expérience. Le téléphone combine souvent page lourde et connexion faible.

Google utilise la version mobile pour l’indexation et le classement et recommande des contenus et métadonnées équivalents. Le contenu peut passer dans des volets, onglets ou cartes, pas disparaître. Chargez titre, explication et commandes essentielles avant ou avec la carte.

Core Web Vitals considère bons un LCP en 2,5 s, un INP inférieur ou égal à 200 ms et un CLS inférieur ou égal à 0,1, au 75e centile et séparément sur mobile et ordinateur. INP a remplacé FID en 2024.

Un accueil rapide ne prouve rien sur la carte. Mesurez filtres, sélection, déplacement, recherche, panneaux et itinéraires sur appareils réels ou émulés, réseaux lents, grands jeux de données, première visite et visites répétées.

• Charger uniquement les couches initiales.
• Paginer ou récupérer progressivement les grands résultats.
• Simplifier les polygones à faible zoom.
• Regrouper les points denses.
• Compresser les images et fournir des tailles adaptatives.
• Mettre en cache les ressources stables.
• Réserver l’espace de la carte et des médias.
• Limiter les scripts tiers.
• Mesurer les utilisateurs réels après lancement.
• Fixer un budget de performance pour les changements.

8. Faire de l’accessibilité une condition de lancement

Les cartes concentrent les risques parce qu’elles dépendent de la vision, du pointeur, de la couleur, du glisser, du zoom et des rapports spatiaux. WCAG 2.2 est le cadre W3C actuel. Un modèle fournit des bases, mais ne garantit pas la conformité après ajout des couleurs, images, contenus, intégrations et comportements : celle-ci appartient au produit livré.

Le clavier doit atteindre recherche, filtres, résultats, détails et actions, avec un focus visible. Les boutons icônes doivent avoir un nom. Le glisser ne peut être la seule méthode ; WCAG 2.2 couvre mouvements de glissement et taille des cibles. La couleur ne peut être le seul signal.

Une liste, un tableau ou une vue structurée doit permettre de trouver les lieux et d’agir sans carte. Annoncez aux technologies d’assistance changements de résultats et erreurs. Testez le parcours complet au clavier, lecteur d’écran, zoom, contraste élevé, réduction de mouvement et aides mobiles ; l’automatisation n’en détecte qu’une partie.

• Titre et structure de titres significatifs.
• Textes alternatifs pour les images utiles.
• Libellés pour tous les champs et contrôles.
• Contraste suffisant et état jamais codé par la seule couleur.
• Navigation clavier avec focus visible.
• Cibles tactiles suffisantes.
• Liste ou contenu alternatif accessible.
• Annonce des nombres et erreurs.
• Aucun mouvement imposé.
• Test de la tâche complète.

9. Construire la visibilité hors du canevas cartographique

Exposez l’information dans des pages explorables, pas seulement marqueurs, pop-ups et canvas. Google traite JavaScript par exploration, rendu et indexation ; rendu et erreurs peuvent retarder ou empêcher la découverte. Publiez sujet, lieux, services, catégories et informations client en HTML sémantique, avec rendu serveur ou prérendu pour l’essentiel.

Chaque lieu important mérite une URL stable et indexable, avec titre, description, adresse, attributs, texte propre et liens. Le mobile doit garder le contenu significatif. Les données structurées LocalBusiness rendent type, adresse, horaires et services lisibles par machine ; elles doivent correspondre à la page et ne garantissent aucun résultat.

Un sitemap aide sans garantir l’indexation ; la navigation interne doit comporter des liens explorables. Pour les moteurs de réponse, énoncez les faits, rattachez-les à l’entité, maintenez-les et séparez vérification et promotion. Ne générez pas des centaines de pages pauvres ne différant que par le nom du lieu.

10. Ne demander la position que lorsque la tâche l’exige

La position améliore localisateurs, tourisme, immobilier et itinéraires, mais crée des obligations de confidentialité. La spécification W3C Geolocation définit l’interface et les permissions. Il s’agit d’un Candidate Recommendation Snapshot du 26 mars 2026, pas d’une Recommendation finale.

Ne demandez pas la position précise dès l’arrivée. Un contrôle lancé par l’utilisateur — « Utiliser ma position » — et une explication préalable donnent contexte et choix. En cas de refus, adresse, ville, code postal ou recherche cartographique doivent conduire au même résultat.

Minimisez collecte et conservation. Un calcul ponctuel n’exige pas de conserver les coordonnées ; l’analytique ne doit pas enregistrer de coordonnées brutes sans besoin documenté et protections. Régions approximatives ou bandes de distance suffisent souvent.

11. Protéger données, API, formulaires et administration

Le no-code ne supprime pas les risques : API, formulaires, bases, analyse, géocodage, routage, paiement et comptes restent connectés. Séparez données publiques et restreintes avant l’import. Un champ « masqué » contenant clients, notes internes ou informations confidentielles demeure livré au site ; masquer n’est pas sécuriser.

Limitez les jetons visibles par domaine, portée, quota et environnement ; aucun secret serveur ne doit apparaître dans le code ou un fichier public. Évaluez les intégrations avec l’OWASP API Security Top 10 : autorisation par objet, authentification, consommation illimitée, mauvaise configuration, inventaire et consommation non sûre d’API tierces.

Un accès par rôle évite qu’un rédacteur gère facturation, domaines, sécurité, intégrations et utilisateurs. Les formulaires demandent validation, limites anti-abus, endpoints protégés et règles de conservation. Transmettez aux tiers le strict nécessaire et vérifiez accès, transferts, suppression, incidents et fin de contrat avant connexion.

Le NIST Privacy Framework structure le risque. Tenez aussi l’inventaire des services et retirez les anciens : le no-code accumule extensions et automatisations abandonnées parce que chaque ajout paraît gratuit.

12. Vérifier licences, attribution et conditions

Fonds, données, satellite, icônes, polices, photos, lieux, géocodage et itinéraires peuvent relever de règles distinctes. Les données OpenStreetMap sont ouvertes, mais les serveurs de tuiles publics ont une Tile Usage Policy séparée : capacité limitée, aucun SLA et blocage possible. La production exige un fournisseur ou hébergement adapté et l’attribution requise.

Les fournisseurs commerciaux ajoutent quotas, prix par requête, restrictions d’affichage, jetons, cache, stockage et attribution. Consignez fournisseur, produit, propriétaire du compte, forfait, quota, renouvellement, texte de crédit et usages autorisés. Ne rognez pas les crédits pour l’esthétique et vérifiez séparément les droits sur photos, logos, descriptions, supports et jeux importés. Publier via une plateforme ne règle aucun droit tiers.

Un flux de publication pratique

Les douze décisions s’ordonnent en dix étapes : données avant configuration, configuration avant contenu, tests avant domaine.

Publiez en staging lorsque possible. Modifier directement la production risque données cassées, mises en page incohérentes et indexation accidentelle sans retour. Notez date, version des données, changements, responsable et point de restauration. La publication ouvre l’exploitation : mises à jour, revue, comptes, performance et assistance. Une carte devient fausse plus vite qu’une page statique.

Cadre d’assurance qualité avant lancement

Avant de connecter le domaine, effectuez six contrôles ciblés :

Construire l’expérience avec Kaleidr

Kaleidr relie données de localisation, cartes interactives, modèles de sites, création dans Studio, intégrations et outils développeur. Un projet peut combiner carte, lieux structurés, site centré sur la carte, découverte assistée par IA et analyse. Lieux, zones, équipements, itinéraires et contenus apparaissent sur une vraie carte ; l’interface conversationnelle rend les mêmes données accessibles en langage naturel. La manière dont les moteurs recommandent d’abord les entreprises est expliquée dans ce guide de découverte locale par IA.

Kaleidr ne prend pas les décisions métier. Tâche utilisateur, coordonnées, sincérité des attributs, accessibilité, confidentialité des permissions et conditions externes restent à la charge de l’organisation. Une bonne plateforme retire l’implémentation ; le jugement demeure.

Conclusion

Le no-code a changé qui peut publier une carte, pas ce qui la rend efficace. Un modèle livre rapidement mise en page, composants, adaptation et hébergement ; il ne peut définir la question, vérifier les coordonnées, maintenir les horaires, rendre le clavier possible ou lire les conditions du fournisseur. Ces décisions étaient le cœur du travail et le restent.

Le test pratique consiste à savoir si le modèle le plus simple satisfait la tâche sans contournement. Si oui, le no-code transforme des semaines d’implémentation en configuration et libère du temps pour données, contenu et tests. Sinon, low-code ou sur-mesure est la réponse honnête. La recherche conseille d’examiner l’arbitrage avant l’adoption.

Questions fréquentes

Qu’est-ce qu’un site cartographique sans code ?

Une carte interactive avec données structurées, contenu, recherche, filtres, détails et actions, assemblée par modèles et configuration. La plateforme génère le socle ; l’éditeur gère données, contenu, marque et comportement.

No-code signifie-t-il absence de travail technique ?

Non. Le travail passe à la configuration, aux données, au design, à la gouvernance et aux tests. Champs, comportement, appareils, permissions et maintenance restent nécessaires.

Quand le no-code est-il un mauvais choix ?

Lorsque l’expérience ne correspond pas aux schémas réutilisables : routage complexe, grandes données temps réel, authentification particulière, transactions fréquentes ou interface atypique.

Réduit-il les coûts et délais ?

Pas toujours. La recherche rapporte avantages et difficultés. Le gain dépend de l’adéquation entre exigences et capacités de la plateforme.

Quels formats de données sont acceptés ?

Beaucoup acceptent GeoJSON selon RFC 7946, en WGS 84 et ordre longitude-latitude. CSV et tableurs sont aussi courants.

Le site peut-il être bien classé ?

Seulement grâce à du contenu explorable. Utilisez du HTML sémantique et une URL stable par lieu ; conservez le contenu essentiel sur mobile puisque Google l’indexe.

Quels objectifs de performance viser ?

Au 75e centile : LCP en 2,5 s, INP jusqu’à 200 ms et CLS jusqu’à 0,1. Mesurez aussi filtre, sélection, déplacement et recherche.

Comment l’accessibilité s’applique-t-elle ?

WCAG 2.2 s’applique entièrement : clavier, noms accessibles, alternatives au glisser et à la couleur, liste ou tableau comme parcours non cartographique.

Un site commercial peut-il utiliser OpenStreetMap gratuitement ?

Les données sont ouvertes, mais les tuiles publiques ont une politique distincte, une capacité limitée et aucun SLA. Utilisez un service adapté et affichez l’attribution.

Faut-il demander la position du visiteur ?

Uniquement si la tâche l’exige, via une action expliquée. Le site doit fonctionner en cas de refus et ne rien conserver d’inutile.

Références

• 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}
}