¿Qué son las Consultas Geoespaciales?

Una consulta geoespacial es una búsqueda en la base de datos que filtra y ordena registros por ubicación — cerca de un punto, dentro de un radio o de un área. Es la que impulsa el pedido de feature que llega en el segundo mes de casi todo producto: encontrar X cerca — cafés, conductores, tiendas, otros usuarios. Y es el caso más claro de una clase de consulta que la indexación B-tree común no puede atender: la cercanía es bidimensional, y una estructura ordenada en una sola dimensión no la ve.

Puntos clave

La consulta de cercanía, escrita y sentida

// JavaScript / Node.js — Back4app JS SDK
// "Find cafes within 2 km, nearest first" — the canonical geo query
const here = new Parse.GeoPoint({ latitude: 40.7484, longitude: -73.9857 });

const query = new Parse.Query('Cafe');
query.withinKilometers('location', here, 2); // radius filter, nearest-first
query.equalTo('openNow', true);              // geo + ordinary filters compose
query.limit(20);
const cafes = await query.find();

cafes.forEach((c) => {
  const km = here.kilometersTo(c.get('location'));
  console.log(`${c.get('name')} — ${km.toFixed(2)} km away`);
});

// Flutter / Dart — Back4app Flutter SDK
// "Find cafes within 2 km, nearest first" — the canonical geo query
final here = ParseGeoPoint(latitude: 40.7484, longitude: -73.9857);

final query = QueryBuilder<ParseObject>(ParseObject('Cafe'))
  ..whereWithinKilometers('location', here, 2) // radius filter, nearest-first
  ..whereEqualTo('openNow', true)              // geo + ordinary filters compose
  ..setLimit(20);
final response = await query.query();

for (final result in response.results ?? []) {
  final cafe = result as ParseObject;
  final loc = cafe.get<ParseGeoPoint>('location');
  print('${cafe.get<String>('name')} at '
      '${loc?.latitude}, ${loc?.longitude}');
}

// iOS / Swift — Back4app Swift SDK
// "Find cafes within 2 km, nearest first" — the canonical geo query
let here = try ParseGeoPoint(latitude: 40.7484, longitude: -73.9857)

let query = Cafe.query(
  withinKilometers(key: "location", geoPoint: here, distance: 2),
  "openNow" == true                 // geo + ordinary filters compose
).limit(20)

query.find { result in
  if case .success(let cafes) = result {
    for cafe in cafes {
      print("\(cafe.name ?? "?") — \(String(describing: cafe.location))")
    }
  }
}

// Android / Kotlin — Back4app Android SDK
// "Find cafes within 2 km, nearest first" — the canonical geo query
val here = ParseGeoPoint(40.7484, -73.9857)

val query = ParseQuery.getQuery<ParseObject>("Cafe")
query.whereWithinKilometers("location", here, 2.0) // radius, nearest-first
query.whereEqualTo("openNow", true)                // geo + filters compose
query.limit = 20

query.findInBackground { cafes, e ->
    if (e == null) cafes.forEach { cafe ->
        val loc = cafe.getParseGeoPoint("location")
        val km = loc?.distanceInKilometersTo(here)
        println("${cafe.getString("name")} — ${"%.2f".format(km)} km away")
    }
}

La misma física en SQL, vía PostGIS — y el índice que la hace viable:

-- Un índice espacial sobre la columna geography:
CREATE INDEX cafe_location_gix ON cafe USING GIST (location);

-- "Cafés a menos de 2 km, el más cercano primero":
SELECT name, ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS meters
FROM cafe
WHERE ST_DWithin(location, ST_MakePoint(-73.9857, 40.7484)::geography, 2000)
ORDER BY location <-> ST_MakePoint(-73.9857, 40.7484)::geography
LIMIT 20;
--  con el índice: toca solo las celdas que cubren el círculo de 2 km
--  sin él:        calcula una distancia para cada fila de la tabla

Cómo el índice ve el globo

Un índice estilo 2dsphere vuelve la cercanía indexable al mapear la superficie curva en celdas jerárquicas cuyo orden preserva la adyacencia — puntos cercanos en el globo caen en entradas cercanas del índice. Una consulta por radio se lee entonces como cualquier lookup en índice: identifica las pocas celdas que cubren el círculo, recorre sus candidatos, verifica las distancias exactas sobre esa lista corta. La geometría esférica — en lugar de la matemática de plano — mantiene los resultados correctos a escalas reales, al cruzar el antimeridiano y hacia los polos.

