Volver al Blog

¿Qué Es GeoJSON? La Guía Definitiva

GeoJSON es un formato de texto en JSON plano para entidades geográficas, estandarizado como RFC 7946 en 2016, y sus coordenadas son siempre longitud primero, después latitud, sobre WGS 84. Alguien te mandó un .geojson y se abre como una pared de números. O exportaste uno desde QGIS y se dibuja en el Atlántico Norte. O un mapa web lo rechaza como "GeoJSON no válido" cuando cualquier linter de JSON dice que está bien. Cada comando y número de abajo se ejecutó el 15 de septiembre de 2026 contra un dataset real, los límites estatales de Brasil de 2022 del IBGE, y cada afirmación sobre nuestro visor se midió en la herramienta en vivo.

¿Qué es GeoJSON?

GeoJSON es un formato de texto para entidades geográficas, escrito como JSON plano y estandarizado como RFC 7946 en agosto de 2016. Un archivo suele ser un FeatureCollection que contiene un array de objetos Feature, y cada Feature tiene una geometry (la forma) y un objeto properties (los atributos, cualquier JSON que quieras). No hay esquema, no hay archivo lateral y no hay sección binaria, por eso cualquier librería de mapas web lo habla de forma nativa.

El archivo útil más pequeño es una sola entidad, y este es un fixture real de nuestro laboratorio: {"type":"Feature","properties":{"name":"Brasília"},"geometry":{"type":"Point","coordinates":[-47.8825,-15.7942]}}. Leé las coordenadas con cuidado, porque esta es la frase que la gente se salta y después pierde una tarde entera: una posición GeoJSON se escribe primero la longitud, después la latitud. Brasília es [-47.8825, -15.7942], no el -15.79, -47.88 que escribirías en un buscador. La especificación dice [longitude, latitude]; un par invertido se parsea sin quejarse y se dibuja en el hemisferio equivocado.

Los siete tipos de geometría, y el octavo que los contiene

Toda geometry tiene un type y un array de coordinates; solo cambia la profundidad de anidamiento.

  • Point — una posición, [lon, lat].
  • MultiPoint — un array de posiciones.
  • LineString — dos o más posiciones, en orden de dibujo.
  • MultiLineString — un array de arrays de coordenadas de LineString.
  • Polygon — un array de anillos cerrados; el primero es el límite exterior, el resto son agujeros.
  • MultiPolygon — un array de arrays de coordenadas de Polygon. Los 27 estados de Brasil son 12 Polygon y 15 MultiPolygon, porque un estado costero con islas son varios anillos que no son agujeros entre sí.
  • GeometryCollection — el octavo tipo: un array geometries con cualquiera de los anteriores, sin coordinates propio. Aparece donde no lo pediste, como vimos más abajo.

Qué cambió la RFC 7946, y por qué tu archivo puede ser anterior a la especificación

Antes de 2016 el formato era la "especificación GeoJSON" de 2008, un documento comunitario, y muchos exportadores todavía escriben esa variante por defecto, GDAL incluido. La RFC 7946 endureció cinco cosas, y cada una explica un archivo que "debería funcionar" y no funciona.

  • Solo WGS 84, y el miembro CRS desapareció. Un archivo RFC 7946 siempre es longitud y latitud en grados decimales sobre WGS 84. La especificación de 2008 permitía un objeto crs de nivel superior que nombraba cualquier sistema de coordenadas; la RFC lo eliminó. Un archivo con un miembro crs es un archivo de la especificación de 2008, y si nombra algo distinto de WGS 84 tenés el problema de la siguiente sección.
  • La regla de la mano derecha para los anillos. Un anillo exterior va en sentido antihorario, los agujeros en sentido horario. Los Shapefiles guardan los anillos exteriores en sentido horario, así que todo polígono convertido sin la flag de la RFC queda "al revés"; a la mayoría de los lectores no les importa.
  • La caja delimitadora ganó un orden fijo. El bbox ya existía en 2008; la RFC fija su significado en [west, south, east, north], todavía opcional en cualquier objeto.
  • Tres dimensiones, no más. Una posición es [lon, lat] o [lon, lat, elevation]; un cuarto número no debería estar ahí; la RFC dice SHOULD NOT, no MUST NOT.
  • Corte en el antimeridiano. Una forma que cruza los 180° de longitud debería partirse en dos. Es una recomendación para quien escribe el archivo; los lectores varían.

