GeoJSON y el shapefile son los dos formatos vectoriales más utilizados para intercambiar datos espaciales. Ambos almacenan puntos, líneas, polígonos y sus atributos, pero se diseñaron para entornos distintos: el shapefile para los SIG de escritorio de los años noventa y GeoJSON para la web. Este artículo compara su estructura, sus sistemas de coordenadas, sus reglas para los atributos, su rendimiento y su uso práctico.

GeoJSON frente a Shapefile: ¿cuál es la diferencia?

El shapefile es un formato binario compuesto por varios archivos que siempre deben viajar juntos, y puede almacenar datos en cualquier sistema de coordenadas con una gama completa de tipos de atributo definidos de antemano. GeoJSON es un único archivo de texto con sintaxis JSON, legible en cualquier editor, siempre en coordenadas geográficas y con atributos definidos para cada entidad en lugar de mediante un esquema de tabla fijo.

GeoJSON frente a Shapefile

¿Qué es un shapefile?

Un shapefile es un conjunto de archivos que, juntos, describen una clase de entidad. La geometría se almacena en el archivo .shp, un índice de desplazamientos de registros en .shx y los atributos en la tabla .dbf, con una fila por entidad en el mismo orden. El archivo opcional .prj contiene la definición del sistema de coordenadas en WKT, y .cpg registra la codificación de caracteres de la tabla.

Como las posiciones de los registros están indexadas, el software puede ir directamente a una entidad concreta sin leer todo el archivo. Esto hace que los shapefiles sean eficientes para el trabajo de escritorio, pero también significa que el formato solo es válido cuando están presentes todos los archivos obligatorios y comparten el mismo nombre base.

¿Qué es GeoJSON?

GeoJSON describe los datos espaciales con objetos JSON corrientes. Una FeatureCollection contiene entidades, cada una con una geometría y un objeto properties que guarda los atributos. El formato admite Point, LineString, Polygon, sus variantes Multi y GeometryCollection, y una entidad también puede tener una geometría nula.

Como GeoJSON es JSON simple, funciona directamente con las tecnologías web. Un navegador puede analizarlo sin ninguna biblioteca, una API puede devolverlo como respuesta y puede guardarse en bases de datos documentales o en un sistema de control de versiones, donde los cambios se ven línea a línea.

Sistemas de coordenadas

Esta es la diferencia que causa más problemas en la práctica. La RFC 7946 define un único sistema de referencia de coordenadas para GeoJSON: WGS 84 con longitud y latitud en grados decimales, en ese orden. La especificación anterior de 2008 permitía un miembro crs, y algunos programas todavía lo escriben, pero los lectores que cumplen el estándar lo ignoran e interpretan los números como grados.

Un shapefile lleva su sistema de coordenadas en el archivo .prj y puede almacenar datos en cualquier proyección, por lo que los shapefiles proyectados deben reproyectarse a WGS 84 antes de convertirlos a GeoJSON. Si falta el archivo .prj, el software no puede conocer la proyección y suele asumir una por defecto, lo que sitúa los datos en una ubicación incorrecta.

Atributos y codificación

La tabla dBASE en la que se basa el shapefile impone varios límites: nombres de campo de hasta 10 caracteres, un máximo de 255 campos, valores de texto de hasta 254 caracteres y campos de fecha que guardan la fecha pero no la hora. No admite valores nulos, de modo que los números vacíos se convierten en cero y el texto vacío en una cadena en blanco, lo que cambia el significado de los datos durante el análisis.

La codificación es otra fuente de problemas. El estándar dBASE se creó en torno a páginas de códigos de un solo byte, por lo que los valores de atributo no latinos aparecen como caracteres ilegibles cuando el archivo .cpg falta o es incorrecto. GeoJSON evita este problema por completo al exigir UTF-8, y no impone restricciones a los nombres de campo ni a la longitud de los valores, de modo que los atributos se conservan sin truncarse en la conversión.

Tamaño de archivo y rendimiento

Un componente de shapefile no puede superar los 2 GB, lo que equivale aproximadamente a 70 millones de puntos, y los shapefiles también ocupan bastante más espacio en disco que una geodatabase con los mismos datos. La especificación de GeoJSON no fija ningún límite de tamaño, pero el texto es extenso: las coordenadas se guardan como cadenas decimales y cada entidad repite todos los nombres de las propiedades, así que el mismo conjunto de datos suele ser varias veces más grande que un shapefile.

La limitación más importante es cómo se lee el archivo. GeoJSON no tiene índice, por lo que una aplicación normalmente carga todo el archivo en memoria antes de dibujar nada. Un archivo de pocos megabytes funciona bien en un navegador, uno de decenas de megabytes es lento y uno de cientos de megabytes resulta poco práctico. Para conjuntos de datos grandes, las teselas vectoriales, FlatGeobuf, GeoParquet o una base de datos espacial son mejores opciones que un único archivo GeoJSON.

