how - GeoJSON y MongoDB: ¿Vale la pena almacenar puntos como GeoJSON.Point?

mongodb index 2dsphere

Question

Con la introducción de 2.3 > MongoDB se ha vuelto aún más útil con el manejo y la consulta de los datos de ubicación. MongoDB almacena documentos como BSON, por lo que cada documento tiene todos los campos de documentos, lo que obviamente conduce a bases de datos más grandes que nuestro RMDBS convencional.

Solía ​​almacenar polilíneas y polígonos como una serie de puntos indexados, con un campo adicional que representa el orden de cada línea (estaba haciendo esto para garantizar la coherencia al usar JavaScript, por lo que los puntos no siempre se almacenaban en su orden correcto). Fue algo como esto:

polyline: {
[
point: [0,0],
order: 0
],
[
point: [0,1],
order: 1
]
}

Mientras que ahora uso:

polyline: {
type: ''LineString'',
coordinates: [
[0,0],
[1,0]
]
}

He visto una mejora en el tamaño de los documentos, ya que algunas polilíneas pueden tener hasta 500 puntos.

Sin embargo, me pregunto cuáles serían los beneficios de almacenar todos los datos de mi Point como GeoJSON . Me desanima el aumento en el tamaño del documento, como por ejemplo:

loc: [1,0]

es mucho mejor que

loc: {
type: ''Point'',
coordinates: [0,1]
}

y por lo tanto sería más fácil trabajar con ellos.

Mi pregunta es:

¿Es mejor / recomendado almacenar puntos como objetos GeoJSON en lugar de una matriz de 2 puntos?

Lo que he considerado es lo siguiente:

• Restricciones de tamaño: potencialmente podría tener millones de documentos con una ubicación, lo que podría afectar el tamaño de la colección y potencialmente mi bolsillo.
• Coherencia: sería mejor tratar con cada conjunto de coordenadas en el formato lng, lat en lugar de mantener lat, lng para puntos, y el primero para todas mis otras características de ubicación.
• Conveniencia: Si tomo un punto y uso un $geoWithin o $geoIntersects con él, no tendría que convertirlo a GeoJSON antes de usarlo como un parámetro de query .

Lo que no estoy seguro es:

• Si el soporte para loc: [x,y] se eliminará en el futuro en MongoDB
• Cualquier beneficio de indexación de 2dsphere en lugar de 2d
• Si cualquier adición planeada de GeoJSON a MongoDB podría resultar en la necesidad de la consistencia mencionada anteriormente.

Prefiero GeoJSON a GeoJSON mientras mis datos aún son manejables, que cambiar en el futuro bajo mucha presión.

¿Puedo por favor pedir una respuesta concienzuda (aunque sea un poco)? No seleccionaré una respuesta correcta pronto, así que puedo evaluar cualquier respuesta .

Tampoco estoy seguro de que SO sea el lugar correcto para plantear la pregunta, por lo que si DBA es un lugar más apropiado, moveré la pregunta allí. Elegí SO porque hay mucha actividad relacionada con MongoDB aquí .

Answer 1

Sí, creo que vale la pena. Desde mi experiencia con el Sistema de información geoespacial, sería mejor almacenar sus datos de ubicación en un estándar útil y transferible. GeoJSON en MongoDB es compatible con el estándar de referencia WGS84 .

En MongoDB, el operador $near puede buscar coordenadas 2d heredadas y coordenadas GeoJSON. En una colección de coordenadas 2d heredada, $ near devuelve la primera colección ordenada más cercana. $geoNear devuelve la primera colección ordenada más cercana con la distancia de los metadatos de puntos buscados.

Otro beneficio es la capacidad de usar otras consultas geoespaciales (es decir, $ geoWithin y $ geoIntersect) especialmente si almacena otros tipos de GeoJSON (Polilínea, Polígono)

Por último, si bien las consultas básicas que utilizan la distancia esférica son compatibles con el índice 2d, considere pasar a un índice 2dsphere si sus datos son principalmente de longitud y latitud.

Espero que esta información le proporcione algunos puntos de reflexión sobre qué hacer con sus datos de ubicación.

Answer 2

Si solo está almacenando geometrías de puntos en su base de datos, pero desea admitir varias consultas GeoJSON diferentes en esos datos, tenga en cuenta que es posible almacenar puntos en formato de pares de coordenadas heredados y usar un índice de 2dsphere .

Las notas de la versión para el soporte GeoJSON de Mongoose (MongoDB> = 2.4) dan el siguiente ejemplo:

Índice 2dsphere en pares de coordenadas heredadas:

new Schema({
loc: { type: [Number], index: ''2dsphere''}
});

GeoJSON en los pares de coordenadas heredadas, utilizando el índice 2dsphere :

var geojsonPoly = {
type: ''Polygon'',
coordinates: [[[-5,-5], [''-5'',5], [5,5], [5,-5],[-5,''-5'']]]
};
Model.find({ loc: { $within: { $geometry: geojsonPoly }}});

Answer 3

Yo recomendaría usar el nuevo formato GeoJSON. Si bien no creo que se haya hecho ningún anuncio acerca de abandonar el soporte para el formato antiguo, el hecho de que se refieran a él como legado debería ser una indicación de su opinión.

Hay algunos beneficios de indexación al usar 2dsphere en lugar de 2d.

• En primer lugar, en realidad calcula las consultas basadas en que la Tierra es una esfera. Una de las desventajas de un índice 2d es que no tiene en cuenta esto, lo que significa que tendrá que manejar la conversión usted mismo si está interesado en el área real cubierta por una consulta en lugar de la lat / lngs básica.
• La capacidad de usar índices compuestos, si desea hacer algo como "obtener 100 resultados de esta área, la más reciente primero", entonces 2dsphere es su única opción.
• La posibilidad de utilizar consultas geoIntersects.
• Las consultas de geometría geoWithin requieren que use el formato geoJSON.

Otra cosa importante a tener en cuenta es que debe asegurarse de que la consulta que está utilizando esté respaldada por el índice que utiliza. Si utiliza un 2dsphere, por ejemplo, no puede usar una consulta de $ box ya que no se indexará. Sin embargo, Mongo no le avisará . ¡El resultado solo realizará un escaneo de la tabla y será muy lento!

Mongo proporciona una tabla de compatibilidad de las consultas que se pueden utilizar con qué índice