Qué le hizo la flag realmente a un archivo real

Convertimos el mismo Shapefile dos veces, en el modo 2008 por defecto y con -lco RFC7946=YES, y comparamos las salidas.

  • El miembro CRS desapareció. El archivo en modo 2008 abre con "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } } en su cuarta línea; el archivo RFC pasa directo de "name": "BR_UF_2022" a "features". Ninguno de los dos tiene bbox, que es opcional.
  • Las coordenadas se redondearon a 7 decimales. El primer vértice de Acre pasó de [-68.792817347,-10.999569268] a [-68.7928173,-10.9995693]. El driver usa por defecto 15 decimales en modo 2008 y 7 en modo RFC; 7 decimales es aproximadamente un centímetro.
  • Los anillos se reorientaron. El anillo exterior de Acre, con 41.498 vértices en ambos archivos, empieza en el mismo vértice y camina en sentido contrario: horario en el archivo 2008, antihorario en el archivo RFC.
  • El archivo se achicó en un cuarto. 39.274.442 bytes pasaron a 29.108.343, casi todo por los números más cortos.
  • Tres polígonos cambiaron de tipo, en silencio. El archivo 2008 tiene 12 Polygon y 15 MultiPolygon; el archivo RFC tiene 11 Polygon, 13 MultiPolygon y tres entidades GeometryCollection, para Alagoas, Paraná y Goiás. Una segunda corrida con -lco RFC7946=YES -lco COORDINATE_PRECISION=15 devolvió 12 y 15, así que la causa es el redondeo: a 7 decimales anillos diminutos en Alagoas y Goiás colapsan a menos de cuatro puntos distintos y un anillo de Paraná se cruza a sí mismo; el modo RFC de GDAL los repara con MakeValid(), y las partes colapsadas salen como miembros LineString y MultiLineString empaquetados junto con el polígono en una colección, con 36 vértices perdidos. GDAL no dice nada al respecto salvo que lo corras con --debug on, que imprime una línea Running MakeValid() por estado reparado. El modo 2008 con -lco COORDINATE_PRECISION=7 toma otro camino, SetPrecision(), y conserva 12 Polygon y 15 MultiPolygon. La precisión es una decisión de geometría, y correr un validador después de convertir sale barato.

El lugar equivocado clásico: metros en un formato que significa grados

El reclamo dice "exporté mi capa a GeoJSON y quedó en el océano" o "no está en ningún lado". La causa casi siempre son coordenadas que no son [longitude, latitude] en grados: ejes invertidos, o metros proyectados.

Nuestro dataset viene en coordenadas geográficas SIRGAS 2000, así que para reproducir el bug lo exportamos a SIRGAS 2000 / UTM zona 23S: ogr2ogr -f GeoJSON utm.geojson BR_UF_2022.shp -t_srs EPSG:31983. GDAL no se niega. Escribe un archivo de 55.908.110 bytes, 1,4 veces el archivo en grados del modo 2008 (1,9 veces el archivo RFC, que también redondea a 7 decimales), y el primer vértice de Acre se convierte en [-2171693.959168141, 8673426.088929612] donde el archivo correcto tiene [-68.7928173, -10.9995693]. El easting tiene siete dígitos y es negativo porque Acre queda cuatro zonas UTM al oeste de la zona 23. GDAL también hace lo que la especificación de 2008 permitía: escribe "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::31983" } } arriba de todo, honesto con los números pero no GeoJSON en el sentido de la RFC 7946. GDAL respeta ese miembro al volver a leerlo, ogrinfo reporta el archivo como SIRGAS 2000 / UTM zone 23S, y QGIS lee los archivos vectoriales a través de GDAL, y por eso un archivo así "funciona en QGIS y se rompe en la web".

