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

2つのUTMゾーンGDA / MGA94 UTMゾーン55および56にまたがるデータがあります。地籍、道路、パイプラインなどのレイヤーがあり、長さや面積などの測定値をメートルまたは何らかのメトリック表記で保存します。度！ PostGISでこれを管理する最良の方法は何ですか（私はPostGreSQL 8.4 PostGIS 1.5を使用しています）？データをGDA94地理座標として保存し、何らかの回避策を使用して必要な測定値を計算する必要がありますか？または、これを処理する別の方法がありますか？

27 postgis  coordinate-system 

現在、EC2でインスタンスを構築しています。このインスタンスで、現在取り組んでいるいくつかのプロジェクトの地球全体のデータのPlanet.osmスナップショット全体をインポートします。大規模なUbuntu x64インスタンスをスピンアップし、Postgresデータベース用にEBSボリュームに多数の個別のストレージを接続し、PGSQLデータを格納するように変更しました。 現在、サーバーはosm2pgsqlスナップショットのインポートに問題があります...さまざまなメモリ構成などで2、3回試行した後、プロセスはほとんどの処理を行った後「Kill​​ed」を出力し続けます。「保留中のウェイを通過中」に削除され、次回、スリムキャッシュをわずかに調整した後、クラッシュする前に「処理中のウェイ」に到達しました。私が読んだことから、これは一般的にメモリの問題によるものです。 インポートを実行する私の最新の試みは次のとおりです。 osm2pgsql -v -U osm -s -C 4096 -S default.style -d osm /data/osm/planet-latest.osm.bz2 そして、EC2のLargeインスタンスの仕様は次のとおりです。 ラージインスタンス7.5 GBのメモリ、4つのEC2コンピューティングユニット（それぞれ2つのEC2コンピューティングユニットを備えた2つの仮想コア）、850 GBのローカルインスタンスストレージ、64ビットプラットフォーム 私の質問です-osm2pgsqlとPostgresのチューニング要件を決定するための良いベンチマークリソースはありますか？インポートの速度はそれほど重要ではありません。4〜5日かかる場合でも、プロセスが安全に完了することを確認できるようにしたいと思います。フレデリックラムの「レンダリングの最適化」を読みました。チェーン」（昨年のSOTMからの（PDF）ドキュメントですが、他にも良い意見/リソースはありますか？

27 postgis  openstreetmap  postgresql  mapnik  optimization 

ユニットが何から返されているフロートののかしらST_Distance。 ドキュメントには次のように書かれています： ...投影された単位の2つのジオメトリ間のデカルト最小距離（空間参照に基づく）。 これらの予測単位は何ですか？ ジオメトリは次のフィールドに保存されますgeometry(Point,4326)。

24 postgis  postgis-2.0 

