Un punto en (0, 0), o en algún lugar del golfo de Guinea: cuatro formas de perder una coordenada

Respuesta corta: un punto en (0, 0) no es un lugar del que vengan tus datos. Es una coordenada que se perdió, que se intercambió o que se leyó de la columna equivocada — y el cúmulo que aparece no tiene por qué estar en (0, 0): el que se midió para este post queda a mil kilómetros de la costa de África occidental, en el golfo de Guinea. Cuatro fallas lo producen: dos que las herramientas cuentan en voz alta, dos silenciosas.

Probado el 23 de septiembre de 2026 contra static-page-tools@79fc1f6 — el csv-viewer y el coordinate-converter tal como están desplegados hoy. Cada texto citado es el de la herramienta; cada coordenada es el primer par de una descarga con Exportar GeoJSON, salvo la transcripción de GDAL en "Cómo arreglarlo", repetida sin cambios de la corrida de línea de comandos de la guía de CSV (GDAL 3.13.3 "Iowa City"). Los archivos de prueba, al final.

La celda vacía: una fila salteada y contada, y siempre lo fue

Encabezado id,lat,lon,nome, filas 1,-23.55,-46.63,São Paulo, 2,,,Brasília, 3,-3.12,-60.02,Manaus. El panel dice 2 puntos · 1 fila sin coordenadas válidas, no hay ningún aviso, y la fila en blanco no aparece en la exportación: dos entidades, ningún [0,0] en ninguna parte. Vaciá una segunda fila y dice 1 punto · 2 filas sin coordenadas válidas. Vaciá las tres y el contador se va con la capa que estaba contando, y queda el aviso que se cita más abajo.

El visor nunca dibujó esa fila en cero — ni en esta versión, ni en la anterior al arreglo de septiembre. El mismo archivo pasado por el parser tal como estaba antes del arreglo de septiembre da los mismos dos puntos y el mismo único salteo: el código viejo usaba parseFloat, y parseFloat de una cadena vacía ya no es un número. La comprobación explícita de cadena vacía que agregó el arreglo compró preservación, no reparación — cambió parseFloat por Number para que una celda 23°33'S dejara de dibujarse en Arabia Saudita, y Number de una cadena vacía es 0, así que sin esa línea el cambio habría introducido el punto en (0, 0). En el mismo banco de pruebas la fila 23°33'S sí se movió, de dibujarse en [46, 23] a ser un salteo contado, así que el no-cambio de la celda en blanco es real.

El conversor convierte el mismo defecto en una instrucción de tipeo: completá Latitud, dejá Longitud vacío, y la tarjeta dice Completa latitud y longitud para convertir. en ámbar y no muestra nada. Con los dos vacíos no dice nada en absoluto. Ninguna de las dos herramientas pone una celda vacía en (0, 0).

Intercambiadas: nada puede detectarlo

Mismo encabezado, valores invertidos: 1,-46.63,-23.55,São Paulo. Línea de conteo 3 puntos, sin contador, sin aviso, primer par [-23.55, -46.63] — a 3.290,4 km de São Paulo con rumbo 147°, en el Atlántico Sur; Manaus aterriza a 7.934,8 km de Manaus. Nada avisa que algo esté mal y nada puede hacerlo: −46,63 es una latitud perfectamente válida y −23,55 una longitud perfectamente válida. El conversor coincide, convirtiendo — -46.63 y -23.55 dejan vacía la línea de ayuda y devuelven -46.63000000 y -23.55000000.

Una fila puede caer, por accidente, cuando el intercambio mete en la columna de latitud una longitud más allá de ±90. Poné como tercera fila 3,139.69,35.69,Tokyo y el visor dice 2 puntos · 1 fila sin coordenadas válidas; las otras dos siguen a 3.290 km de donde corresponde. El conversor rechaza 139.69 con Latitud o longitud inválida.

La columna equivocada: lo que la regla de magnitud no ve