Lo que pasa después depende del lector, así que medimos el nuestro. Nuestro visor de GeoJSON gratuito lee archivos con OpenLayers, que respeta un miembro crs solo cuando nombra un sistema de coordenadas que OpenLayers ya conoce: los alias de WGS 84, incluido urn:ogc:def:crs:OGC:1.3:CRS84, y Web Mercator. EPSG:31983 no está en esa lista. Seis fixtures, cada uno soltado en la herramienta en vivo:

  • Un CRS que nombra EPSG:31983, en cualquiera de las dos formas de escritura. El visor no muestra ningún error. El panel de capas dice 27 entidades y 27 Polígono, todo parece cargado, y el GeoJSON exportado pone el primer vértice de Acre en [-19.5086591263066, 61.20664023081724]: el Atlántico Norte entre Islandia y Noruega, a unos 9.000 km de Acre. Los metros UTM se tomaron como metros de Web Mercator y se convirtieron de vuelta a grados. La propia forma de GDAL, urn:ogc:def:crs:EPSG::31983, dio el mismo par.
  • Los mismos metros sin ningún CRS. Sigue sin haber error, sigue diciendo 27 entidades. Sin crs el lector asume grados, así que -2171693.96 es una longitud de dos millones de grados. El primer vértice exportado es [-2171693.959168141, -53.911070387188786]: la latitud dio la vuelta por la fórmula de Mercator hasta −53,9°, la longitud volvió sin cambios, y la forma no está en ningún lugar al que puedas navegar. Dos fallas silenciosas de un mismo archivo: "Brasil frente a Islandia" y "nada en ningún mapa".
  • Un archivo estilo 2008 que declara CRS84. Se dibuja correctamente. El primer vértice de Acre se exporta como [-68.7928173712301, -10.999569659337354], el mismo par que dio el archivo RFC; los dígitos extra son el viaje de ida y vuelta por Web Mercator.
  • Un CRS cuyo tipo OpenLayers no reconoce. Tanto la forma "type":"link" de la especificación de 2008 como un "type":"bogus" inventado detienen el parseo con el aviso Error al procesar el archivo. Verifica que sea un GeoJSON válido. Un crs malformado falla a los gritos; un crs bien formado que nombra el sistema equivocado falla en silencio. Esa asimetría es el problema de interoperabilidad que la RFC 7946 §4 cita al eliminar el miembro.

El arreglo está del lado de quien escribe el archivo y es una sola flag: agregá -t_srs EPSG:4326 a la exportación para que el archivo tenga grados. No edites la línea crs a mano; los números de adentro siguen siendo metros, y ninguna declaración los convierte en [longitude, latitude]. Reproyectá con ogr2ogr -t_srs EPSG:4326; en el modo 2008 por defecto GDAL todavía escribe una declaración CRS84, que es inofensiva (el visor la respeta, como mostró el tercer fixture de arriba), y -lco RFC7946=YES la elimina por completo.

Convertir a GeoJSON con ogr2ogr

El comando que produce un archivo con el que cualquier lector está de acuerdo es ogr2ogr -f GeoJSON out.geojson in.shp -t_srs EPSG:4326 -lco RFC7946=YES. La página del driver de GeoJSON de GDAL lista todas las opciones de creación de capa; estas cuatro cambian el archivo de formas que podés ver.

  • RFC7946=YES — todo lo de la sección sobre qué le hizo la flag a un archivo real: sin crs, anillos reorientados, 7 decimales, y posiblemente un cambio de tipo de geometría donde el redondeo invalida un anillo. El valor por defecto es NO.
  • COORDINATE_PRECISION=6 — un decimal menos que el default de la RFC. Una millonésima de grado son unos 0,11 m en el ecuador (111.320 m por grado, dividido por un millón), todavía por debajo de la precisión de la mayoría de los datos vectoriales. Llevó nuestro archivo de 29.108.343 bytes a 26.839.688, un ahorro del 7,8 %, y el primer vértice de Acre pasó a [-68.792817,-10.999569]. Cinco decimales es aproximadamente un metro.
  • WRITE_BBOX=YES — agrega un bbox a la colección y a cada entidad: nuestro archivo ganó 28 de ellos, [ -73.9904500, -33.7511780, -28.8476399, 5.2718411 ] arriba de todo y uno por estado, por 1.626 bytes extra.
  • ID_FIELD=CD_UF — promueve un atributo al "id" de nivel de entidad y lo saca de properties. Nuestros estados salieron como "id":"12", "id":"13", "id":"15", strings porque el campo del Shapefile era texto. Útil cuando un mapa web necesita una clave estable.

