Como lançar um site de mapas sem código

Um site de mapas sem código combina mapa interativo, dados de localização estruturados, conteúdo explicativo, busca e filtros, páginas de detalhes e ações do cliente. Ele é montado por modelos e configuração, não por front-end personalizado. A plataforma assume a implementação rotineira; o editor continua responsável pelas decisões que determinam o resultado: quais dados o mapa contém, qual pergunta a interface responde e qual ação o visitante conclui. Quando o projeto se encaixa no fluxo do Kaleidr, comece no Kaleidr Studio, gere o mapa por prompt, refine o design e publique ou incorpore. Use este artigo como a lista de produção que um modelo não pode substituir.

Escopo e evidências

No-code é uma abordagem em que o usuário monta uma aplicação com modelos, formulários, controles visuais e componentes prontos em vez de escrever a maior parte do código. Software, infraestrutura, modelagem de dados, testes e responsabilidade técnica continuam existindo. No-code usa configurações e componentes reutilizáveis; low-code acrescenta scripts, fórmulas, APIs ou componentes limitados; desenvolvimento personalizado dá controle direto da arquitetura e do código-fonte.

A pesquisa não sustenta que no-code sempre reduza custo total ou prazo. Uma revisão de 40 estudos publicados entre 2017 e 2023 sobre a adoção de low-code e no-code relata benefícios buscados e desafios encontrados. Outra pergunta o que a pesquisa diz sobre a viabilidade de low-code. Juntas, descrevem uma escolha com contrapartidas e uma questão organizacional, não um ganho automático.

Este artigo combina essa literatura com cartografia interativa e normas oficiais de dados geográficos, acessibilidade, indexação, desempenho, privacidade, segurança de APIs e licenças. Quando uma afirmação é inferência, o texto informa. O foco são decisões de produção, não marketing de plataforma.

Resumo executivo

No-code redistribui o trabalho. A plataforma assume front-end, integração de hospedagem, layout responsivo e comportamento dos componentes. A equipe mantém objetivo do usuário, exatidão dos dados, escolha de interações, testes, proteção das informações e manutenção.

O modelo se encaixa em padrões estáveis: guias de hotéis e destinos, mapas imobiliários, localizadores de lojas, locais de eventos, campi, turismo, eventos e diretórios comunitários. Roteamento complexo, grandes dados em tempo real, autenticação especial, transações frequentes ou interfaces incomuns apontam para low-code ou desenvolvimento próprio. Exceções constantes transformam no-code em uma pilha frágil de contornos.

Mapas acrescentam coordenadas, limites, camadas, zoom, agrupamento, atribuição, permissão de localização, atualização, interação móvel e alternativas não cartográficas. Um modelo bonito não corrige coordenadas erradas, controles inacessíveis, renderização lenta ou tarefa confusa.

O que um site de mapas sem código realmente é

Ele reúne tela do mapa, navegação, busca, filtros, marcadores, camadas geográficas, cartões, páginas, formulários, eventos analíticos e seções responsivas. O editor escolhe layout e estilo, envia dados, associa campos, ativa filtros, aplica a marca, conecta o domínio e publica. A plataforma transforma escolhas em comportamento; registra decisões, não as toma.

Código, bibliotecas, bancos de dados, CDN, APIs, hospedagem e controles de segurança continuam por trás da interface. A reutilização reduz o custo de padrões comuns e restringe os incomuns. O no-code compensa quando os requisitos cabem nas capacidades existentes.

Sem código não significa sem trabalho técnico

O esforço passa da sintaxe para configuração, preparação dos dados, design, governança e garantia de qualidade. O editor evita implementar estruturas, estado, biblioteca e hospedagem, mas ainda deve preparar dados compatíveis, associar campos, escolher o comportamento, testar dispositivos, administrar permissões e verificar a publicação.

A dívida técnica muda de forma: em software próprio, aparece no código complexo e nas dependências antigas; em no-code, em configurações sem documentação, nomes inconsistentes, duplicatas, integrações sem governança, fórmulas específicas e fluxos que só uma pessoa entende. Documente fontes, campos, papéis, integrações, domínio, publicação, eventos e recuperação como documentaria código.

