Por qué convertir GeoJSON a GeoParquet
GeoJSON es fácil de leer y fácil de escribir a mano, y por eso mismo se convirtió en el formato predeterminado para compartir datos de mapas en la web. Pero esa misma sencillez tiene un costo cuando un conjunto de datos crece más allá de unos pocos miles de entidades. GeoJSON guarda cada coordenada como texto plano dentro de una estructura JSON, y un lector tiene que analizar el archivo completo, llave por llave, antes de poder examinar siquiera una propiedad. No hay forma de leer solo las columnas que necesitas, ni de conocer la extensión de un archivo sin abrirlo y recorrerlo entero.
GeoParquet resuelve esto tomando prestado el almacenamiento por columnas que los ingenieros de datos ya usan para grandes conjuntos de datos tabulares. Cada propiedad se convierte en su propia columna, la geometría se convierte en una columna binaria de valores WKB, y el archivo lleva un pequeño bloque de metadatos que indica de antemano los tipos de geometría y el cuadro delimitador general. Una herramienta como DuckDB o GeoPandas puede entonces leer solo las columnas que una consulta realmente necesita, saltarse archivos cuyo cuadro delimitador no se superpone con un área de interés, y aprovechar la compresión integrada de Parquet para reducir valores repetidos como nombres de lugares o códigos de estado.
Esta herramienta existe para eliminar la fricción de ese primer paso. En lugar de instalar GDAL, un entorno de Python o una herramienta de línea de comandos, puedes soltar un archivo GeoJSON en tu navegador y obtener un archivo GeoParquet funcional en cuestión de segundos. La conversión se ejecuta del lado del cliente usando WebAssembly, así que la herramienta funciona igual sin importar si tu archivo tiene diez entidades o cien mil, y tus datos nunca se envían a ningún sitio.
GeoParquet: historia, estructura y datos clave
GeoParquet está construido sobre Apache Parquet, un formato de archivo orientado a columnas que Twitter y Cloudera publicaron como proyecto de código abierto en 2013 para el procesamiento de datos a gran escala en Hadoop. Parquet en sí no sabe qué es una coordenada; simplemente almacena columnas tipadas de forma eficiente, con compresión por columna y metadatos que permiten a un lector saltarse bloques de datos completos que no necesita.
La especificación GeoParquet añade reglas geoespaciales sobre ese formato de propósito general. Fue desarrollada por una comunidad abierta que trabaja bajo el Cloud-Native Geospatial Forum, con la primera versión 1.0.0 publicada en agosto de 2023. La versión 1.1.0, publicada en 2024, añadió soporte opcional para una columna de cuadro delimitador por fila y un campo "covering", ambos pensados para que un lector pueda filtrar filas sin decodificar cada geometría.
Algunos datos que vale la pena conocer: GeoParquet almacena la geometría como WKB de forma predeterminada, así que cualquier lenguaje con una librería WKB puede leer la columna de geometría incluso sin herramientas específicas para GeoParquet. La especificación asume el orden longitud/latitud en OGC:CRS84 a menos que un archivo indique otro sistema de referencia de coordenadas mediante PROJJSON. Y GeoParquet ya se ha adoptado mucho más allá de simples experimentos: Overture Maps, el proyecto cartográfico conjunto respaldado por Amazon, Meta, Microsoft y TomTom, publica todo su conjunto de datos global (edificios, lugares, carreteras y límites administrativos) como GeoParquet, y Source Cooperative aloja decenas de conjuntos de datos GeoParquet públicos que cualquiera puede consultar directamente desde almacenamiento en la nube.
En resumen, GeoParquet no es un modelo de geometría nuevo. Es un acuerdo sobre cómo colocar una codificación de geometría ya conocida y bien entendida dentro de un formato de archivo columnar rápido en el que ya confía el resto del mundo de la ingeniería de datos.
Guía paso a paso
Elige un archivo .geojson de tu computadora, pega texto GeoJSON directamente en el cuadro, o haz clic en "Probar ejemplo" para cargar un pequeño archivo ya preparado con ciudades alemanas.
Una vez cargado tu GeoJSON, haz clic en "Convertir a GeoParquet". La conversión se ejecuta por completo en tu navegador y termina en una fracción de segundo para archivos típicos.
Aparece un resumen: cuántas entidades se convirtieron, qué tipos de geometría se encontraron, el cuadro delimitador, las columnas de propiedades y el tamaño del archivo resultante.
Las entidades de origen se dibujan en el mapa para que puedas confirmar que se convirtieron los datos correctos antes de descargar nada.
Haz clic en "Descargar converted.parquet" para guardar el archivo GeoParquet terminado en tu computadora.
Seis casos de uso reales
Dónde se usa realmente GeoParquet, más allá del formato de archivo en sí.
- Publicar grandes conjuntos de datos abiertos. Proyectos como Overture Maps publican conjuntos de datos globales de edificios y lugares como GeoParquet porque un solo archivo puede contener millones de entidades y seguir siendo rápido de consultar por región.
- Cargar datos geoespaciales en un almacén de datos en la nube. BigQuery, Snowflake y DuckDB leen Parquet de forma nativa. Convertir primero GeoJSON a GeoParquet hace que la columna de geometría se cargue junto con el resto de la tabla sin necesidad de un paso de importación aparte.
- Alimentar flujos de aprendizaje automático. Los flujos de entrenamiento que leen muchos archivos pequeños se benefician de la disposición por columnas de Parquet: un modelo que solo necesita coordenadas y una columna de etiquetas puede saltarse el resto de las propiedades en lugar de analizar un objeto GeoJSON completo por cada fila.
- Archivar conjuntos de datos GIS municipales y gubernamentales. Los portales de datos abiertos que actualmente publican límites de ciudades, zonificación o datos de parcelas como GeoJSON pueden ofrecer también una copia en GeoParquet, dando a los analistas un archivo más pequeño y más rápido de consultar para los mismos datos.
- Catalogar huellas de imágenes satelitales y teledetección. Las escenas y huellas de mosaicos de imágenes satelitales son naturalmente tabulares: una geometría más metadatos como la fecha de captura y la cobertura de nubes por fila, que es exactamente la forma para la que está pensado un formato columnar como Parquet.
- Preprocesar datos para un flujo de cartografía web. Los ingenieros de datos que construyen mosaicos vectoriales o backends de mapas suelen preparar primero el GeoJSON en bruto como GeoParquet, ya que herramientas posteriores como DuckDB spatial o Apache Sedona pueden filtrar y reestructurar millones de entidades mucho más rápido que volver a analizar texto JSON.
Preguntas y respuestas técnicas
Diez preguntas comunes sobre el funcionamiento de este conversor, respondidas directamente.
1. ¿Qué es GeoParquet, en términos sencillos?
GeoParquet es una forma de almacenar datos de mapas (puntos, líneas, polígonos y la información asociada a ellos) dentro de un archivo Apache Parquet normal. Parquet es un formato de archivo basado en columnas construido para análisis rápido. GeoParquet simplemente añade un pequeño conjunto de reglas para que las columnas de geometría puedan vivir dentro de un archivo Parquet y seguir leyéndose correctamente con software GIS.
2. ¿Cómo se almacena realmente una geometría dentro del archivo?
Cada geometría se codifica como WKB, abreviatura de Well-Known Binary. WKB es una receta byte a byte: un byte indica si los números están en orden little-endian o big-endian, cuatro bytes indican el tipo de geometría (punto, línea, polígono, etc.), y luego siguen las coordenadas como números en bruto de 8 bytes. Este valor WKB se guarda en una columna binaria del archivo Parquet, una fila por entidad.
3. ¿Puede un mismo archivo GeoParquet contener más de un tipo de geometría?
Sí. Una sola columna de geometría puede mezclar puntos, líneas y polígonos, porque WKB lleva su propio código de tipo dentro de cada valor. Este conversor registra cada tipo de geometría que encuentra en una lista "geometry_types" dentro de los metadatos del archivo, así que un lector sabe de antemano qué esperar sin tener que recorrer cada fila.
4. ¿Qué es la clave de metadatos "geo" y por qué importa?
Todo archivo GeoParquet lleva un pequeño objeto JSON bajo una clave a nivel de esquema llamada "geo". Indica cuál es la columna de geometría principal, describe la codificación (WKB), enumera los tipos de geometría presentes y da el cuadro delimitador del archivo. Sin esta clave, un archivo Parquet es solo una tabla de bytes. Con ella, cualquier herramienta compatible con GeoParquet sabe exactamente cómo convertir esos bytes de nuevo en geometrías reales.
5. ¿Cómo se compara GeoParquet con GeoJSON en tamaño de archivo y velocidad de lectura?
GeoJSON almacena las coordenadas como texto, así que un número como 13.404954 ocupa nueve caracteres. GeoParquet almacena ese mismo número como un double binario de 8 bytes, y luego Parquet comprime los patrones repetidos en toda la columna. En conjuntos de datos reales, esto suele producir archivos de 5 a 10 veces más pequeños que GeoJSON, y como Parquet está basado en columnas, una consulta que solo necesita una columna de propiedades puede saltarse por completo la lectura de la geometría.
6. ¿Qué sistema de referencia de coordenadas usa GeoParquet de forma predeterminada?
A menos que un archivo indique lo contrario, un lector de GeoParquet asume que las coordenadas son longitud y latitud en OGC:CRS84, el mismo orden de coordenadas y el mismo datum que usa el GeoJSON estándar. Este conversor sigue ese valor predeterminado, ya que toma GeoJSON como entrada.
7. ¿El archivo guarda un cuadro delimitador para todo el conjunto de datos?
Sí. Este conversor calcula un cuadro delimitador acumulativo, el X y el Y mínimos y máximos, mientras procesa cada entidad, y lo escribe en los metadatos "geo" como el bbox de la columna. Un lector puede revisar ese único bbox antes de decidir si abre el archivo, lo cual es útil al filtrar muchos archivos por área.
8. ¿Qué software puede abrir el archivo .parquet que genera esta herramienta?
Cualquier herramienta construida sobre la especificación GeoParquet puede leerlo: DuckDB con su extensión espacial, GeoPandas, Apache Sedona, QGIS (versiones recientes) y la mayoría de los almacenes de datos en la nube que admiten Parquet con un lector consciente de la geometría por encima. Como por debajo es Apache Parquet puro, incluso un lector de Parquet sin capacidades espaciales puede abrir el archivo y ver la geometría como una columna binaria.
9. ¿La conversión pierde precisión en las coordenadas?
No. Las coordenadas de GeoJSON son números JSON, que JavaScript ya representa internamente como floats de doble precisión IEEE-754. WKB almacena cada coordenada como ese mismo double IEEE-754 exacto, así que la conversión es una recodificación binaria directa, no una operación de redondeo. El proceso de ida y vuelta se verificó byte a byte durante el desarrollo.
10. ¿Se sube mi archivo GeoJSON a un servidor?
No. El análisis, la codificación WKB y la escritura de Parquet se ejecutan todos dentro de tu navegador mediante WebAssembly. Tu archivo nunca sale de tu dispositivo, y ninguna parte de la conversión pasa por un servidor.
Las matemáticas detrás de la conversión
La conversión no tiene ninguna ambigüedad ni estimación. Cada paso es una operación fija y reversible sobre bytes y números, y eso es lo que hace posible un proceso de ida y vuelta idéntico byte a byte. Esto es lo que ocurre realmente con tus datos.
1. Las coordenadas ya son doubles IEEE-754
Una coordenada GeoJSON como 13.404954 es interpretada por el analizador JSON de JavaScript como un float de doble precisión IEEE-754 de 64 bits: 1 bit de signo, 11 bits de exponente y 52 bits de mantisa, lo que da aproximadamente entre 15 y 17 dígitos decimales significativos de precisión. WKB almacena cada coordenada como exactamente ese mismo double de 8 bytes, escrito en orden de bytes little-endian. Aquí no ocurre ningún redondeo ni cambio de formato: la conversión copia los mismos 64 bits que ya estaban en memoria hacia el búfer de salida.
2. Disposición de bytes y tamaño de WKB
Todo valor WKB empieza con una bandera de endianness de 1 byte y un código de tipo de geometría de 4 bytes sin signo, así que el encabezado fijo siempre es de 5 bytes. Después de eso, el tamaño depende del tipo de geometría. Para un anillo de n pares de coordenadas (usado por LineString y por cada anillo de un Polygon), 4 bytes registran la cantidad de puntos y luego cada par cuesta 16 bytes (8 para X, 8 para Y):
ring_bytes(n) = 4 + 16n Point = 5 + 16 = 21 bytes LineString(n) = 5 + ring_bytes(n) Polygon(rings) = 5 + 4 + Σ ring_bytes(ring) for each ring MultiPoint(n) = 5 + 4 + 21n (each point repeats the 5-byte header) MultiLineString = 5 + 4 + Σ (5 + ring_bytes(line)) for each line MultiPolygon = 5 + 4 + Σ (5 + 4 + Σ ring_bytes(ring)) for each polygon, each ring
Esto es preciso, no aproximado: el conversor calcula el tamaño exacto en bytes de una geometría antes de reservar su búfer, escribe el encabezado y cada coordenada con un DataView, y nunca redimensiona el búfer a mitad de la escritura. Una simple línea de dos puntos ocupa entonces exactamente 5 + 4 + 32 = 41 bytes, siempre, en cualquier plataforma.
3. El cuadro delimitador es un único recorrido lineal
El cuadro delimitador [minX, minY, maxX, maxY] se calcula visitando cada par de coordenadas exactamente una vez y manteniendo un mínimo y un máximo acumulados, una reducción O(n) donde n es el número total de pares de coordenadas en todas las entidades. No hay ordenamiento ni segundo recorrido: cada nueva coordenada solo necesita compararse con los cuatro valores acumulados, así que el costo de calcular el bbox crece de forma lineal con el tamaño del conjunto de datos, nunca más rápido ni más lento.
4. Por qué el archivo termina siendo más pequeño
Un par de coordenadas GeoJSON como [13.404954, 52.520008] ocupa unos 20 bytes como texto, incluyendo corchetes y la coma. Ese mismo par como dos doubles WKB ocupa exactamente 16 bytes, un ahorro modesto por sí solo. La ganancia mayor viene de la codificación a nivel de columna de Parquet: una columna de texto, como el nombre de un país repetido en miles de filas, se comprime extremadamente bien con codificación por diccionario, ya que Parquet solo necesita almacenar cada cadena distinta una vez más una referencia entera corta por fila. Las columnas numéricas se benefician de forma similar de las codificaciones run-length y bit-packing cuando los valores se repiten o caen dentro de un rango estrecho. Nada de esto está disponible en un formato de texto orientado a filas como GeoJSON, donde cada valor se vuelve a escribir como texto en cada fila.
En conjunto, el proceso de conversión es determinista en cada etapa: se analiza un double IEEE-754 conocido, se escribe en una disposición de bytes conocida, se lleva un mínimo y máximo acumulado, y el resultado se entrega a un compresor columnar de propósito general. Ese determinismo es exactamente lo que hace posible que el proceso de ida y vuelta no pierda datos, y es la razón por la que el mismo archivo GeoJSON convertido dos veces en dos máquinas distintas produce una salida GeoParquet idéntica byte a byte.
La conversión se ejecuta por completo en tu navegador usando Apache Arrow y una compilación WebAssembly de parquet-wasm. Ningún archivo se sube jamás a un servidor. Teselas del mapa © colaboradores de OpenStreetMap, dibujadas con Protomaps (alojado por KONAKTIVE), con CARTO como respaldo.