Cambiá solo el encabezado, a id,este,norte,nome. El selector se abre con cada archivo y preselecciona por nombre: primero los alias conocidos, después una coincidencia de subcadena con lat y lon, y después las dos primeras columnas. Ni este ni norte coinciden, así que Columna de Latitud queda puesta en id y Columna de Longitud en este. Aceptá eso y obtenés 3 puntos, sin contador, sin aviso, primer par [-46.63, 1] — con la latitud real sentada en la tabla de atributos bajo norte, como -23.55.

La regla de magnitud de más abajo no puede ver esta. Las latitudes son 1, 2 y 3, cada una una latitud brasileña plausible, y el mapa queda 2.729,8 km justo al norte de donde corresponde, con cada número pasando la inspección. La pista es la forma de la columna: una latitud que sube de a uno es un número de fila.

Poné metros UTM de verdad bajo el mismo encabezado — 1,333283.88,7394643.65,São Paulo — y el resultado se invierte. La preselección es idéntica, pero 333283.88 no es una longitud, así que todas las filas fallan la comprobación de límites, no se crea ninguna capa, y obtenés No se encontraron columnas de coordenadas válidas. Verifica que las columnas seleccionadas contengan valores numéricos de latitud y longitud. Cuál de los dos te toca depende de los valores, no de nada que la herramienta entienda. Si los números son metros necesitás el código EPSG de la zona, listado bajo "Cómo elegir una zona UTM en Brasil" en la hoja de referencia EPSG.

En el conversor no hay ninguna columna que elegir y la única comprobación es el límite: 90 y 180 convierten, 90.01 y 180 dan Latitud o longitud inválida. Un este de seis cifras queda fuera de ese límite, así que la regla lo rechaza — eso se deduce de la regla, no se tipeó en la tarjeta para este post — mientras que un contador de filas que vale 1 queda dentro y convierte.

La coma decimal que no sobrevivió al guardado

Columnas correctas, números correctos, archivo equivocado: 1,-23,55,-46,63,São Paulo bajo id,lat,lon,nome. En un archivo delimitado por comas eso son seis celdas, no cuatro, antes de que ningún parser de coordenadas lo vea — lat se queda con -23, lon con 55, nome con -46, y São Paulo se cae del final. Las dos celdas de coordenadas son números enteros, así que no se rechaza nada: 3 puntos, sin contador, sin aviso. São Paulo se dibuja en [55, -23], a 10.096,7 km de distancia; Manaus en [12, -3], a 1.374,8 km del origen — el golfo de Guinea del título. La pista está en la tabla de atributos, donde nome dice -46.

El entrecomillado es toda la diferencia: 1,"-23,55","-46,63",São Paulo vuelve como [-46.63, -23.55] con nome diciendo São Paulo. El rescate corre por celda, después de partir la fila, así que solo puede salvar una coma que nunca fue un delimitador.

El conversor tiene el mismo defecto y lo esconde mejor. Escribí -23,55 y -46,63 y no hay línea de error ni campo en rojo — y el resultado dice -23.00000000 y -46.00000000. Su validador cambia la coma por un punto antes de comprobar, así que el valor pasa; su parser no lo hace, así que se detiene en la coma. Eso son 61,2 km al norte del punto que escribiste cuando solo la latitud lleva coma, y 88,8 km con rumbo 047° cuando la llevan las dos. Con puntos da -23.55000000 y -46.63000000. Es un bug, está registrado, y hoy nada te avisa.

El diagnóstico de diez segundos

Brasil va aproximadamente de −74° a −29° de longitud y de +5° a −34° de latitud, y casi todo esto es una comprobación de magnitud contra esa caja. Una longitud fuera de −74 a −29 es la pista de un intercambio: las del archivo intercambiado son −23,55, −15,79 y −3,12, y las tres fallan, mientras que las del archivo correcto — −46,63, −47,88 y −60,02 — pasan las tres. Una longitud entre +12 y +79 es la pista de una coma decimal perdida: ese archivo exporta 55, 79 y 12. Una latitud más allá de ±90 es lo único que las dos herramientas atrapan solas.

