17

MongoDBの導入により、2.3 >位置データの処理とクエリがさらに便利になりました。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]
}

したがって、作業がより簡単になります。

私の質問は：

GeoJSON2点配列ではなく、点をオブジェクトとして保存する方が良い/推奨されますか?

私が検討したことは次のとおりです。

  • サイズの制約: 何百万ものドキュメントが場所とともに潜在的に存在する可能性があり、コレクションのサイズに影響を与える可能性があり、潜在的に私のポケットに影響を与える可能性があります。
  • lng, lat一貫性: ポイントに固執するのではなく、フォーマット内のすべての座標セットを処理した方がよいでしょうlat, lng。他のすべての位置フィーチャは前者に固執します。
  • 利便性: ポイントを取得して$geoWithinor$geoIntersectsを使用すると、パラメータとして使用する前に最初に GeoJSON に変換する必要がなくなりqueryます。

私が確信していないのは：

  • MongoDB でのサポートloc: [x,y]が将来廃止されるかどうか
  • インデックス作成2dsphereは、2d
  • MongoDB への追加が計画さGeoJSONれている場合、上記の一貫性が必要になるかどうか。

GeoJSON負担が大きい状態で将来切り替えるよりも、データがまだ管理可能なうちに移行したいと考えています。

徹底的に（少しでも）考え抜かれた回答をお願いします。すぐに正解を選択しないので、回答を評価できます。

また、SO が質問をするのに適切な場所であるかどうかもわかりません。そのため、DBA がより適切な場所である場合は、そこに質問を移動します。SO を選択したのは、MongoDB 関連のアクティビティがここにたくさんあるためです。

4

3 に答える 3

17

新しい GeoJSON 形式を使用することをお勧めします。古いフォーマットのサポートをやめるという発表がなされたとは思いませんが、彼らがそれをレガシーと呼んでいるという事実は、彼らの意見を示しているに違いありません.

2d ではなく 2dsphere を使用すると、いくつかのインデックス作成の利点があります。

  • まず、球体である地球に基づいてクエリを実際に計算します。2D インデックスの欠点の 1 つは、基本的な緯度/経度ではなく、クエリでカバーされる実際のエリアに関心がある場合は、自分で変換を処理する必要があるという意味を考慮していないことです。
  • 複合インデックスを使用する機能。「この領域から最新の結果を 100 件取得する」などの操作を行う場合は、2dsphere が唯一の選択肢です。
  • geoIntersects クエリを使用する機能。
  • geoWithin ジオメトリ クエリでは、geoJSON 形式を使用する必要があります。

注意すべきもう 1 つの重要な点は、使用しているクエリが、使用しているインデックスでサポートされていることを確認する必要があるということです。たとえば 2dsphere を使用する場合、インデックスが作成されないため $box クエリを使用できません - ただし、mongo は警告しません- 結果はテーブル スキャンを実行するだけで、非常に遅くなります!

Mongo は、どのクエリをどのインデックスで使用できるかの互換性チャートを提供します

于 2013-05-28T09:55:35.793 に答える
4

はい、それだけの価値があると思います。GeoSpatial Information System での私の経験から、便利で転送可能な標準で位置データを保存するのが最善でしょう。MongoDB の GeoJSON は、WGS84データム標準をサポートしています。

MongoDB では、$near演算子は従来の 2d 座標と GeoJSON 座標で検索できます。従来の 2D 座標コレクションでは、$near は最も近い最初に並べ替えられたコレクションを返します。$geoNearは、検索されたポイント メタ データからの距離で最も近い最初に並べ替えられたコレクションを返します。

もう 1 つの利点は、特に他の GeoJSON タイプ(Polyline、Polygon)を格納する場合に、他の地理空間クエリ(つまり、$geoWithin および $geoIntersect)を使用できることです。

最後に、球面距離を使用した基本的なクエリは 2d インデックスでサポートされていますが、データが主に経度と緯度である場合は、2dsphere インデックスへの移行を検討してください。

この情報が、位置情報データをどうするかについて考えるヒントになることを願っています。

于 2013-05-16T23:59:22.787 に答える
2

データベースにポイント ジオメトリのみを保存しているが、そのデータに対して複数の異なるGeoJSON クエリをサポートしたい場合は、従来の座標ペア形式でポイントを保存し、インデックスを使用できることに注意してください。2dsphere

mongooseのGeoJSON サポート (MongoDB >= 2.4)のリリース ノートには、次の例が示されています。

2dsphere従来の座標ペアのインデックス:

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

GeoJSON2dsphereインデックスを使用して、従来の座標ペアに対してクエリを実行します。

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

Model.find({ loc: { $within: { $geometry: geojsonPoly }}});
于 2014-05-26T23:25:04.160 に答える