タグ付けされた質問 「spatial-database」

空間データベースは、ポイント、ライン、ポリゴンなど、空間内のオブジェクトに関連するデータを格納および照会するために最適化されたデータベースです。

2
天体座標の地理データを保存するには、どの座標系を使用する必要がありますか？
私は天文学プロジェクトをしています。画像に関する情報を空間的に有効化されたデータベースに保存したい。空は完全に球体として扱うことができ、地球の表面のような楕円形の処理を必要としないため、これはGIS機能の非常に簡単な特別なケースになるはずです。残念ながら、私はまだこれを行う方法を見つけていませんし、楕円地球を使用する空間関数で地雷をかわしています。（度ではなくメートルを返すほとんどの関数は、楕円計算を使用している可能性があります。幸いなことに、必要なPostGIS関数の多くは、返された結果が球ではなく楕円体。しかし、それは将来のバージョンで変わる可能性があり、懸念の原因です） 背景：現在、PostGISおよびWGS 84座標（SRID = 4326）でPostgreSQLを使用しています。これはかなりうまくいきます。画像の四隅の赤経と赤緯から閉じたポリゴンを作成しています。たくさんの画像（10k以上）があり、空の広い領域をカバーしています。各画像は約1度の正方形です。これらの画像のセットから、15〜30個の画像の小さなサブセットからモザイクを作成しています。各モザイクは約1.5度の正方形です。 現在、モザイクの地理を、モザイクに入った各画像に対応するすべてのポリゴンで構成されるマルチポリゴンとして保存しています。[より良い解決策は、すべての個々のポリゴンの結合の周囲を記述する単一のPOLYGONを作成することです。これが球面座標（つまり、地理タイプ）で実行できるかどうかはわかりません。これも私にとって興味深い答えです。]日付変更線と天の極がデータセットの画像に含まれている可能性があるため、可能な限り平面座標への投影を避けています。 PostGIS関数を使用して天体座標に使用する必要がある座標系は何ですか？ 私はhttp://spatialreference.org/を見まし たが、これまでのところ何も見つかりませんでした。Googleはほとんど姿を見せていない。私は困惑しています。基本的に、関数が距離としてメートルを返す場合、それは球上の大円に沿ったメートルであることを確認したいです。 より一般的には、空間データベースで天体座標を使用するためのアドバイスも歓迎します。 PostGISを選択することでエラーが発生しましたか？ はるかに優れた商業的選択肢はありますか？ FOSSの選択？ PostGIS 1.5.2を使用しています。PostGIS 2.0はまだ試していません。ST_CoveredBy関数がタイプgeographyのPOLYGONおよびMULTIPOLYGONで機能するかどうか興味があります。誰かが2.0を実行している場合、これと同じエラーが発生するかどうか教えてください： mydb=# select ST_CoveredBy(ST_GeographyFromText('MULTIPOLYGON(( (10.37795 -69.57926,8.9498 -69.54875,9.0178 -69.21643,10.4242 -69.24648,10.37795 -69.57926),(10.42436 -69.24618,9.01774 -69.2162, 9.08363 -68.88389,10.46914 -68.91344,10.42436 -69.24618)))'),ST_GeographyFromText('POLYGON((10.46915 -68.91315,9.08371 -68.88364,9.14755 -68.5513,10.5125 -68.58038,10.46915 -68.91315))')); ERROR: geography_covers: only POLYGON and POINT types are currently supported CONTEXT: SQL function "st_coveredby" …
5
ArcGIS for DesktopはSpatiaLiteをサポートしていますか？
SpatiaLiteは私の組織でますます重要な役割を果たしています。 2012年の時点では、ArcGIS DesktopとSpatiaLiteを併用するには、常に些細なことではなかったデータのインポートとエクスポートが必要でした。 Data Interoperability ExtensionやFMEなどの製品以外に、ArcGIS for DesktopでSpatiaLiteをサポートする他のオプションはありますか？
4
空間インデックスを使用すべきでない場合
私は主にOracleで働いていたのでこれを求めていますが、過去1年間はPostGISとSQLServer 2008で倍増しています。Oracleのほとんどの空間関数はORA-13226エラーを返す空間インデックスなしでは機能しません。 13226、00000、「インタフェースは空間索引なしではサポートされていません」原因：ジオメトリ表に空間索引がありません。// *アクション：空間演算子で参照されるジオメトリテーブルに空間インデックスがあることを確認します。 これは理にかなっています。空間クエリを実行します=空間インデックスが必要です。しかし、私が理解している限りでは、SQL ServeではなくPostGISもこれを必要としません。PostGISには、空間インデックスを明示的に使用しない関数（_ *例_STContains）があるようです。 問題は、空間インデックスを使用してはならないケースがあるかどうかです。「取る」か「残す」かは必ずしも違いません。つまり、違いはありませんが、空間インデックスを使用しないとパフォーマンスが低下します。私にとって、最後の文は用語の矛盾ですが、そうでなければPostGISがこれらの機能を提供するのはなぜですか？
3
レイヤーの複数のコピーの整理と整頓？[閉まっている]
大学にいた頃、「組織と整頓」の問題がありました。組織化されておらず、レイヤーを異なる名前の異なるフォルダーに保管していたため、各レイヤーのコピーが複数ありました。 仕事を始めて以来、私は多くのことを改善してきました–特別なフォルダーを特別なサブフォルダーで維持します。レイヤーの名前をもう少しきちんとしたシステムに基づいて付けますが、レイヤーの複数のコピーを管理する必要があるため（AutocadとArcGISは非ラテン語を扱う場合に違いがあるため、コピーを保持する必要があります）プログラムごとに調整されています）、あなたの経験から聞いて、あなたからいくつかのヒントを学びたいと思います： レイヤーをどのように整理しますか？それらにどのように名前を付けますか？名前、日付、内容、顧客ごと？ 複数のコピーをどのように整理または処理しますか（より深刻：複数のコピーを一度に更新するにはどうすればよいですか）。 注：私は、ウェブ開発者/ウェブマネージャーのPOVではなく、アナリスト/ DBA POVから話をしています（私自身のために、おそらく2人以上のGISワーカーのためにレイヤーを整理することについて話しています）。
2
1つのPostGISテーブルでジオメトリタイプを混合する
次の問題に直面しています。OracleデータベースからPostgreSQL + PostGISに移行する必要があります。現在、すべてのタイプのすべてのジオメトリが1つのテーブルに格納され、各レコードには同じレイヤーのフィーチャを示す「lid」フィールドが含まれています。 そのような方法を使用することの長所と短所は何ですか？データベースをサードパーティのソフトウェアで使用する必要がない場合、データを複数のテーブルに分割する必要がありますか？空間クエリのパフォーマンスはどうですか？インデックスは役立ちますか？
7
小規模な大学の研究センター向けのGISソフトウェアの選択[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 小さな大学の研究センター用のGISシステムを選択する必要があります。私たちは幅広いデータ（たとえば、数値潮anal分析、気象データ、貧困、孤立した経済活動、スキルの利用可能性、再生可能エネルギー資源の利用可能性）を扱っており、既存のデータセットが比較的貧しい国で主に営業しています。 他のグループとやり取りしますが、その一部はARCGISを使用しています。Web上のすべてのGISソフトウェア記述子を調べる必要がありますか、それとも誰かが候補者の可能性を示してください。
3
PostGISに大きなラスターを保存し、QGISで視覚化するとパフォーマンスが低下する
私の質問は、PostgreSQL、PostGIS、QGIS、およびGDALなど、いくつかのソフトウェアツールを組み合わせて使用​​およびパフォーマンスすることに関するものです。 私は、ArcGIS、Python、Rの長年のユーザーであり、無料のオープンソースGISエコシステムとLinuxへの多様化にも関心があります。最近、QGIS（ver 2.8）をPostgreSQL（ver 9.4）およびPostGIS（ver 2.1）と一緒に使用することに非常に興味があり、Windows 8.1 x64を搭載したコンピューターにコンピューターにソフトウェアをインストールしました（コンピューターの仕様：ThinkPad 2.1GHzコア2、8GB RAM、および240GB SSDを搭載したX200）。空間データ（〜100GB相当）の管理方法を学んだら、このマシンでUbuntuを実行したいと思います。 現時点では、シェープファイルとラスターを確実に保存および取得しようとしています。これまでのところ、シェープファイルをPostGISに読み込むことに成功していますが、ラスターはより問題が多いことが判明しています。小さなgeoTIFFおよびGRIDファイルの単一およびバッチインポートを正常に完了しましたが、大きなラスター（たとえば、ディスク上のサイズが156MBの15619x14655セルIMGまたはTIFFファイル）がPostGISにロードされるまでに時間がかかります。空間インデックスを構築し、これらのパラメーターを使用してタイルによってラスターを読み込むために、raster2pgsqlツールを読んで構成しました。 raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgres インポートのパフォーマンスは依然として非常に低く、ハードウェアは問題ではありません。QGISでのPostGISラスターの視覚化はさらに悪く、せいぜい小さなラスターをゆっくりロードするか、完全にフリーズします。私が述べたような大きなラスターは、QGISで視覚化することは不可能です。ドキュメントとフォーラムの議論から、この欠点はQGIS自体ではなく、GDALのPostGISラスタードライバーによるものと思われます。フォーラムでの議論ではこの問題について簡単に言及しており、ラスタをPostGISに保存すべきではないと示唆する人もいます（ラスタをスムーズに処理できない空間データベースのポイントは何ですか？）。それでも、私は日常的にESRIのファイルジオデータベースを使用して、非常に大きな（〜70GB）ラスターをすばやく簡単に保存、視覚化、分析し、ArcGIS 10.1はそのような日常的な操作によってフリーズまたはスローダウンすることはありません。 ここで不足しているもの、対処していないボトルネックはありますか？PostGISのパフォーマンス上の利点を実現するために、PostgreSQLをチューニングする必要がありますか？探してコンパイルする必要があるGDALのバージョンがありませんか？特に、QGISでのシェープファイルとラスターのPostGISパフォーマンスと視覚化を改善するにはどうすればよいですか？Linuxターミナルを使用して、包括的かつ迅速な空間データ管理の栄光を享受するにはどうすればよいですか？この問題に関する助けを歓迎します！ Duncan Golicherがこのガイドに従いました：https ://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/ 私は元々自動設定のタイルを使用していましたが、タイルを行ごとに100x100セルにリセットし、ガイドに示されているようにピラミッドを含めました。 raster2pgsql -s 3161 -d -C -I -M -l 4 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 …
2
オープンソースとESRIの両方の使用に最適なジオデータベースタイプはどれですか？
主な質問：ESRIとオープンソース製品の両方でシームレスに動作するジオデータベースタイプはありますか？ 詳細：私の会社は現在、さまざまなベクターおよびラスターファイル形式でジオデータを渡し、特に編成されていません。ほとんどの処理はオープンソースツールを使用して行われますが、一部の顧客はデータをESRI Mapサービス形式でホストすることを要求しています。これらのサービスをホストするArcGISサーバーインスタンスは既にありますが、ESRI arcsdeジオデータベースに結果をダンプする前に、オープンソースツールを使用してアップストリームで処理します。私の知る限り、ogr / gdalにはarcsdeジオデータベースからの読み取り/書き込み機能が多少制限されていますが、すべてのデータをarcsdeジオデータベースに合理的に格納し、処理ツールがarcsdeを使用できることを期待できるほどではありません会社のプライマリデータストアとしてのジオデータベース。私が間違っている？postgisなどのオープンソースジオデータベースに切り替えた場合、処理ツールは正常に機能しますが、ESRIサービスをホストするためのデータストアとしてpostgisデータベースを使用できるとは思いません。私が間違っている？オープンソースとESRIの両方をシームレスに処理できるジオデータベースタイプはありますか？そうでない場合、オープンソース用とESRI用の並列ジオデータベースを維持するのが一般的ですか？ 追加のしわ：私が得た答えはPostgreSQL / PostGISを使用することでした。唯一の潜在的なしわは、このデータベースをAmazon Web Services（AWS）でホストし、可能であればAmazon Relational Database Service（RDS）を使用してデータベース管理のオーバーヘッド（バックアップ、負荷分散）を最小限にしたいことですなど）。ただし、RDSは現在、データベースエンジンとしてMySQL、Oracle、およびSQL Serverのみをサポートしています。RDSがPostgreSQLのサポートを開始する場合、これが理想的なシナリオになると考えていますが、再確認するには、PostgreSQLはArcGIS + gdal / ogrベースのオープンソースの相互運用性の正しい唯一のオプションですか？その場合、AWSでPostgreSQLデータベースを作成する可能性が高いので、それを管理するためにより多くのリソースを費やす必要があります。
3
（いつ）GIS対応データベースを使用する必要がありますか？
私はGISを初めて使用する長年のプログラマです。GISのデータベースの側面を把握しようとしていますが、GISの使用に特化したデータベースがいくつかあることを理解しています。基本的に、このようなデータベースを使用するか、非常に人気があり、確立され、広くサポートされている（そして無料の）MySqlを使用するかを理解しようとしています。 私がコーディングしなければならない種類のアプリケーションは、次のようなものです。 フリート管理（陸上または海洋ベースの車両） 従業員追跡 在庫管理（メートル単位で正確な物理的位置の粒度で） えーと、それについてです、本当に 通常、追跡するアイテムの数はわずか数百（最大、おそらく数千）になります。アイテムは、アプリケーションに応じて、同じ（大きな）建物、一連の建物、都市、国、または世界中に配置される場合があります。 私は時々、建物のカスタムフロアプランで、またはGoogle Earthなどで（おそらく別の質問で）それらを視覚的に表現します。 私はMySqlを使ってlat / longまたはその他の位置データの列を追加しているようですが、それは単にMySqlを知っているからかもしれません。 より専門的なデータベースを検討する必要がある理由はありますか？
3
空間データベースの違いは何ですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 閉じた3年前。 Oracle Spatial、PostGIS、SQLServer2008、SpatiaLite、MySQLの空間サポートの違いは何ですか？それぞれが輝く特定のユースケースはありますか。これらのデータベースで何を避けたいのでしょうか。
9
空間データを保存するデータベースを選択しますか？
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 数日前、空間情報4.9のデモをMapInfoからSQL Server 2005のインストールにインストールし、すべての大きなデータセットをロードしました。古いファイルベースのアプローチに対するパフォーマンスに非常に感銘を受けましたが、他にどんなオプションがあり、それらの長所と短所は何かを考えさせられました。 Spatialwareで私が言わなければならない欠点は、それが$ 5000 p / aであり、MapInfoのみがそこからオブジェクトを読み取ることができるという事実です。MapInfoのみを使用しているため、現時点では問題ありません。 私は他の人々が何をしたのか、彼らの経験は何なのかと思っています。
1
ジオハッシュと比較したRツリーの利点
ジオハッシュは、Lucene、mongodbなどの製品で広く使用されており、現在の最も重要な技術の1つになっています。 ジオハッシュは古き良きRツリーを置き換えましたか、それともジオハッシュと比較してRツリーには利点がありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.