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

私は1年の3/4でPostgis 2.0を使用していますが、実際に使用している間は、クエリ処理に時間がかかりすぎて、ユースケースでは基本的に使用できなくなりました。 私は、多くの場合、数十万のマルチポリゴンを持つ地方自治体のデータセットで大量のジオプロセシングを行う傾向があります。これらのマルチポリゴンの形状は非常に不規則な場合があり、マルチポリゴンごとに4ポイントから78,000ポイントまで変化する可能性があります。 たとえば、525個のマルチポリゴンを含む管轄データセットで329,152個のマルチポリゴンとパーセルデータセットを交差させると、合計消費時間について次の統計が得られます。 ArcGIS 10.0 (on same host with windows 7 OS): 3 minutes Postgis:56 minutes (not including geometry pre-processing queries) 言い換えると、ArcGISよりもPostgisでこの共通部分を実行するのに1500％長い時間が必要です。これは、私の最も単純なクエリの1つです。 ArcGISが高速に実行されると思われる理由の1つは、インデックスの改善によるものです。最近、一部のプログラマはこれらのインデックスがどのように機能するかを理解しました。Postgisでこれらのインデックスを作成する方法（またはインデックスを模倣するテーブルを作成する方法）を知っている人がいるかどうか疑問に思います。おそらくこれはPostgisの速度の問題のほとんどを解決するでしょう。特にArcGISは4 GBのRAMしか使用できませんが、postgisサーバーの最大4倍のRAMを使用できるため、何らかの方法が必要だと思います。 もちろん、postgisの動作が遅くなる理由はたくさんありますので、システム仕様の詳細バージョンを提供します。 Machine: Dell XPS 8300 Processor: i7-2600 CPU @ 3.40 GHz 3.40 GHz Memory: Total Memory 16.0 GB (10.0 GB on virtual machine) Platform: Ubuntu …

62 postgis  sql  algorithm  spatial-index 

私はこれらの列を持つpostgresql / postgisにラスターデータベースを持っています： （ID、rast、data_of_data）。 「ラスト」は、WKT形式のラスターファイルがある列です。WGS84システム（30.424、-1.66）および2002-01-09のポイントのDN値を検索するクエリの例は次のとおりです。 SELECT st_value(rast,(st_GeomFromText('POINT(30.424 -1.66)', 4326))) as val FROM my_table WHERE date_of_data='2002-01-09' これらの種類のクエリを高速化する方法（空間インデックスなど）はありますか？

16 postgis  raster  query  performance  spatial-index 

SQL Server 2008 R2 Expressデータベースには約7,500万件のレコードがあります。それぞれは、ある値に対応する緯度経度です。テーブルにはgeography列があります。特定の緯度経度（ポイント）の最も近い隣人を見つけようとしています。既に空間インデックスを使用したクエリがあります。ただし、レコードがデータベース内のどこにあるか、たとえば第1四半期または最後の四半期に応じて、クエリは3〜30秒で最も近い隣を見つけることができます。これは、クエリまたは空間インデックスを最適化することで、より高速な結果を得るために最適化できると思います。現在、デフォルト設定でいくつかの空間インデックスを適用しています。これが私のテーブルとクエリの外観です。 CREATE TABLE lidar( [id] [bigint] IDENTITY(1,1) NOT NULL, [POINTID] [int] NOT NULL, [GRID_CODE] [numeric](17, 8) NULL, [geom] [geography] NULL, CONSTRAINT [PK_lidar_1] PRIMARY KEY CLUSTERED ([id] ASC) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) …

16 sql-server  lidar  spatial-index  nearest-neighbor  optimization 

約200万レコードのテーブルがあります。境界ボックス以外のデフォルトを使用して、空間インデックスを作成します。一部のクエリは非常に高速で、一部のクエリは非常に低速であることに気付きました。決定要因は、クエリで使用されるポリゴンのサイズに現れます。 より大きな検索エリアでは、を使用WITH(INDEX(SIX_FT5))するとクエリが大幅に遅くなります（0秒から15秒以上）。小さい検索エリアでは、正反対が当てはまります。 以下は、私がテストしているクエリの一部です。 高速： SELECT TOP(1000) * FROM [FT5] WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1) スロー： SELECT TOP(1000) * FROM [FT5] WITH(INDEX(SIX_FT5)) WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1) 誰がここで何が起こっているのか知っていますか？

