タグ付けされた質問 「postgis」

現在、空間データコンポーネントを持つWebアプリケーションを構築しています。空間データの比較では、最初に特定のポイントを取得し、一致する重複した空間ポリゴンを返します。 そうは言っても、私たちのデータベースには、一般的なリレーショナルデータベースで見られるすべての典型的なものを含む他の多くのコンポーネントがあります。 私たちはプロジェクトで、使用するデータベースソリューションを選択する必要があります。 すべてのプロジェクトメンバーは、MySQLの実装と管理に精通していますが、すべての研究では、特にpostGISを使用した空間データに関して、PostgreSQLがより優れたソリューションであることが示唆されています。 私たちのアプリケーションが多くの同時ユーザーで多くのアクションを体験することを期待しています。 空間データコンポーネントを使用してRDBMSとしてMySQLを使用した経験がある人には、長期的なアドバイスや経験がありますか？ PostGISを使用することの不便さはありますか？

15 mysql  postgresql  spatial  postgis  feature-comparison 

だから私は最近新しい会社に着手し、顧客にデータを提供するためにPostGISインスタンスを進めたいと強く思っている多くのArcGISユーザーがいます。これについては問題ありませんが、私たちは95％がSQL Server、5％がOracleショップです。現在の内部GISはSQL Serverで実行されており、苦情はまだ聞いていません。 2012年の時点で、SQL Serverの空間/幾何学的機能が大幅に改善されていることは知っていますが、新しいプラットフォームに侵入する価値のあるPostGISのキラー機能はありますか？私はそれを研究しようとしましたが、真に詳細なものを見つけることができません、またはそれは完全に偏っていません。 私は彼らに彼らの仕事を成し遂げるための最高のツールを提供したいだけでなく、私が最初からPostgres / GISを学び、それがそれ自体の全体の旅であるという事実を考慮しなければなりません。

15 sql-server  database-recommendation  spatial  postgis 

大量の気象モデルデータをPostgreSQLデータベースに入れています。マシンには8つのコアと16 GBのRAMが搭載されています。PostGIS 2.1でPostgreSQL 9.3を実行しています。各テーブルには、さまざまな気象データ（気温、露点、風など）があります。各テーブルには6〜7列があります。緯度、経度、ポイントジオメトリ、標高、モデルが関連する日時、および対象となる1〜2のデータ値です。データは主に、時間と高度によって境界ボックスを照会されます。テーブルあたり約145,757,360行になります（現在より古いデータはもはや関係がなくなり、削除されます）。テーブルのサイズは、おおよそ、インデックスなしで約10 GBと推定されます。（これは、52バイトのデータと1行あたり23バイトのオーバーヘッドです）。新しいモデルデータが利用可能になると、データは定期的に更新/挿入されます。注意： だから私はこれらの2つの計画を見ています： ポイントジオメトリの追加のインデックスを使用して、（日時、標高）でインデックスを付けてクラスタ化するだけです。古い行を削除し、vacuum / analyzeを実行し、再クラスター化する通常のcronジョブを実行します。 日時でパーティション化し、ジオメトリのインデックスを持つテーブルごとに標高でクラスタ化してインデックス化します。通常のcronジョブを実行して、新しいテーブルを追加し、古いテーブルを削除します。 さらに、 したがって、テーブルを削除する方がはるかに効率的で、削除およびバキューム処理を行うことを知っています。しかし、それ以外の場合はパフォーマンスが向上しますか？ パーティションは、すべてのテーブルが均等に更新されて削除されるまで適切ではない場合に適切ですか（ドキュメントでは、一部のテーブルのみを選択した場合にパーティションが最適に機能することが示されています）？ データを配信する場合、選択はクラスター化インデックスよりも高速になりますか？複数のリクエストが一度に行われる場合、答えは変わりますか？ ありがとうございました。必要なデータをすべて入れてほしい。知らない場合はお知らせください。追加します。

12 postgresql  database-design  partitioning  postgis  postgresql-9.3 

テーブルplanet_osm_polygonをあるデータベースosmから別のデータベースにコピーしようとしていますtest。私su postgresと実行しましたpg_dump。 問題：ただし、エラーが発生could not change directory to "/root"し、Password:プロンプトが2回表示されます。pg_dumpとしてログインしたときにを実行する方法はありますrootか？ root@lalaland:~# su postgres postgres@lalaland:/root$ pg_dump -h localhost "osm" --table "public.planet_osm_polygon" | psql -h localhost "test" --table "staging.planet_osm_polygon" could not change directory to "/root" could not change directory to "/root" Password: Password: 更新 問題＃2：publicフラグを渡したにもかかわらず、テーブルがスキーマにコピーされているようです--table="staging.planet_osm_polygon"。なぜスキーマにコピーされないのstagingですか？

12 postgresql  postgresql-9.1  postgis 