グライダーパイロットからは、一定の間隔でGPSを修正するという形で多くのフライトデータを取得しています。飛行経路を分析し、グライダーのパイロットがサーマルを見つけたときに行う「旋回」の開始と終了を検出したいと思います。 理想的には、アルゴリズムは線上の開始点と終了点を与え、1つの「円」を定義します。これらのポイントは、GPS修正の1つと等しくなる可能性があり、補間する必要はありません。 飛行経路に沿って歩き、回転数を確認し、グライダーが旋回しているかどうかを判断するための基準を設定することができました。 PostGIS拡張機能を備えたPostgreSQLを使用しているため、この問題に対するより良いアプローチがあるかどうか興味がありました。私はすでに2つの線分の角度を計算する手順を持っています： CREATE OR REPLACE FUNCTION angle_between( _p1 GEOMETRY(PointZ,4326), _p2 GEOMETRY(PointZ,4326), _p3 GEOMETRY(PointZ,4326) ) RETURNS DECIMAL AS $$ DECLARE az1 FLOAT; az3 FLOAT; BEGIN az1 = st_azimuth(_p2,_p1); az3 = st_azimuth(_p2,_p3); IF az3 > az1 THEN RETURN ( degrees(az3 - az1)::decimal - 180 ); ELSE RETURN ( degrees(az3 - …

24 postgis  postgresql  algorithm  trajectory 

PostGISで新しいデータベースを作成したいので、現在のデータベースが使用されている間にそれをロードできます。ドキュメントによると PostGISのパッケージ化されたディストリビューション（特にPostGIS 1.1.5以降のWin32インストーラー）は、PostGIS関数をtemplate_postgisと呼ばれるテンプレートデータベースにロードします。PostgreSQLインストールにtemplate_postgisデータベースが存在する場合、ユーザーやアプリケーションは、単一のコマンドを使用して空間的に有効化されたデータベースを作成できます。 私の場合、これはそうではないようです： $ createdb -T template_postgis my_spatial_db createdb: database creation failed: ERROR: template database "template_postgis" does not exist 過去には、プライマリgisデータベースをコピーしてから、すべてのテーブルの内容を削除することをいじりました。より良い方法がなければなりません。誤ってドロップした場合はどうしますか？

24 postgis  postgresql  database  create 

地理的特徴（ライン、ポリゴン、およびそれらの同等のマルチパート）がantimeridian（±180°経度）にまたがり、GeoJSONとしてクライアントWebアプリケーションに送信および受信する必要がある場合、それらを保存するためのベストプラクティスは何ですか？ 私は、Postgres / PostGISデータベースのサポートを受けて、サーバー側のWeb APIで作業を開始し、熱帯低気圧の履歴と風の半径を予測します。太平洋の多くのサイクロンは、時には寿命の間に複数回、反時計回りを通過する不幸な傾向があります。 ニュージーランドのアンティリディアンの近くに住んでいる私は、地域のデータでこの問題に何度も対処し、対処戦略を立てましたが、実際にベストプラクティスと考えられるものを見つけたいと思います。残念ながら、antimeridianでタグ付けされた既存の質問はないため、関連する質問を検索するのは困難です。私がこの問題に苦労しているのを見た質問はすべて、非常にアプリケーション固有のアドバイスを求めているようです。この質問では、境界のない地球に広がるGeoJSONポリゴンの場合の反時計回りについて簡単に説明します。この質問は、私が尋ねていることにかなり近いものです。 空間的データベースに歴史的サイクロンと予測サイクロンを保存する必要がありますが、反時計回りに問題があると予想しています。たとえば、緯度/経度(0,179)で始まり、で終わる線(0,-179)は、その方向に関してあいまいです。それは、反時計回りを横切る短い経路を取るか、惑星全体を「包む」かです。このようなパスを空間データベースにどのように保存する必要がありますか（具体的には私はPostGISを使用していますが、ソリューションが十分に汎用的であることを望みます）。私が持っているいくつかのアイデア： フィーチャジオメトリに変更を加えず、クライアントアプリケーションへの曖昧さをシフトします。 antimeridianを横切るフィーチャを、antimeridianでブレークするマルチパートジオメトリに分割します。（GeoJSON仕様は名前付きCRSをサポートしています。） 仕事以外のグローバル予測などの不連続を持っていない別のサイクロン流域や海洋地域のために サイクロンが惑星全体を巡回することが一度も観察されていないという事実を利用して(90,-90) 、360°の位相でオフセットされた緯度範囲から始まるサイクロンの座標を保存します（他の-180-180°を維持） サイクロンがアフリカの南端の南にある可能性が非常に低いという事実を利用して、経度30°でブレークを使用します（上記のマップのように）。 座標がEPSG 4326の有効範囲を超えて拡張できるようにします。たとえば、反時計回りを通過するすべてのフィーチャに対して、180度以上-180度未満です。 TopoJSONと同様に、デルタエンコーディング（例：で始まり(0,-179)、次の座標は-3緯度西です）。PostGISにデータを保存するときにこれを実装するかどうか、または実装する方法がわかりませんが、これはクライアントアプリケーションにデータを送信するための優れたソリューションです。 何らかの形式のベクトル表記または極座標。（かなり難しくて珍しいようです。） これらのうち、アイデア2〜5は一般的なものではないので好きではありませんが、私の特定のアプリケーションにとって意味があるので好きです。太平洋のデータのみを処理するアプリケーションの場合、それらは非常に理にかなっている可能性があるため、オプションとして完全に割引したくはありません。 アイデア6および7は、Tom MacWrightのブログから取り上げられました。このブログは読む価値はありますが、反時計回りに関しては決定的なものではありません。 アイデア4はGeographicaGS 'GeodesicLinesToGISPythonによって使用されfiona.transform.transform_geom、360°の反時計回りオフセットで使用されています。次に、FionaはOGRを使用してい-wrapdatelineます。これは非常に堅実な先例であり、実際にはかなり一般的だと思います。 ストレージの問題に関連して、そのような機能をクライアントアプリケーションに送信する方法、およびアプリケーションがそこにポストバックされるデータを考慮する方法を検討する必要があります（たとえば、太平洋のサイクロンの予測トラックを変更する人間予報士）。交換形式はおそらくGeoJSONになりますが、そうである必要はありません。 残念ながら、GeoJSON仕様は、反時計回りの問題について明示的ではありません。ウィキペディアからこれ： 多くの地理的ソフトウェアライブラリまたはデータ形式は、世界を長方形に投影します。多くの場合、この長方形は180番目の子午線で正確に分割されます。これにより、180番目の子午線上で単純なタスク（エリアやラインを表すなど）を実行できなくなることがよくあります。いくつかの例： GeoJSON仕様では、仕様で180番目の子午線の処理に言及していないため、180番目の子午線を横切る線の表現は、世界中を回っていると解釈できます。 OpenStreetMapでは、領域（ロシアの境界など）は180番目の子午線で分割されます。 私の読書では、GeoJSONには反時計回りに広がる特徴の特定の標準表現はなく、意図的に曖昧なままになっています（マルチパートジオメトリによって問題が解決される可能性があります）。同様に、OpenStreetMapにはantimeridianにジオメトリ分割がありますが、そのような分割されたフィーチャがマルチパートであるか、実際に個別のレコードであるかはわかりません。 これは、特にバウンディングボックスまたはこの行にまたがる他の空間要求を作成するという観点からだけでなく、入力の解析とサニタイズおよびフィーチャジオメトリの更新においても、かなり問題があります。これが、私が従うことができるベストプラクティスを決定しようとしている理由です。

24 postgis  geojson  api  antimeridian 

次の問題に直面しています。OracleデータベースからPostgreSQL + PostGISに移行する必要があります。現在、すべてのタイプのすべてのジオメトリが1つのテーブルに格納され、各レコードには同じレイヤーのフィーチャを示す「lid」フィールドが含まれています。 そのような方法を使用することの長所と短所は何ですか？データベースをサードパーティのソフトウェアで使用する必要がない場合、データを複数のテーブルに分割する必要がありますか？空間クエリのパフォーマンスはどうですか？インデックスは役立ちますか？

24 postgis  spatial-database  postgresql  storage 

PostGISデータベースにロードしたい7GBのGeoJsonファイルがあります。私はogr2ogrを使用しようとしましたが、ファイルが大きすぎてogr2ogrがメモリにロードして処理できないため、失敗します。 このgeojsonファイルをPostGISに読み込む他の方法はありますか？ 私が得るogr2ogrエラーは次のとおりです。 エラー2：CPLMalloc（）：メモリ不足-611145182バイトを割り当てています。このアプリケーションは、ランタイムに異常な方法で終了するように要求しました。詳細については、アプリケーションのサポートチームにお問い合わせください。

24 postgis  convert  geojson 

PostGISでビューを作成するときに、そのビューに一意のIDを追加する方法はありますか？他のPostGISテーブルの「gid」フィールドと同じように？ 編集：申し訳ありませんが、元の投稿にこれを含めるべきでした。PostGresql 9.0およびPostGIS 1.5を使用しています。 安藤

24 postgis  postgresql 

ネットワークグラフがあり、エッジの数を減らすという意味で単純化する必要があります。アイデアは、近くにあるノードをマージし、接続している短いエッジを削除することです。 PostGISまたはGRASSでこれをどのように達成できますか？または、このようなネットワークを自動的に簡素化するためのより良いアプローチはありますか？ 既にST_SnapToGrid関数を試しましたが、結果に満足できません（グレー=オリジナル、黒=スナップ）：

24 postgis  grass  network  simplify 

隣接するポリゴンのセットを単純化する問題が発生しました。Douglas–Peuckerアルゴリズム（多くのオープンソースツールで使用）を使用して各ポリゴンを個別に単純化すると、通常、結果のポリゴンは隣接しなくなります。この問題は、たとえば、国/県の国境を簡素化するときに存在します。 誰かがPostGISを使用して解決策を持っていますか？

24 postgis  simplify  adjacency 

現在、PostGISトポロジ拡張を使用していますが、構造がどのように機能するかを理解するのは困難です。 重要なポイントの1つは「レイヤー」の使用です。私が理解しているように、フィーチャ属性はトポロジのスキーマ（という名前のスキーマtopo_actualname）からテーブルに保存し、そのトポロジのレイヤーとしてに登録する必要がありAddTopoGeometryColumnます。 しかし、それぞれの特徴（の要素を有する（層テーブルに格納された）属性を結合する簡単な方法がありnode、faceまたはedge_data）か？ 今、私がしていることは： SELECT whatever FROM layer_tb l JOIN topo_topologyname.edge_data e ON (l.topo).id=edge_id; しかしlayer、必要な情報を取得するためにトポロジスキーマ名とレイヤー名の両方を知る必要がある場合、概念全体はかなり役に立たないと思います。 実際、topoレイヤーの列にはそれぞれのトポロジがどこにあるかを知るのに十分な情報があり、さらにtopologyスキーマには各トポロジの各レイヤーテーブルへの参照が格納されていることを理解したと思います。 情報を結合するための短い/シンプル/適切な方法はありますか？トポロジ拡張機能で何かを探していましたが、有用なものが見つかりませんでした。

24 postgis  postgis-2.0  topology 

st_union（）の後、PgSQLは次のメモを返します。 NOTE: TopologyException: side location conflict at 226.001 39.5158 結果には、空のジオメトリを持つ2つの行があり、他の行は問題ありません。 その問題の原因は何ですか？解決方法は？

23 postgis  postgresql 

西ミシガン州の農場の場所を保存するWebアプリがあります。製品（「ブロッコリー」など）を検索すると、その製品を栽培しているすべての農場が表示されます。 現在、MySQLと三角法を使用して、ユーザーの場所と各ファームの場所の差を計算しています。それは悪い方法ではありませんが、やることが必要でした。 もうすぐやりたいことは、さまざまな地域のさまざまな製品の成長シーズンを計画することです。（たとえば、カリフォルニアではアボカドが特定の時期に成長しますが、オハイオ州では成長しないことを示したいと思います。） 私はこれが無制限で素朴な質問であることに気付きましたが、PostgreSQL / PostGISに切り替えてその空間機能を活用する価値があるでしょうか？

23 postgis  mysql-spatial 

私の質問は、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 …

23 qgis  postgis  postgresql  spatial-database  postgis-raster