Defina também responsáveis por negócio, dados, conteúdo e administração. Uma pessoa pode acumular papéis, mas nenhum deve ficar implícito.

Escolher o modelo de entrega adequado

A escolha depende da interação, do controle, da integração e da manutenção reais. Os cinco modelos não são uma escala de qualidade; resolvem problemas diferentes. Leia primeiro a limitação.

Uma incorporação adiciona contexto a uma página; um site de mapas organiza toda a jornada em torno da descoberta espacial. Mostrar o escritório de turismo pede um embed; pesquisar atrações, filtrar, comparar bairros, abrir detalhes e planejar rotas pede um site. Escolha o modelo menos complexo que cumpra a tarefa sem contornos relevantes.

1. Defina a decisão do usuário antes de configurar o mapa

O mapa deve apoiar uma decisão específica, não exibir todos os registros. Um hóspede escolhe onde comer a pé; um comprador compara imóveis por bairro e transporte; um cliente encontra a loja mais próxima com certo serviço; um visitante localiza estacionamento, entradas ou rotas acessíveis. São produtos diferentes.

Resuma público, decisão, geografia e resultado em uma frase: “O site ajuda hóspedes a encontrar lugares próximos de acordo com seus interesses e obter direções desde o hotel.” A frase exige origem, lugares, categorias, distância ou rota e ação de direções; exclui análise GIS, contas e edição. Antes de configurar, responda:

• Quem usará o site?
• Qual decisão o mapa apoiará?
• Qual área cobrirá?
• Quais locais, limites ou rotas aparecerão?
• Quais atributos determinam adequação?
• Qual ação segue a descoberta?
• Quais informações mudam com frequência?
• Quais exigem autenticação?
• Qual métrica indica conclusão da tarefa?

2. Construa uma base confiável de dados de localização

A qualidade do site não supera a dos dados. Coordenadas erradas, duplicatas, categorias incoerentes, horários antigos e links quebrados anulam uma interface polida. Cada feição precisa de ID estável para distinguir registros, preservar links, atualizar locais, conectar análises e evitar duplicação.

Um ponto normalmente contém nome, categoria, latitude, longitude, endereço, descrição, status, imagem, URL e data de atualização. Um polígono descreve propriedade, área de serviço, distrito, campus ou evento; uma linha, rota, trilha, corredor ou trecho. Separe campos públicos de apresentação de IDs de origem, estado interno, datas e notas de qualidade.

RFC 7946 define GeoJSON e coordenadas WGS 84 em graus decimais. Um erro frequente: GeoJSON armazena longitude-latitude, não latitude-longitude. Inverter coloca a feição em outro país ou fora do 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 e planilhas também são comuns. Antes da primeira importação, padronize nomes, valores, datas, precisão e regras de vazio.

• Atribua um ID único a cada feição.
• Valide intervalos de latitude e longitude.
• Padronize categorias e estados.
• Remova duplicatas antes de importar.
• Confira todas as URLs públicas.
• Registre fonte e data de informações operacionais.
• Separe campos públicos, internos e sensíveis.
• Teste limites inválidos ou autointersectados.
• Faça backup antes de grandes atualizações.
• Programe revisão de registros temporais.

3. Projete a arquitetura da informação

O site precisa de organização espacial e web convencional. O mapa oferece exploração; a estrutura oferece navegação, explicação, indexação, acessibilidade e links diretos. Em geral inclui página inicial, explorador, categorias, páginas de locais, sobre, ajuda, privacidade e contato ou conversão.

Não deixe informação importante apenas no mapa. Pop-ups, rótulos de canvas e sobreposições dinâmicas têm pouca visibilidade de busca e criam barreiras. Nomes, endereços, serviços, descrições e ações também devem existir em texto e páginas. URL estável permite compartilhar, indexar, medir e dar suporte.

Uma lista sincronizada oferece alternativa escaneável, aceita teclado, reduz dependência do ponteiro e funciona se o mapa falhar. Use a linguagem do visitante — “Onde comer” — e não códigos internos.

4. Configure a interação em torno da tarefa

A taxonomia empírica de Roth reduz interação a identificar, comparar, classificar, associar e delimitar. Seu estudo posterior conclui que complexidade deve corresponder à capacidade e motivação. Uma interface desagradável pode impedir alguém capaz.

