GeoJSON и MongoDB: Стоит ли хранить точки в виде GeoJSON.Point?

Question

С введением 2.3 > MongoDB стал еще более полезным при обработке данных и обработке запросов. MongoDB хранит документы как BSON, поэтому каждый документ имеет все поля документа, что, очевидно, потенциально приводит к большим базам данных, чем наши обычные RMDBS.

Я использовал для хранения полилиний и полигонов в виде ряда индексированных точек с дополнительным полем, представляющим порядок каждой строки (я делал это, чтобы обеспечить согласованность при использовании JavaScript, поэтому точки не всегда сохранялись в их правильный заказ). Это было что-то вроде этого:

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

А сейчас я использую:

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

Я видел улучшение в размере документов, так как некоторые ломаные может иметь до 500 пунктов.

Тем не менее, мне интересно, какие преимущества хранения всех моих Point данных будут GeoJSON. Я обескуражен увеличением размера документа, как, например:

loc: [1,0] 

это лучше, чем

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

и, таким образом, будет легче работать.

Мой вопрос:

Является ли это лучше/рекомендуется хранить в качестве точек GeoJSON объектов, в отличие от массива в 2 очка?

Что я рассмотрел это следующие:

• Размер ограничения: Я мог бы потенциально иметь миллионы документов с места, что может повлиять на размер сбора и потенциально мой карман.
• Последовательность: было бы лучше иметь дело с каждым набором координат в формате lng, lat, в отличие от прикрепления к lat, lng для очков, а также для всех моих других функций местоположения.
• Удобство: Если я возьму точку и воспользуюсь с ней $geoWithin или $geoIntersects, мне не нужно было бы преобразовывать ее в GeoJSON прежде, чем использовать ее в качестве параметра query.

Что я неуверен является:

• ли поддержка loc: [x,y] будет отброшен в будущем на MongoDB
• Любые индексирование выгоды от 2dsphere в отличие от 2d
• ли какой-либо плановой GeoJSON дополнения к MongoDB могут привести к необходимости согласованности, упомянутой выше.

Я предпочел бы переехать в GeoJSON, пока мои данные по-прежнему управляемы, чем в будущем в будущем под большим напряжением.

Прошу вас просить полностью (хотя бы слегка) продуманный ответ. Я скоро не выберу правильный ответ, поэтому я могу оценить любые ответы.

Я также не уверен, что SO является правильным местом для постановки вопроса, поэтому, если DBA является более подходящим местом, я переведу туда вопрос. Я выбрал SO, потому что здесь много активности, связанной с MongoDB,.

Answer 1

Я бы рекомендовал использовать новый формат GeoJSON. Несмотря на то, что я не считаю, что было сделано какое-либо заявление об отказе от поддержки старого формата, тот факт, что они относятся к нему как к наследию, должен служить указанием на их мнение.

Есть некоторые преимущества индексации при использовании 2dsphere, а не 2d.

• Во-первых, он фактически вычисляет запросы на основе Земли, являющейся сферой. Один из недостатков индекса 2d заключается в том, что он не учитывает это значение, что вам придется обрабатывать преобразование самостоятельно, если вы заинтересованы в фактической области, покрываемой запросом, а не в базовых латах/lng.
• Способность использовать составные индексы, если вы хотите сделать что-то вроде «получить 100 результатов из этой области, которые были самыми последними», то 2dsphere - ваш единственный выбор.
• Возможность использования запросов geoIntersects.
• Геометрические запросы geoWithin требуют, чтобы вы использовали формат geoJSON.

Еще одна важная вещь, которую следует учитывать, заключается в том, что вам необходимо убедиться, что используемый вами запрос поддерживается индексом, который вы используете. Если вы используете 2dsphere, например, вы не можете использовать запрос $ box, поскольку он не будет проиндексирован - однако mongo не предупредит вас - результат будет просто выполнять сканирование таблицы и будет очень медленным!

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

Answer 2

Да, я думаю, это того стоит. Из моего опыта работы с GeoSpatial Information System лучше всего хранить данные о местоположении в полезном и переносимом стандарте. GeoJSON в MongoDB поддерживает базовый стандарт WGS84.

В MongoDB оператор $near может выполнять поиск по старым координатам 2d и координатам GeoJSON. В старой коллекции координат 2d $ near возвращает ближайшую первую отсортированную коллекцию. $geoNear возвращает ближайшую первую отсортированную коллекцию с расстоянием от метаданных, найденных в точке.

Еще одним преимуществом является возможность использования других геопространственных запросов (т.е. $ geoWithin и $ geoIntersect) особенно, если вы храните типы другой GeoJSON (полилинию, многоугольник)

Наконец 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.

Я надеюсь, эта информация дает вам несколько соображений о том, что делать с данными вашего местоположения.

Answer 3

Если вы только Запоминание точки геометрии в базе данных, но вы хотите поддерживать несколько отличается GeoJSON запросов по этим данным, то обратите внимание, что можно хранить точки в наследство формата координат пары и используйте индекс 2dsphere.

release notes для поддержки GeoJSON Mongoose (в MongoDB> = 2.4) привести следующий пример:

2dsphere индекс на наследство пары координат:

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

GeoJSON запроса на наследство координат пар, используя 2dsphere индекс:

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

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