14 sql-server  performance  spatial-index 

Postgisの空間GiSTインデックスの内部データ構造とストレージメカニズムについて興味があります。Oracleでは、SDOインデックスが「単なる別のテーブル」であり、レベルがインデックスの属性であり、インデックス付きジオメトリのbboxがblob（抽出可能）として格納されている方法を示すのが好きでした。postgisはインデックスをどのように保存しますか？ システムテーブルhttp://www.postgresql.org/docs/8.3/static/catalogs.htmlを使用してインデックスを識別できますが、実際のストレージにアクセスする方法がわかりません（実際にテーブルである場合）

13 postgis  postgresql  spatial-index 

RTreeでの空間インデックスの使用を理解できません。 例：300個のバッファーポイントがあり、各バッファーの交差領域とポリゴンシェープファイルを知る必要があります。ポリゴンシェープファイルには、20,000を超えるポリゴンがあります。プロセスを高速化するために空間インデックスを使用することが提案されました。 SO ...ポリゴンシェープファイルの空間インデックスを作成する場合、何らかの方法でファイルに「アタッチ」されますか、それともインデックスはスタンドアロンですか？つまり、作成後、ポリゴンファイルで交差関数を実行するだけで、より高速な結果を得ることができますか？交差点は空間インデックスがあることを「認識」し、何をすべきかを知っていますか？または、インデックスで実行してから、FIDなどを介して元のポリゴンファイルにそれらの結果を関連付ける必要がありますか？ RTreeのドキュメントはあまり役に立ちません（おそらくプログラミングを学んでいるだけだからです）。手動で作成されたポイントを読み取り、それから他の手動で作成されたポイントに対してクエリを実行して、ウィンドウ内に含まれるIDを返すことにより、インデックスを作成する方法を示します。理にかなっています。しかし、インデックスの元のファイルにどのように関連するかについては説明していません。 私はそれがこのような何かに行かなければならないと考えています： ポリゴンシェープファイルから各ポリゴンフィーチャのbboxを取得し、空間インデックスに配置して、シェープファイル内のIDと同じIDを与えます。 そのインデックスをクエリして、交差するIDを取得します。 次に、インデックスのクエリによって特定された元のシェープファイル内のフィーチャのみで交差を再実行します（この最後の部分をどのように行うかはわかりません）。 正しいアイデアはありますか？私は何かが欠けていますか？ 現在、このコードを、1つのポイントフィーチャのみを含む1つのポイントシェープファイルと、20,000個以上のポリゴンフィーチャを含む1つのポリゴンシェープファイルで動作するようにしています。 Fionaを使用してシェープファイルをインポートし、RTreeを使用して空間インデックスを追加し、Shapelyを使用して交差を試みています。 私のテストコードは次のようになります。 #point shapefile representing location of desired focal statistic traps = fiona.open('single_pt_speed_test.shp', 'r') #polygon shapefile representing land cover of interest gl = MultiPolygon([shape(pol['geometry']) for pol in fiona.open('class3_aa.shp', 'r')]) #search area areaKM2 = 20 #create empty spatial index idx …

13 python  shapely  fiona  spatial-index  rtree 