Ative apenas controles úteis ao objetivo. A extensão inicial deve mostrar o contexto certo. Categoria e seleção devem usar forma, ícone, texto, contorno e tamanho, não só cor. Pontos densos exigem agrupamento, agregação, exibição por escala ou filtro no servidor.

Filtros devem refletir critérios reais: distância a pé, cozinha, horário e acessibilidade para hotéis; preço, tipo, disponibilidade e transporte para imóveis. Inclua redefinição. Marcador e item da lista devem selecionar um ao outro.

Ative por padrão busca, zoom, redefinir vista, categorias, contagem, detalhes, legenda, lista acessível, direções quando pertinentes e localização atual apenas quando justificada. Adicione desenho, medição, consultas espaciais, vários mapas base, edição, coordenadas, tempo ou 3D só se a tarefa exigir.

5. Comunique procedência e incerteza

Um mapa parece oficial mesmo com dados incompletos ou antigos. Uma revisão de visualização de incerteza encontrou muitas técnicas novas e pouca avaliação, recomendando testes centrados na tarefa. Nenhuma técnica deve ser tratada como universal.

Identifique a organização responsável e mostre a data quando a atualização mudar a interpretação. Distinga imóveis disponíveis, indisponíveis e desconhecidos; rotas temporárias e fechamentos; recursos verificados e não verificados.

Evite falsa precisão. Uma área aproximada não deve parecer um limite legal medido; uma coordenada estimada não deve parecer uma entrada confirmada. Uma limitação curta e específica ajuda, mas não substitui qualidade.

6. Personalize a marca sem reduzir a legibilidade

Logo, tipografia, cores da página, botões, cabeçalho, rodapé, imagens e CTA pertencem ao site; mapa base, símbolos, cores de camada, estados, rótulos e painéis pertencem à cartografia. Uma cor corporativa pode funcionar no logo e falhar no mapa. Não imponha toda a paleta à representação geográfica.

Reserve a maior ênfase à ação principal e use texto específico: “Ver imóvel”, “Verificar disponibilidade”, “Reservar”, “Ligar para este local”, “Criar rota”. Projete também carregamento, vazio e erro; é nesses momentos que a confiança é decidida.

7. Projete para celulares e redes variáveis

Mapas carregam código, estilos, geodados, imagens, fontes, marcadores e serviços. Móvel não é encolher desktop: toque, espaço, orientação, desempenho e rede mudam a experiência. O telefone frequentemente combina a página mais pesada com a conexão mais fraca.

O Google usa a versão móvel para indexar e classificar e recomenda conteúdo e metadados equivalentes. O conteúdo pode ir para painéis, abas ou cartões, mas não desaparecer. Carregue título, explicação e controles antes ou junto do mapa.

Core Web Vitals considera bons LCP em 2,5 s, INP de 200 ms ou menos e CLS de 0,1 ou menos, no percentil 75 e separados por móvel e desktop. INP substituiu FID em 2024.

Uma home rápida não prova o desempenho do mapa. Meça filtros, seleção, movimento, busca, painéis e rotas em dispositivos reais ou emulados, redes lentas, grandes dados e visitas iniciais e repetidas.

• Carregue apenas camadas iniciais.
• Paginar ou recupere resultados grandes progressivamente.
• Simplifique polígonos com zoom baixo.
• Agrupe pontos densos.
• Comprima imagens e forneça tamanhos responsivos.
• Armazene recursos estáveis em cache.
• Reserve espaço para mapa e mídia.
• Limite scripts de terceiros.
• Meça usuários reais depois do lançamento.
• Defina orçamento de desempenho para mudanças.

8. Trate acessibilidade como requisito de lançamento

Mapas concentram riscos por dependerem de visão, ponteiro, cor, arrastar, zoom e relações espaciais. WCAG 2.2 é o quadro atual do W3C. Um modelo oferece bases, mas não garante conformidade após cores, imagens, conteúdo, integrações e comportamento; conformidade pertence ao produto publicado.

O teclado deve alcançar busca, filtros, resultados, detalhes e ações, com foco visível. Botões de ícone precisam de nomes. Arrastar não pode ser o único método; WCAG 2.2 cobre movimento de arrasto e tamanho do alvo. A cor não pode ser o único sinal.