Tres cosas más que el laboratorio resolvió.

  • La elevación sobrevive, a pesar del aviso. Convertir un punto [-47.8825,-15.7942,1172] con -dim XYZ imprime Warning 1: Attempt to write Z geometries to layer pz that does not support them. Z component will be discarded, y después escribe [-47.8825,-15.7942,1172.0], que se vuelve a leer como un 3D Point. No le creas al aviso.
  • GeoJSONSeq es la forma en streaming. ogr2ogr -f GeoJSONSeq out.geojsonl in.shp -t_srs EPSG:4326 escribe un Feature por línea sin colección que lo envuelva: 27 líneas, coordenadas de 7 decimales, sin crs, 29.108.905 bytes. Una herramienta orientada a líneas puede transmitirlo; un lector que espera un solo FeatureCollection no puede, porque el archivo completo no es un único valor JSON.
  • TopoJSON no es GeoJSON. Codifica arcos compartidos una sola vez y suele ser mucho más chico, pero su objeto de nivel superior es un Topology. GDAL lo lee y no lo puede escribir: ogr2ogr -f TopoJSON responde ERROR 1: TopoJSON driver does not support data source creation. Nuestro visor lo rechaza de dos formas según el nombre: un .topojson nunca llega al parser y recibe Tipo de archivo no compatible. Usa GeoJSON (.geojson o .json).; los mismos bytes renombrados .json sí llegan al parser y reciben Error al procesar el archivo. Verifica que sea un GeoJSON válido.

Tamaño, medido

GeoJSON es grande sin comprimir y es el más chico de los tres formatos vectoriales comunes una vez comprimido, porque el texto se comprime mucho mejor que las formas binarias. Estos números son de nuestro laboratorio de comparación de formatos del 15 de septiembre de 2026 sobre el mismo dataset: el BR_UF_2022.zip del IBGE, 13.717.460 bytes descargado, SHA-256 282ec7f0f0beeeead45e6609f4ffffce161bda04cb8ee0afcad2316d1c841bcb, 27 estados, 1.138.650 vértices.

  • Shapefile — 18.227.115 bytes por los cinco archivos juntos, el .shp y sus cuatro archivos laterales; 13.794.222 bytes re-comprimidos al máximo.
  • GeoPackage — 18.386.944 bytes, un poco más grande que el Shapefile porque las páginas de SQLite y el índice espacial cuestan más que el .shx que reemplazan; 13.828.105 bytes comprimido.
  • GeoJSON al default de la RFC de 7 decimales — 29.108.343 bytes, el más grande en disco por lejos; 8.457.365 bytes comprimido, el más chico de los tres por unos 5,1 MiB.
  • GeoJSON a 6 decimales — 26.839.688 bytes; 7.132.808 bytes comprimido.

Así que en disco y en la memoria del navegador, GeoJSON cuesta 1,6 veces lo que cuesta un Shapefile; comprimido en zip, cuesta un 61 %, y el argumento del tamaño en su contra casi desaparece. La comparación completa de ocho criterios, con los tiempos de carga en el navegador incluidos, está en nuestro post Shapefile vs GeoPackage vs GeoJSON.

Cómo abrir un archivo GeoJSON

