GeoJSON e MongoDB: vale la pena conservare punti come GeoJSON.Point?

Question

Con l'introduzione di 2.3 > MongoDB è diventato ancora più utile con la gestione e l'interrogazione dei dati di posizione. MongoDB memorizza i documenti come BSON, quindi ogni documento ha tutti i campi del documento, che ovviamente portano a database più grandi del nostro RMDBS convenzionale.

Ho usato per memorizzare polilinee e poligoni come una serie di punti indicizzati, con un campo extra che rappresenta l'ordine di ogni riga (lo stavo facendo per garantire la coerenza mentre uso JavaScript, quindi i punti non erano sempre memorizzati nel loro giusto ordine). E 'stato qualcosa di simile:

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

Mentre ora uso:

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

ho visto un miglioramento della dimensione dei documenti, come alcune polilinee possono avere fino a 500 punti.

Tuttavia, mi chiedo quali sarebbero i vantaggi di archiviare tutti i miei dati come . Io sono scoraggiato dall'aumento delle dimensioni del documento, come ad esempio:

loc: [1,0] 

è modo migliore di

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

e sarebbe quindi più facile lavorare con.

La mia domanda è:

è meglio/consigliato di memorizzare punti come GeoJSON oggetti in contrapposizione ad un array di 2 punti?

Quello che ho preso in considerazione è la seguente:

• vincoli di dimensione: ho potuto potenzialmente avere milioni di documenti con una posizione, che potrebbe avere un impatto la dimensione della collezione, e potenzialmente tasca.
• Coerenza: sarebbe meglio gestire ogni set di coordinate nel formato lng, lat anziché attenersi a lat, lng per i punti e il primo per tutte le altre funzioni di posizione.
• Praticità: se utilizzo un punto e utilizzo un $geoWithin o $geoIntersects con esso, non è necessario convertirlo prima in GeoJSON prima di utilizzarlo come parametro query.

Quello di cui sono sicuro di è:

• Sia il supporto per loc: [x,y] verrà abbandonato in futuro su MongoDB
• Eventuali prestazioni di indicizzazione da 2dsphere al contrario di 2d
• Sia qualsiasi previsto GeoJSON l'aggiunta a MongoDB potrebbe comportare la necessità della coerenza sopra menzionata.

Preferisco passare a GeoJSON mentre i miei dati sono ancora gestibili, piuttosto che passare in futuro sotto sforzo.

Posso gentilmente chiedere una risposta approfondita (anche se leggermente) ponderata. Presto non selezionerò una risposta corretta, quindi posso valutare tutte le risposte.

Inoltre, non sono sicuro che SO sia il posto giusto per porre la domanda, quindi se DBA è un luogo più appropriato, sposterò la domanda lì. Ho scelto SO perché qui c'è un sacco di attività correlate a MongoDB.

Answer 1

Si consiglia di utilizzare il nuovo formato GeoJSON. Sebbene non ritenga che sia stato fatto alcun annuncio in merito all'abbandono del supporto per il vecchio formato, il fatto che si riferiscano ad esso come eredità dovrebbe essere un'indicazione della loro opinione.

Ci sono alcuni vantaggi di indicizzazione nell'utilizzo di 2dsphere anziché di 2d.

• In primo luogo, in realtà calcola query basate sulla Terra sia una sfera. Uno degli svantaggi di un indice 2d è che non tiene conto di questo significato: dovrai gestire tu stesso la conversione se sei interessato all'area reale coperta da una query piuttosto che al lat/lng di base.
• La possibilità di utilizzare indici composti, se si vuole fare qualcosa come "ottenere 100 risultati da quest'area più recente prima", quindi 2dsphere è la vostra unica scelta.
• La possibilità di utilizzare le query geoIntersects.
• Le query sulla geometria di geoWithin richiedono l'utilizzo del formato geoJSON.

Un'altra cosa importante da notare è che è necessario assicurarsi che la query che si sta utilizzando sia supportata dall'indice che si utilizza. Ad esempio, se utilizzi una 2dsphere non puoi utilizzare una query $ box perché non verrà indicizzata, tuttavia mongo non ti avviserà - il risultato eseguirà solo una scansione della tabella e sarà molto lento!

Mongo provide a compatibility chart of which queries can be used with which index

Answer 2

Sì, penso che ne valga la pena. Dalla mia esperienza con GeoSpatial Information System, sarebbe meglio memorizzare i dati di localizzazione in uno standard utile e trasferibile. GeoJSON in MongoDB supporta lo standard di riferimento WGS84.

In MongoDB l'operatore $near può eseguire ricerche sulle coordinate 2d legacy e sulle coordinate GeoJSON. Su una collezione di coordinate 2d legacy, $ near restituisce la prima raccolta ordinata più vicina. $geoNear restituisce una prima raccolta ordinata più vicina con distanza dai metadati dei punti ricercati.

Un altro vantaggio è la possibilità di utilizzare altre query geospaziali (cioè $ geoWithin e $ geoIntersect) soprattutto se si memorizzano i tipi altro GeoJSON (Polilinea, Poligono)

Infine While basic queries using spherical distance are supported by the 2d index, consider moving to a 2dsphere index if your data is primarily longitude and latitude.

spero questa informazione ti dà alcuni punti di riflessione su cosa fare con i tuoi dati di localizzazione.

Answer 3

Se sei solo punto di stoccaggio geometrie nel database, ma desidera supportare più diversi GeoJSON interroga su tali dati, allora si noti che è possibile memorizzare i punti in eredità coordinare formato coppia e utilizzare un indice di 2dsphere.

Il release notes sostegno GeoJSON di mangusta (MongoDB> = 2.4) invia il seguente esempio:

2dsphere indice sulla legacy coppie di coordinate:

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

GeoJSON interrogare l'eredità di coordinate coppie, utilizzando l'indice 2dsphere:

var geojsonPoly = { 
    type: 'Polygon', 
    coordinates: [[[-5,-5], ['-5',5], [5,5], [5,-5],[-5,'-5']]] 
}; 

Model.find({ loc: { $within: { $geometry: geojsonPoly }}});