Mapas web y API

Las bibliotecas de mapas web como Leaflet, OpenLayers, MapLibre y ArcGIS Maps SDK leen GeoJSON de forma nativa, y OGC API - Features lo devuelve como formato de respuesta predeterminado. Los atributos llegan como objetos JavaScript, por lo que pueden usarse directamente en ventanas emergentes, filtros y reglas de estilo sin conversión.

Los shapefiles no pueden mostrarse en un navegador sin un procesamiento adicional. Una aplicación web los convierte en el servidor o descomprime los archivos binarios con una biblioteca JavaScript; por eso los servicios que aceptan la subida de shapefiles los convierten de inmediato en capas alojadas o en otro formato interno.

Conversión entre formatos

La conversión en ambos sentidos es compatible con GDAL/OGR, QGIS, ArcGIS Pro y la mayoría de las herramientas en línea, pero no es sin pérdidas. Pasar de shapefile a GeoJSON requiere reproyectar a WGS 84 y a menudo revela nombres de campo truncados en una etapa anterior. Pasar de GeoJSON a shapefile separa los tipos de geometría mixtos en archivos distintos, trunca los nombres de campo largos, descarta las propiedades anidadas y convierte los valores nulos en ceros o cadenas vacías.

Errores frecuentes

El error más frecuente es enviar un shapefile incompleto. Sin .shx o .dbf los datos no pueden abrirse, y sin .prj hay que adivinar el sistema de coordenadas. Cuando se comparte un shapefile, todos los archivos deben empaquetarse en un único archivo comprimido.

El segundo es suponer que GeoJSON puede contener coordenadas proyectadas. Las coordenadas en metros escritas en un archivo GeoJSON se leen como grados, por lo que la geometría queda muy fuera del rango válido o se concentra cerca del origen del mapa.

El tercero es usar GeoJSON como formato de trabajo para conjuntos de datos grandes o que se editan con frecuencia. Cada edición reescribe todo el archivo y no hay forma de consultar un subconjunto sin leerlo entero, por lo que una base de datos o un GeoPackage es mejor opción cuando los datos crecen o varias personas trabajan con ellos.

Preguntas frecuentes

¿GeoJSON está sustituyendo al shapefile?

En el desarrollo web y la publicación de datos abiertos, en gran medida sí. En los SIG de escritorio se siguen produciendo muchos shapefiles porque numerosas organizaciones y flujos de trabajo de software dependen de ellos, aunque cada vez se recomienda más GeoPackage como sustituto moderno.

¿Puede GeoJSON almacenar datos en un sistema de coordenadas proyectado?

No según la RFC 7946. Algunas herramientas todavía escriben un miembro crs o aceptan coordenadas proyectadas por acuerdo entre las partes, pero esos archivos no son interoperables y el software que cumple el estándar los situará en un lugar incorrecto.

¿Por qué se acortaron los nombres de mis campos al exportar?

Porque los atributos del shapefile se almacenan en una tabla dBASE, que solo permite 10 caracteres por nombre de campo. Los nombres más largos se truncan y los duplicados se renumeran, por lo que conviene documentar aparte los nombres originales o exportar los datos a otro formato.

¿Qué tamaño de archivo GeoJSON es aceptable para un mapa web?

Como referencia aproximada, los archivos de hasta unos pocos megabytes se cargan sin problema. Por encima de eso, conviene simplificar la geometría, reducir los atributos o servir los datos como teselas vectoriales o mediante una API que devuelva solo las entidades de la vista actual.

¿Qué formato debo usar para compartir datos con un colega?

Si el destinatario trabaja en un navegador o con una API, GeoJSON en WGS 84. Si trabaja en un SIG de escritorio y los datos tienen un único tipo de geometría y atributos sencillos, un shapefile comprimido en zip sigue aceptándose en todas partes. Para cualquier caso más complejo, GeoPackage evita las limitaciones de ambos.

Conclusiones clave

GeoJSON y el shapefile resuelven la misma tarea en épocas distintas de los SIG. El shapefile almacena los datos de forma compacta y con índice, conserva su propio sistema de coordenadas y está muy arraigado en los flujos de trabajo de escritorio, a costa de usar varios archivos y una tabla de atributos restrictiva. GeoJSON es un único archivo legible que funciona de forma nativa en la web, a costa de su tamaño, de un sistema de coordenadas fijo y de la ausencia de índice.

En la práctica, la elección depende del destino de los datos. Para mapas web, API y portales de datos abiertos, GeoJSON es el formato natural. Para el intercambio entre SIG de escritorio, el shapefile sigue siendo una opción segura por defecto, pero cuando importan los atributos, el volumen o la estructura de los datos, GeoPackage es la mejor opción moderna.