No necesitás un GIS de escritorio para mirarlo. Soltá el archivo en nuestro visor de GeoJSON y dibuja las entidades sobre un mapa base, las lista en un panel de capas con un conteo por tipo de geometría, y abre una tabla de atributos que se puede ordenar. El paso a paso está en cómo abrir un archivo GeoJSON en línea; los datos de abajo se midieron en la herramienta en vivo con los archivos de esta guía.

  • Qué acepta. El selector de archivos filtra por extensión, .geojson, .json, .kml y .kmz, pero un archivo arrastrado se salta ese filtro y se juzga por su sufijo dentro del parser: un GeoJSON renombrado .txt recibe Tipo de archivo no compatible. Usa GeoJSON (.geojson o .json). No hay límite de tamaño ni límite de entidades; el archivo UTM de 56 megabytes de más arriba cargó en menos de dos segundos, y el techo es la memoria de tu navegador, para la cual no vamos a inventar un número.
  • Un archivo por vez, diez por sesión. Si soltás dos archivos a la vez, carga el primero e ignora el segundo. Después del décimo archivo el botón Añadir del panel de capas simplemente desaparece; no hay ningún mensaje de "demasiados archivos".
  • Qué significan los conteos. El archivo RFC 7946 muestra 27 entidades y 24 Polígono, porque los tres estados GeometryCollection no pertenecen a ningún grupo de geometría; el archivo en modo 2008 muestra 27 entidades y 27 Polígono. Una colección se etiqueta como Colección en la columna Tipo de la tabla de atributos y en el panel de la entidad, no en la fila de capas.
  • Una geometría desnuda funciona. Un archivo cuyo nivel superior es un solo Feature, o incluso un Point desnudo, carga como una entidad; el punto desnudo muestra 0 campos.
  • Los anillos no se revisan. Un anillo exterior en sentido horario se dibuja normal y se exporta todavía en sentido horario; el visor no valida ni repara el enrollado.
  • El estilo dentro de properties se aplica y después se oculta. Las claves de simplestyle, fill, fill-opacity, stroke, stroke-width, marker-color, marker-size, marker-symbol, le dan estilo al mapa y se ocultan de la tabla de atributos: una entidad con siete claves de estilo más name y plain lista 2 campos.
  • Las líneas y polígonos se suavizan 20 cm. Toda geometría que no es un punto se simplifica con una tolerancia de 0,2 metros antes de dibujar y antes de exportar. Una línea de prueba cuyo vértice del medio estaba a 5 cm de la línea recta lo perdió; una a 1 m de distancia conservó los 3 vértices. Para los límites estatales eso son 15.249 vértices de 1.138.614, invisible a cualquier zoom; donde 5 cm importan, guardá el original y tratá la exportación como una foto.

Como consejo general para QGIS, no algo que esta guía haya medido: arrastrá el archivo al lienzo del mapa. Si las propiedades de la capa muestran algo distinto de EPSG:4326, volvé a exportarlo con -t_srs EPSG:4326 antes de publicar.

Archivos de prueba que podés usar

Cada URL de acá se pidió el 15 de septiembre de 2026 con un user agent de navegador, registrando el status, Accept-Ranges y el header de CORS. Una lista así se pudre; leela como una foto de un solo día.

  • Natural Earth 1:110m países, el archivo para empezar. tiene 838.726 bytes, responde 206 con accept-ranges: bytes y access-control-allow-origin: *, y es lo bastante chico para descargar y soltar. Licencia: el LICENSE.md del repositorio arranca con "Everything here is public domain."
  • El contorno de Brasil desde la propia API del IBGE. devuelve GeoJSON directamente: 65.655 bytes, una entidad MultiPolygon, sin miembro crs, leída por GDAL como WGS 84. Responde 200 con access-control-allow-origin: * pero sin accept-ranges, así que está viva y disponible para descargar y soltar, no para un range request. La respuesta no trae texto de licencia; son datos públicos del IBGE, así que citá la fuente.
  • Los 27 estados que usamos. BR_UF_2022.zip de geoftp.ibge.gov.br, nombrado en la sección de tamaño, es un Shapefile; convertilo con el comando de más arriba y tenés nuestro archivo exacto de 29.108.343 bytes.
  • Uno que está muerto, para que dejes de buscarlo. La copia del portal de datos de OKFN de los límites mundiales en data.okfn.org/data/datasets/geo-boundaries-world-110m/data/countries.geojson todavía está enlazada desde tutoriales viejos y su hostname ya no resuelve. Cuando una URL de muestra falla en el DNS, los datos casi siempre se mudaron a GitHub; buscá el nombre del archivo.

Dónde encaja Geodocs

Construimos Geodocs, una plataforma para equipos de campo y GIS, y escribimos esta guía porque GeoJSON es el formato que nuestros usuarios más nos entregan, y el miembro crs es lo que más se rompe.

¿Trabajás con los otros formatos? Nuestra guía completa del formato Shapefile cubre los archivos laterales y el problema del .prj que hereda la sección del lugar equivocado de esta guía; la guía de GeoPackage es la alternativa de un solo archivo; y la guía de KML y KMZ cubre el otro formato de texto que abre el mismo visor. Para mirar un archivo ahora mismo, el visor de GeoJSON enlazado arriba es gratis y corre en tu navegador.

¿Encontraste un error, o una trampa que se nos pasó? Contanos. Volvemos a probar esta página en vez de copiarla y pegarla.

Última verificación: 15 de septiembre de 2026.

Artículos Relacionados

Navegação