これがより良いフォーラムであると示唆されたとき、Stack Overflowで尋ねられた質問の再投稿。 私は、地理空間ではないが非常によく適合するデータセットをプッシュするために少し実験を試みていますが、結果はやや不安定です。データセットはゲノムデータです。たとえば、遺伝子などの要素が特定の開始座標と停止座標（X軸）を占めるDNA領域があるHuman Genomeです。Y軸を占めるDNAの複数の領域（染色体）があります。目標は、単一のY座標に沿って2つのX座標と交差するすべてのアイテム、たとえばLineString（START 1、END 2）を戻すことです。 理論は健全に思えたので、既存のMySQLベースのゲノムプロジェクトにそれをプッシュし、次のようなテーブル構造を思い付きました。 CREATE TABLE `spatial_feature` ( `spatial_feature_id` int(10) unsigned NOT NULL AUTO_INCREMENT, `external_id` int(10) unsigned NOT NULL, `external_type` int(3) unsigned NOT NULL, `location` geometry NOT NULL, PRIMARY KEY (`spatial_feature_id`), SPATIAL KEY `sf_location_idx` (`location`) ) ENGINE=MyISAM; external_idこのテーブルにエンコードしたエンティティの識別子を表し、このexternal_typeソースをエンコードします。すべてが順調に見えたので、いくつかの予備データ（30,000行）を入力しましたが、これはうまくいくようです。これが300万行のマークを超えて増加すると、MySQLは空間インデックスの使用を拒否し、使用を強制されたときに遅くなりました（40秒対全テーブルスキャンを使用した5秒）。さらにデータが追加されると、インデックスの使用が開始されましたが、パフォーマンスの低下が続きました。インデックスを強制的にオフにすると、クエリは8秒になりました。私が使用しているクエリは次のようになります。 select count(*) from spatial_feature where MBRIntersects(GeomFromText('LineString(7420023 1, 7420023 1)'), …

13 performance  spatial-index  optimization  mysql-spatial 

浸透スキーマを使用して、オランダのOpenStreetMapデータをPostGISデータベース（PostgreSQL 8.3 / PostGIS 1.3.3）にロードしました。これは、すべてのタグがhstoreフィールドに保存されることを意味します。浸透がジオメトリフィールドに作成するGISTインデックスに加えて、タグフィールドに追加のGISTインデックスを作成しました。 空間制約とタグフィールドの制約の両方を使用してクエリを実行しようとすると、思ったよりも遅いことがわかりました。このようなクエリ： SELECT n.geom,n.tags,n.tstamp,u.name FROM nodes AS n INNER JOIN users AS u ON n.user_id = u.id WHERE tags->'man_made'='surveillance' AND ST_Within(geom, ST_GeomFromText('POLYGON((4.0 52.0,5.0 52.0,5.0 53.0,4.0 53.0,4.0 52.0))',4326)); 78レコードを返すのに22秒かかります。 このテーブルには、約5,300万件のレコードがあります。 これを大幅にスピードアップする方法はありますか？PostgreSQL 9でhstoreの実装が大幅に改善されたと聞いたことがありますが、アップグレードは役に立ちますか？

12 postgis  openstreetmap  postgresql  spatial-index  optimization 

最も単純なクエリでも、PostgreSQL 9.3.5でPostGIS 2.1を実行して空間インデックスを使用できません。データセット全体800万ポイント（ここから人口数グリッド）です。テーブルは次のように作成されます CREATE TABLE points ( population DOUBLE PRECISION NOT NULL, location GEOGRAPHY(4326, POINT) NOT NULL ) CREATE INDEX points_gix ON points USING GIST(location); クエリは取得するのと同じくらい簡単です SELECT SUM(population) FROM points WHERE ST_Distance( location, ST_GeographyFromText('SRID=4326; POINT(0 0)') ) < 1000 PostgreSQLは常にSeqスキャンを使用します。私は10000ポイントのサブセットを試しました-まだSeqスキャンです。何か案は？

10 postgis  postgresql  spatial-index  st-distance  st-dwithin 

Qgis APIを使用して、いくつかのシェープファイルの空間インデックスを作成しようとしています。Nathan Woodrowのブログ（https://nathanw.net/2013/01/04/using-a-qgis-spatial-index-to-speed-up-your-code/）で説明されている手順を実行しました。： layer = QgsVectorLayer(path, name, 'ogr') idx = QgsSpatialIndex() all_features = layer.getFeatures() map(idx.insertFeature, all_features) 私の問題は、結果のファイルがないことです（.qix？.sbn？.sbx？） この空間インデックスを保存して、シェープファイルの将来のユーザーがそれを利用できるようにするにはどうすればよいですか？

9 qgis  pyqgis  spatial-index 

PyQGISクックブックは、空間インデックスを設定する方法について説明しますが、それは唯一のその用法の半分を説明します。 空間インデックスの作成—次のコードは空のインデックスを作成します index = QgsSpatialIndex() インデックスに機能を追加—インデックスはQgsFeatureオブジェクトを受け取り、それを内部データ構造に追加します。オブジェクトを手動で作成するか、プロバイダーのnextFeature（）への以前の呼び出しからのオブジェクトを使用できます index.insertFeature(feat) 空間インデックスにいくつかの値が入力されると、いくつかのクエリを実行できます # returns array of feature IDs of five nearest features nearest = index.nearestNeighbor(QgsPoint(25.4, 12.7), 5) 返された機能IDに属する実際の機能を取得する最も効率的な手順は何ですか？

9 qgis  pyqgis  spatial-index 

SPIT（QGISプラグイン）を使用して多数のシェープファイルをPostGISデータベースにロードしました。これらのレイヤーには、読み込み時に作成される空間インデックスがありませんでした。各レイヤーのクエリを記述せずにスキーマの各レイヤーの空間インデックスを作成する方法があるかどうか疑問に思っています。私は良いPostGISスクリプトライターではないので、どんな助けでも大歓迎です。 ありがとう

9 postgis  spatial-index 

これが私の最初の質問です。ご容赦ください。 私は、近くのPOI（ポイントosインタレスト）を見つけるために近接検索を行う必要があるモバイルアプリのバックエンドを実装しています。私はそれが非常に一般的なシナリオであり、非常にシンプルに見えることを知っていますが、実装できる方法はたくさんあるので、経験豊富な専門家がこれらの単純な空間検索をどのように実装しているかを確認したいと思います。 POIは単なるPOINTなので、交差点などを含む複雑な計算は必要ありません。そのため、最初に、GEOGRAPHY列と空間インデックスを使用すると、他の方法よりもやり過ぎになるか、遅くなる可能性があると考えました。だから私はそれを3つのアプローチに絞り込んだ： 1）GEOGRAPHYカラム+空間インデックス これはおそらく、この問題の事実上の解決策です。空間インデックスと地理列があるので、それを使用して距離で検索できます。このようなもの。 SELECT * FROM POIs WHERE Loc.STDistance(@radius) <= @distance; Locには空間インデックスがあるため、非常に高速です。 2）緯度と経度の列に「境界ボックス」を使用する これは、空間インデックスを使用しない簡単なアプローチです。ポイントと半径の境界ボックスを見つけて、単にLatitude列とLongitude列を検索します。両方にインデックスが付けられている場合、この検索は非常に高速になります。距離関数を適用して、「円」の外側のいくつかの値をフィルタリングする必要がありますが、バウンディングボックスを通過しません。しかし、それはかなり速いはずです。このアイデアはここでよりよく説明されています：http : //www.movable-type.co.uk/scripts/latlong-db.html このようなもの： DECLARE @lat float DECLARE @lon float SET @lat = -23.001029 SET @lon = -43.328422 DECLARE @maxLat float, @minLat float, @maxlon float, @minLon float DECLARE @R float DECLARE @distance FLOAT = 100 …

8 sql-server  spatial-index  proximity  geohash 

QuadKey Bingマップは、タイルスキーマにクワッドキー構造を使用します。ここでは、http：//msdn.microsoft.com/en-us/library/bb259689.aspxの概念の概要を示します。 GeoHash geohashは、オープンソースワードhttp://en.wikipedia.org/wiki/Geohashで受け入れられている表現のようです 。 ですから、空間インデックスとして使用する場合、2つの間にトレードオフがあるかと思います。どちらもクワッドツリーコンセプトに根ざし、長所と短所がありますが、どちらを使用してもメリットはありますか？

8 bing-maps  spatial-index  geohash  quadtree 

アプリケーションがそれらのサブセットのみをマップに表示し、テーブル全体をマップしない場合に、テーブルのサブセットに空間インデックスを作成することは良いアイデアであるかどうかフォーラムに尋ねていました。 サブセットにはテーブル全体の同じ範囲がないため、独自の空間インデックスを使用してサブセットを表示する方が高速になる可能性があるためです。 私が受け取った答えは、空間インデックスは表示時間に影響を与えず、結合や交差などの空間クエリにのみ使用されるというものでした。それは本当ですか??? GISとデータベースの私の経験は、テーブルに空間インデックスがない場合、マップでの表示がはるかに遅くなることです。ディスプレイでは、現在のマップウィンドウの範囲と交差するフィーチャを表示するためにテーブルにクエリが実行されるため、外部のフィーチャは何も読み込まれません。それは本当にそれがどのように機能するのですか？これは一種の空間クエリです。 真実は何？サブセットに空間インデックスを作成することは良い考えですか？

8 spatial-database  database  spatial-index