Dos cosas que la regla no te va a decir. La columna equivocada la atraviesa sin problema: latitudes de 1, 2 y 3 están dentro de la banda y el mapa sigue estando a 2.729,8 km. Y (0, 0) significa ausente más que cero, salvo cuando no — una celda en blanco nunca llega al mapa, ni antes ni después de aquel arreglo, mientras que una celda que tiene un 0 literal sí llega y se dibuja en el origen. Así que un (0, 0) exacto vino de una celda que tenía un cero, y un cúmulo apenas cerca de él, como [12, -3] a 1.374,8 km, vino de un número que se acortó. El casi acierto es el peligroso, porque parece dato.

Cómo arreglarlo

Un intercambio y una columna equivocada se arreglan los dos en el selector, sin volver a exportar. Abrí de nuevo el archivo en el csv-viewer, poné Columna de Latitud y Columna de Longitud en las columnas que de verdad las tienen, y hacé clic en Abrir en el mapa. En el archivo intercambiado eso mueve el primer par de [-23.55, -46.63] a [-46.63, -23.55]; en el archivo de la columna equivocada, elegir norte como latitud hace lo mismo. Mirá la exportación, no el contador — la línea de conteo dice 3 puntos antes y después, así que solo el par te dice que funcionó.

En el conversor es el botón entre los dos campos, rotulado Intercambiar latitud y longitud: un clic convierte -46.63 y -23.55 en -23.55 y -46.63.

Para la coma el arreglo está en el archivo, y la parte que se midió acá es el entrecomillado: los mismos dígitos entrecomillados por celda se leen bien, y sin comillas no. Qué opción de la planilla produce cuál archivo no se probó para este post, y no se corrió ninguna planilla en absoluto, así que tomá "guardar con el punto como separador decimal" como la forma del arreglo y revisá los bytes que realmente te quedan.

Fuera del navegador el equivalente del selector son dos flags de GDAL: ogr2ogr -f GeoJSON out.geojson in.csv -oo X_POSSIBLE_NAMES=lon -oo Y_POSSIBLE_NAMES=lat. Con el archivo limpio de tres filas eso sale con 0 y escribe {"type":"Point","coordinates":[-46.63,-23.55]} para São Paulo — la corrida de control de la línea de comandos de la guía de CSV, no una lectura del navegador. Poné tus propios nombres de columna en los flags.

Las filas de título, los acentos Latin-1 y un .xlsx soltado sin querer fallan en el mismo archivo; la guía de CSV en un mapa cubre esos casos.

Archivos de prueba que podés usar

No hay nada alojado — pegá las filas en un editor de texto y guardá cada una como un .csv en UTF-8.

• La celda vacía: id,lat,lon,nome, 1,-23.55,-46.63,São Paulo, 2,,,Brasília, 3,-3.12,-60.02,Manaus.
• Intercambiadas: id,lat,lon,nome, 1,-46.63,-23.55,São Paulo, 2,-47.88,-15.79,Brasília, 3,-60.02,-3.12,Manaus.
• La columna equivocada: id,este,norte,nome, 1,-46.63,-23.55,São Paulo, 2,-47.88,-15.79,Brasília, 3,-60.02,-3.12,Manaus.
• La coma decimal: id,lat,lon,nome, 1,-23,55,-46,63,São Paulo, 2,-15,79,-47,88,Brasília, 3,-3,12,-60,02,Manaus.

Para equipos

Un intercambio o una columna equivocada es un problema de traspaso, no un problema de archivo: pasa donde una planilla sale de las manos de una persona y aterriza en el mapa de otra. Geodocs mantiene los datos de campo en un mapa compartido donde los campos de coordenadas se deciden una sola vez, cuando se arma el formulario.