Lista, tabela ou visualização estruturada deve permitir encontrar e usar registros sem mapa. Anuncie mudanças e erros a tecnologias assistivas. Teste o fluxo inteiro com teclado, leitor, zoom, alto contraste, movimento reduzido e recursos móveis; ferramentas automáticas cobrem só parte.

• Título e hierarquia significativos.
• Texto alternativo para imagens úteis.
• Rótulos em campos e controles.
• Contraste suficiente e estado não só por cor.
• Teclado com foco visível.
• Alvos de toque adequados.
• Lista ou conteúdo alternativo acessível.
• Anúncio de contagens e erros.
• Sem movimento forçado.
• Teste da tarefa completa.

9. Construa visibilidade fora da tela do mapa

Exponha informações em páginas rastreáveis, não só marcadores, pop-ups e canvas. O Google processa JavaScript por rastreamento, renderização e indexação; renderização e erros podem atrasar ou impedir descoberta. Publique tema, lugares, serviços, categorias e informações em HTML semântico e prefira renderização no servidor ou pré-renderização para o essencial.

Cada local importante precisa de URL estável e indexável, com título, descrição, endereço, atributos, texto próprio e links. O móvel deve preservar conteúdo. Dados estruturados LocalBusiness tornam tipo, endereço, horário e departamentos legíveis por máquina; devem corresponder à página e não garantem resultados.

Sitemap ajuda, não garante indexação; a navegação deve manter links rastreáveis. Para mecanismos de resposta, declare fatos, entidade e atualização e separe evidência de promoção. Não gere centenas de páginas rasas que mudam apenas o nome do lugar.

10. Solicite a localização apenas quando a tarefa exigir

Localização melhora localizadores, turismo, imóveis e rotas, mas cria obrigações de privacidade. A especificação W3C Geolocation define interface e permissões. É um Candidate Recommendation Snapshot de 26 de março de 2026, não uma Recommendation final.

Não solicite localização precisa na chegada só porque é possível. Use controle iniciado pelo usuário — “Usar minha localização” — e explique antes. Se a pessoa recusar, endereço, cidade, CEP ou busca no mapa devem chegar ao mesmo resultado.

Minimize coleta e retenção. Um cálculo pontual não exige guardar coordenadas; análises não devem registrar coordenadas brutas sem necessidade e proteção documentadas. Regiões aproximadas ou faixas de distância costumam bastar.

11. Proteja dados, APIs, formulários e administração

No-code não elimina risco: APIs, formulários, bancos, análises, geocodificação, rotas, pagamentos e contas continuam conectados. Separe dados públicos e restritos antes de importar. Um campo “oculto” com clientes, notas internas ou informações confidenciais continua entregue ao site; ocultar não é uma fronteira de segurança.

Restrinja tokens visíveis por domínio, escopo, cota e ambiente; segredos do servidor nunca devem aparecer em código ou arquivos públicos. Revise integrações com o OWASP API Security Top 10: autorização por objeto, autenticação, consumo ilimitado, configuração, inventário e uso inseguro de APIs de terceiros.

Use acesso por função para que editores não administrem automaticamente cobrança, domínio, segurança, integrações e usuários. Formulários exigem validação, limites contra abuso, endpoints protegidos e retenção. Envie a terceiros só o necessário e revise acesso, transferência, exclusão, incidentes e encerramento antes de conectar.

O NIST Privacy Framework estrutura o risco. Mantenha inventário dos serviços e remova os antigos: projetos no-code acumulam plugins e automações abandonados porque cada inclusão parece gratuita.

12. Verifique licenças, atribuição e termos

Mapas base, dados, satélite, ícones, fontes, fotos, lugares, geocodificação e rotas podem ter regras distintas. Dados do OpenStreetMap são abertos, mas seus servidores de tiles seguem uma Tile Usage Policy separada: capacidade limitada, sem SLA e com possibilidade de bloqueio. Produção exige provedor ou hospedagem adequada e atribuição.