La regla de composición se sigue de la mecánica común de consultas: las restricciones geo se combinan libremente con filtros de igualdad, rango y pointer (openNow == true en las pestañas de arriba), y los filtros no-geo selectivos de las consultas calientes pueden merecer índices propios.

La paginación merece nota aparte, porque los resultados ordenados por distancia rompen el hábito del offset. Saltarse la primera página de una consulta near obliga al motor a reclasificar todo lo saltado, y un punto que se movió entre solicitudes puede barajar el orden bajo los pies del usuario. Los patrones más sólidos: ampliar el radio progresivamente para el “cargar más”, o paginar por una clave estable dentro de un radio fijo. El orden por cercanía es un ranking sobre datos vivos — trata los límites de página como orientativos, no como filas de un libro contable.

Near vs. within vs. consultas en plano

¿Qué consulta geo deberías usar?

La distinción near/within es lógica de producto, no pedantería: near es un ranking (acótalo con un limit y un radio máximo, o las ciudades densas devuelven miles de filas), within es un predicado (acompáñalo con la geometría del viewport o de la cerca). La fila del plano es la nota al pie honesta — para coordenadas que no están sobre una esfera, los índices esféricos son la herramienta equivocada.

Casos de uso comunes

• “Encontrar X cerca”. Cafés, gimnasios, cajeros, estaciones de carga — la lista de proximidad canónica, con radio acotado y el más cercano primero.
• Matching y despacho. Pasajeros con conductores, pedidos con repartidores — consultas near sobre GeoPoints actualizados con frecuencia.
• Viewports de mapa. Consultas dentro de la caja que alimentan los pines mientras el usuario arrastra el mapa — baratas, sin orden, del tamaño del viewport.
• Geofencing. Chequeos dentro del polígono para zonas de entrega, áreas de servicio y lógica disparada por ubicación.
• Features sociales locales. Gente cerca y eventos de este fin de semana, compuestos con filtros de privacidad y relaciones por pointer.

¿Deberías usar consultas geo o precomputar regiones? Matriz de decisión

La salida de emergencia importa: cuando toda consulta se reduce a “¿está en la zona A?”, una columna de texto indexada común le gana a la maquinaria espacial — más barata, más simple y cubierta por B-trees comunes. La indexación espacial se gana su lugar exactamente cuando la geometría es dinámica: centros arbitrarios, puntos en movimiento, distancias reales.

Limitaciones y trade-offs

• Los índices geo son especialistas. Sirven solo predicados espaciales; tus otros filtros siguen necesitando índices propios, y mantener un índice cuesta escrituras — el mismo impuesto, tarifa espacial.
• Las consultas near sin límite son trampas. Ordenar por cercanía en una ciudad densa sin radio máximo ni limit clasifica media tabla. Acota siempre la búsqueda.
• Los puntos que se mueven escriben constantemente. Ubicaciones de conductores en vivo significan actualizaciones de GeoPoint de alta frecuencia, cada una manteniendo el índice — agrupa en lotes o limita la frecuencia de las posiciones donde el producto lo permita.
• Un punto por fila es el modelo base. Una tienda con cinco sucursales son cinco registros; formas más ricas que puntos (rutas, áreas de cobertura) empujan hacia bases de datos espaciales completas.
• La precisión tiene pisos. El error esfera-vs-elipsoide es despreciable, pero el ruido del GPS es de metros en un buen día — diseña la lógica del producto (zonas, umbrales) para tolerarlo.

Consultas geoespaciales en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. GeoPoint es un tipo de columna nativo en el almacenamiento gestionado respaldado por MongoDB, y los operadores de proximidad, radio y caja — withinKilometers, near, withinGeoBox — vienen en las APIs generadas automáticamente y en todos los SDKs, exactamente como los usan las pestañas de código de arriba. Los índices geo se gestionan junto con el resto de tu estrategia de índices en el dashboard, lo que convierte el habitual proyecto de infraestructura de “encontrar X cerca” en una decisión de esquema y tres líneas de query.