13

地図を保存するための理想的なデータベースまたはデータ構造の提案を探しています。基本的に、マップは道路や小道などのような「ウェイ」で構成されます。ウェイにはノード (緯度と経度の座標、場合によっては高度) が含まれます。

そのようなデータベースまたは構造:

  1. バウンディング ボックス内のすべてのノードをすばやく (ミリ秒単位で) 見つけることができる必要があります。

  2. オプションで、多数のノードがバウンディング ボックス内にある場合と少数のノードの場合、またはバウンディング ボックスが大きい場合に、大幅に速度が低下しないようにする必要があります。

  3. 直接接続するノードを見つけることができる必要があります。たとえば、2 つの方法で接続するノードです。

  4. 読み取り専用でした

  5. コンパクトにする必要があります（スペースの無駄を避けます）-英国の地図を1 GB未満に収めたいと考えています。SD カードに約 800 MB の空き容量があるナビを持っています。

最初は、ウェイを格納するための四分木を考えていました。しかし、迅速な実装には注意が必要であり、個々のノードでは機能しません。すべてのノードは、可能な限り最小の bbox に配置されます。

(Open Street Map のデータを使用する予定があるため、意図的に同じ用語を使用しています。)

4

5 に答える 5

8

PostGIS 1.5では、必要に応じてgeographyタイプを使用することをお勧めしますが、組み込みデバイスでこのようなものを使用する際の唯一の懸念はメモリ使用量です。

Java で非 GIS データベース (firebird) を使用して漠然と関連するものを構築しましたが、パフォーマンスはバウンディング ボックス内のポイントを取得するのに十分でした (ただし、PostGIS には当てはまらない派手な SQL が必要でした)。

于 2010-10-06T14:29:31.683 に答える
7

PostGISが最良の選択かもしれません。注: PostGISは、地理的拡張機能を備えた PostgreSQL です。文字通り postgres をインストールしてから、geo 関数とタイプを追加するさまざまなスクリプトを実行します。

PostGIS に関する OpenStreetMap の情報を参照してください。osm2pgsql を使用して、OpenStreetMap の惑星ファイル/惑星抽出物を PostGIS にロードできます。これは、Mapnik レンダラーが実行される OpenStreetMap タイル サーバーで行われます。でも...

OpenStreetMap データ用のより生のデータベース スキーマもあります (「ノード」や「ウェイ」などと呼ばれるテーブル) 。これは、空間インデックスなどに関してはそれほど賢くはありませんが、素晴らしくシンプルです。この形式でデータベースを作成するには、OpenStreetMap API/website ruby​​ on rails codeをインストールします。これは、最新バージョンのデータベース スキーマ( rails migrations で 定義)を設定する最も信頼できる方法です。その後、osmosisツールを実行してデータベースにデータを入力することができます。

于 2010-10-18T16:20:04.973 に答える
3

PostGISは地理空間データをサポートする唯一のデータベースではありませんが、価格は非常に優れています。「無料」に勝るものはありません。

しかし、他にも無料のオプションがあり、一部の読者はすでに別のリレーショナルデータベースシステムを導入していて、PostGISを学ぶ代わりにその専門知識を活用したいと思うかもしれません。説明するシナリオには、Open Geographical Consortium仕様（OGCまたはOpenGeo）をサポートするデータベースで十分です。

そして、写真の世界からの格言のように-「最高のカメラはあなたが持っているものです」-時には理想的な空間データベースはあなたがすでに持っていて使い方を知っているものです。

だからここに私が知っているすべてのオプションのリストがあります：

空間RDBMS-無料オプションが利用可能

  • Oracle（SpatialまたはLocatorを使用）（無料オプション：Oracle XE + Locator）
  • MS SQL Server（2008以降）（無料オプション：SQL Server Express）
  • PostGIS

空間RDBMS-無料オプションなし

  • DB2（Spatial Extender付き）
  • Informix（Spatial Blade付き）

理想的ではない空間RDBMS

  • MySQL Spatial（非常に限られた機能セット）

空間的な「エクステンションウェア」

  • ArcSDE（既存のRDBMSに追加します）
于 2011-12-13T20:59:00.337 に答える
1

私が知っている地理データ用の最適なデータベースは、geo 拡張機能を備えた PostgreSQL ですが、速度についてはわかりません。OSM がこれを使用していることは知っていますが、OSM は高速で巨大なコンピューター インフラストラクチャにアクセスできます。また、より高速なプログラムを作成できる人を求めていることも知っています。

Quadtree は、地理空間データを処理するための非常に優れたオプションであると言えます。私が知る限り、正方形が小さすぎることを許可しているようです。境界をよりソフトにし (ノードがクワッドツリーの 2 つのリーフにあるようにする)、リーフごとに最小限のノードを追加することができます。どのリーフにも 64 未満のノードを含めることは許可されておらず、1024 を超えてはいけないとします。

並べ替えは、ここでの速度にとって特に重要です。提案は、最初にアクセスされる可能性が高いエリアを並べ替えることです。すべてのリクエストの 70% がロンドン周辺にあるとします。この場合、このデータをファイルの先頭に配置して検索時間を短縮するのが最も高速です。

于 2010-10-09T20:59:32.753 に答える
0

スペースについてはわかりませんが、一般的なデータベース サーバーに Geo 拡張機能を使用することを検討することをお勧めします (可能な場合)。それらは通常、高速な地理的索引付け、バウンディング・ボックス・ベース (1 および 2 への回答) を提供し、計算を行うための多くの地理的手順 (3、3 への回答intersect(way1,way2)) を提供します。

また、あなたの質問はhttp://gis.stackexchange.comに適しています

于 2010-10-02T23:28:04.027 に答える