5万行のテーブルがあります。これは実際にはPostGISテーブルです。 クエリには4つの部分があります（1つは必須）（3つはオプション） 緯度と経度が4の交差ボックス（地理長方形）（st_intersectsを使用）[必須] 日付フィールドの日付範囲（最小、最大） 現在IN（.....）を使用しているファイルタイプ（最大8つのテキスト値のセット）ですが、必要に応じて一時テーブルにすることができます。INが嫌いな人が多いようです。 国（テキスト値）。 返される行は約100〜4,000になると思います テーブルに複合インデックスを作成する場合、最初にどの列を使用する必要がありますか。きめ細かいのはおそらく場所です（データは世界中に広がっています）。現在、GISTインデックスとして持っています。 他のインデックスはBTREEです。 私の直感は、きめ細かい、そして最後にコースを使用すると言います。たとえば、ファイルタイプは約12しかないため、インデックスのバケットは非常に大きくなります。 PostgreSQLとPostGISの達人（システムの内部を知っている人）は何と言っていますか？ 更新： この質問をもっとはっきりさせましょう。 やるべきことを誰かにやらせてもらいたくない。あなたの時間を尊重しすぎます。ですから、後で説明の分析に行きます。 私が探していたのは、いくつかの指針とヒント、およびガイドラインだけでした。 私はこの優れた小さな投稿を読みました：https : //devcenter.heroku.com/articles/postgresql-indexes#managing-and-maintaining-indexesインデックスについて 私が通常行うことは、4つの個別のインデックス（ジオボックス、国名、file_type、および日付）を作成することですが、複合クエリが何を行うかを確認したいのです。 これらの仮定のいずれかが間違っているかどうか教えてください。（私は複合インデックスのアイデアにかなり新しいです） 順序は重要です。最初のインデックスとして、行を最も削減するインデックスを選択します（私の場合、場所（地理）は単純なポリゴンまたはマルチポリゴンが最も効果的です）。 クエリはインデックスをスキップすることがあります。しかし、キー（＃1、＃2、＃3、＃4）を使用して複合クエリを作成した場合、ユーザーが＃1、＃3を要求するものを作成した場合でも、プランナーは単一の複合クエリを使用します。維持されている。 通常、3つのBTREEクエリと1つのGIST（地理タイプ用）を作成します。PostGISは、複数のインデックスタイプからの複合の作成をサポートしていません。したがって、GISTを複合インデックスとして使用する必要があります。しかし、それは物事を傷つけるべきではありません。 追加の複合インデックスまたは単一値インデックスを作成する場合、プランナーは最もインテリジェントなインデックスを選択するのに十分スマートです。 国名は約250の異なる値を持つことができ、明らかに場所（ジオボックス）に強くリンクされていますが、行サイズを削減するための次善のインデックスがfile_typeの場合は、次に使用する必要があります。ユーザーがクエリセットで国や日付を頻繁に使用するとは思わない。 4つのキーの複合インデックスを作成すると、インデックスデータのサイズが大幅に増加することを心配する必要はありません。つまり、1つのキーのインデックスがパフォーマンス向上の90％になる場合でも、さらに3つの項目を追加して複合させることは問題ありません。逆に、実際には両方のインデックスを作成する必要があります。単一の地理インデックスと複合インデックス。プランナーにどちらが最適かを判断させ、インデックステーブルのサイズを考慮します。 繰り返しになりますが、私は誰かに私のソリューションを設計するように頼んでいません。しかし、PostGreSQLドキュメントが実装について教えてくれないことが必要です [まだEXPLAIN結果を表示できないのは、24Mの行テーブルからこの25Kの行テーブルを作成する必要があるためです。思ったより時間がかかります。私はものを1,000個のアイテムグループにクラスター化し、ユーザーに25K行テーブルに対してクエリを実行させています。しかし、次の質問では、そのクエリの結果を使用してMASTER 25M行テーブルに移動し、物事を引き出します。これが、複合インデックスのパフォーマンスが実際にHITになる場所です。 以下のサンプルクエリ： SELECT public.product_list_meta_mv.cntry_name AS country, public.product_list_meta_mv.product_producer AS producer, public.product_list_meta_mv.product_name AS prod_name, public.product_list_meta_mv.product_type AS ptype, public.product_list_meta_mv.product_size AS size, ST_AsGeoJSON(public.product_list_meta_mv.the_geom, 10, 2) AS …

9 postgresql  postgis 

PostgreSQL 9.2では、地理（postGIS）タイプと整数の両方を複合インデックスとして持つインデックスを問題なく作成できました。しかし、現在（9.6）はインデックスの作成に不満を示しており、それが提供するヒントを理解できません。 列とデータはすべて適切に作成されていますが、Postgresは作成インデックスについて不平を言っています。 ERROR: data type integer has no default operator class for access method "gist" HINT: You must specify an operator class for the index or define a default operator class for the data type. ********** Error********** ERROR: data type integer has no default operator class for access method …

8 postgresql  postgis  postgresql-9.6 

非常に大きな（約320 GB）PostGISデータベースをserver1（PostgreSQL 9.1、PostGIS 1.5）からserver2（PostgreSQL 9.3、PostGIS 2.1）に移動してアップグレードする必要があります。 アップグレードプロセスは十分に文書化されています。問題は、server1にファイルをダンプしてチェックサムし、それをserver2にコピーして合計を確認するのに十分なスペースがないことです。私は試した： を使用して、server1からserver2にダンプをパイピングしますnc。 を使用してserver1にマウントされているserver2ファイルシステムに直接ダンプファイルを書き込む。sshfs どちらの場合も、ダンプファイルが破損しているようです。pg_restoreこのようなエラーで別の場所で壊れました： pg_restore: [compress_io] could not uncompress data: incorrect data check 誰かがこの移動とアップグレードを完了するためのより良い方法を提案できますか？ 更新： NFSを試してみました（そしてSSHFSにもう一度試してみました）。これらのリモートファイルシステムがこれだけのデータを確実に転送できないことは明らかです。結果のSQLファイルから明らかにブロックが欠落しているため、インポート中に次のような構文エラーが発生します。 ERROR: invalid input syntax for integer: "8266UPDATE spatial_ref_sys o set auth_name = n.auth_name, auth_srid = n.auth_srid, srtext = n.srtext, proj4text = n.proj4text FROM _pgis_restore_spatial_ref_sys n WHERE o.srid = …

8 postgresql  migration  postgis