Provedores comerciais acrescentam cotas, preço por chamada, restrições, tokens, cache, armazenamento e atribuição. Registre provedor, produto, dono da conta, plano, cota, renovação, texto de crédito e usos permitidos. Não corte créditos por estética e verifique separadamente direitos de fotos, logos, descrições, materiais e datasets. Publicar numa plataforma não resolve direitos de terceiros.

Um fluxo prático de publicação

As doze decisões formam dez etapas: dados antes da configuração, configuração antes do conteúdo e testes antes do domínio.

Publique em staging quando possível. Editar produção arrisca dados quebrados, layouts incoerentes e indexação acidental sem volta. Registre data, versão dos dados, mudanças, responsável e ponto de reversão. Publicar inicia operação: atualizações, revisão, contas, desempenho e suporte. Um mapa se torna incorreto mais rápido que uma página estática.

Garantia de qualidade antes do lançamento

Antes de conectar o domínio, faça seis revisões focadas:

Construindo a experiência com Kaleidr

Kaleidr conecta dados de localização, mapas interativos, modelos de site, criação no Studio, embeds e integrações. Um projeto pode combinar mapa, lugares estruturados, site centrado no mapa, descoberta assistida por IA e análises. Locais, áreas, comodidades, rotas e conteúdo aparecem sobre um mapa real; a interface conversacional permite usar linguagem natural. Como mecanismos recomendam empresas é tratado neste guia de descoberta local por IA.

Kaleidr não toma as decisões de negócio. Tarefa, coordenadas, veracidade dos atributos, acessibilidade, privacidade da permissão e termos externos continuam responsabilidade da organização. Uma boa plataforma remove implementação; o julgamento permanece.

Conclusão

No-code mudou quem pode publicar um site de mapas, não o que o faz funcionar. Um modelo entrega layout, componentes, responsividade e hospedagem rapidamente; não define a pergunta, verifica coordenadas, mantém horários, garante teclado nem lê os termos do provedor. Essas decisões eram o trabalho essencial e continuam sendo.

O teste prático é se o modelo mais simples satisfaz a tarefa sem contornos. Se sim, no-code transforma semanas de implementação em configuração e libera esforço para dados, conteúdo e testes. Se não, low-code ou desenvolvimento próprio é a resposta honesta. A pesquisa recomenda analisar essa troca antes da adoção.

Perguntas frequentes

O que é um site de mapas sem código?

Mapa interativo com dados estruturados, conteúdo, busca, filtros, detalhes e ações, montado com modelos e configuração. A plataforma gera a base; o editor gerencia dados, conteúdo, marca e comportamento.

No-code significa ausência de trabalho técnico?

Não. O trabalho passa para configuração, dados, design, governança e testes. Campos, comportamento, dispositivos, permissões e manutenção continuam necessários.

Quando no-code é uma escolha errada?

Quando a experiência não se encaixa em padrões reutilizáveis: roteamento complexo, dados em tempo real em grande escala, autenticação especial, transações frequentes ou interface incomum.

Reduz custo e prazo?

Nem sempre. A pesquisa relata benefícios e desafios. O ganho depende de os requisitos caberem nas capacidades da plataforma.

Quais formatos de dados são aceitos?

Muitas plataformas aceitam GeoJSON conforme RFC 7946, WGS 84 e ordem longitude-latitude. CSV e planilhas também são comuns.

O site pode se posicionar nos buscadores?

Apenas com conteúdo rastreável. Use HTML semântico e URL estável por local; preserve conteúdo essencial no móvel, pois o Google o indexa.

Quais metas de desempenho usar?

No percentil 75: LCP em 2,5 s, INP até 200 ms e CLS até 0,1. Meça também filtro, seleção, movimento e busca.

Como a acessibilidade se aplica?

WCAG 2.2 se aplica integralmente: teclado, nomes acessíveis, alternativas a arrastar e à cor e lista ou tabela como percurso sem mapa.

Um site comercial pode usar OpenStreetMap gratuitamente?

Os dados são abertos, mas tiles públicos têm política separada, capacidade limitada e sem SLA. Use serviço adequado e exiba atribuição.

Deve solicitar a localização do visitante?

Somente quando a tarefa exigir, por uma ação explicada. O site deve funcionar se houver recusa e não deve guardar dados desnecessários.

Referências

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