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

ラスターをポリゴンに変換するオープンソースのPythonソリューションを探しています（ArcPyは使用しません）。 ラスターをポリゴンに変換するGDAL関数を知っていました。これはマニュアルです：http : //pcjericks.github.io/py-gdalogr-cookbook/raster_layers.html#polygonize-a-raster-band それにもかかわらず、出力はファイルとして保存されず、一時的にメモリ内にある、形の良いポリゴンまたは任意のオブジェクトになる可能性があります。この問題を処理するパッケージまたはコードはありますか？ ラスターがnumpy配列で処理されている場合、アプローチは以下のとおりです。

13 python-2.7  shapely  polygonize 

OSGEO4WインストーラーからQGIS 2.14.6 64Bitをインストールしました。処理拡張機能のバージョンは2.12.99です。スクリーンショットに示されているように、Polygonizeツールにアクセスするために通常どおり「高度なインターフェイス」に切り替えることができません（Lines to Polygonsはまだ機能しません。cp。QGIS 2.12 Lines to Polygonsは正しく機能しません）。 同じインストールを別のマシンで並行して実行すると、Processing Plugin Version 2.10.3が実行されます。ここで、高度なインターフェイスに切り替えてPolygonizeツールにアクセスできます。 追加/更新： 完全に混乱：スタンドアロンインストーラーからインストールされた2.14.5では、処理プラグインのバージョンも2.12.99ですが、ここではPolyonizeツールにアクセスできます。 これまでの研究努力：私は、ケース2でusername\.qgis2\python\plugins\コアプラグインの異常なパスの下に処理プラグインがインストールされていることに気付きました。明らかに（または多分？）問題は、処理がコアプラグインになる前のQGISの以前のインストールであるため、ここのプラグインはコアプラグインをオーバーライドするようです。これは、2のプラグインが更新の影響を受けない理由も説明します（処理はコアプラグインであるため、リポジトリでは使用できません）。解決策は、単にプラグインをアンインストールし、QGISを再起動することでした。コアプラグインバージョン2.12.99が利用可能です。注目すべき点：Polygonizeツールは引き続き使用できます（ケース1とは異なります）。ここまでは順調ですね。 まとめると： 3つのケースすべてで、処理プラグインのバージョンは2.12.99です。 OSGeo4Wインストーラー、Polygonizeツールなし OSGeo4Wインストーラー、Polygonize利用可能なツール スタンドアロンインストーラー、Polygonize利用可能なツール では、ケース1の問題は何でしょうか？OSGeo4Wインストーラーで何かを見逃しましたか？

10 qgis  qgis-processing  polygonize  user-interface 

私は現在、等時性と基礎となるアルゴリズムの分野で働いています。現在問題となっているのは、等時線自体の場合の計算ではなく、結果の視覚化です。 私の等時線アルゴリズムの結果は、ポイントとエッジです。実際、私には有効なソリューションがありますが、3873エッジと1529ノードの場合、時間がかかるようです（2015 Core i7 CPUとかなり高速なSSDを含むLenovo T440sラップトップでは約2.0秒）。秒の代わりに、msec :-)のようなものがもっと欲しいです。 たぶん誰かが、到達可能な領域を視覚化するポリゴンを構築するのに必要な計算時間を短縮するのを手伝ってくれるでしょう。 しかし、待ってください...まず最初に！ これは、私の等時線の計算結果であるエッジの視覚化です。 これらのエッジはPostGISデータベーステーブルに格納され、単純な線ストリングです。 ユーザーに見せたいのは次のようなもの です。画像の最南端と最東端にある切断された領域に注意してください。これらは個別の領域として描画する必要があります（したがって、ここではマージできません:-)） 現在、私はこのクエリを使用しています： SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM ( SELECT ST_MakePolygon(ST_ExteriorRing(ST_GeometryN(segments, generate_series(1, ST_NumGeometries(segments))))) AS polygons FROM ( SELECT ST_Union(ST_Buffer("GEOMETRY", 20, 'quad_segs=2')) AS segments FROM my_edges AS a ) AS b ) AS c 私はすでにいくつかの実験を行っており、多くのドキュメントも読みましたが、より良い解決策を見つけることができません。 私の目には、大きな問題はST_Unionの使用です（ドキュメントで述べられているように、この関数は遅くなる可能性があります）。非常に興味深いのは、それをST_Collectで置き換えると、ST_Bufferの計算が遅くなるように見えるため、次のクエリのオールインオールがさらに長くかかりますが、エッジ間の領域は埋められません（ラインの周りにバッファーが作成されるだけです） ）： SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), …

10 postgis  postgis-2.0  polygonize 

これは、すでに別の目的のために頼まれた、シンプルで非常に一般的な質問です（参照このリンクをし、これも、例えば）、ここでは、しかし、私たちは、探しているではないソフトウェアパッケージが、アルゴリズム我々が言う実装しようとすることができていることPython。 したがって、以下に示すように、一連の線がマップされます（これらは既にトリミングされていますが、BTW）。 ポリゴンを生成するためのアルゴリズム/アイデア（赤いものを示しています）？

10 algorithm  polygonize  geometry-conversion 

を使用してPyQGISでポリラインレイヤーをポリゴン化しようとしている間 processing.runandload("qgis:linestopolygons",explode_path,polygon_path) Pythonコンソールのコマンドでは、ラインエッジに対応するポリゴンは作成されません。代わりに、カーブしたエッジに沿って小さなポリゴンを作成します。ポリゴンがラインエッジに沿って作成されないのはなぜですか？ ポリゴン化では、黒い線は作成されたポリゴンのエッジであると想定されます。代わりに、カーブしたエッジ（青いポリゴン）に沿って作成されるスライバーはほとんどありません。

9 pyqgis  qgis-processing  polygonize 

PythonスクリプトでGDALPolygonize（）を使用してラスターをポリゴン化しようとしています。スクリプトは、昨日の午後5時にポリゴン化を開始し、現在も午前9時30分にポリゴン化しています。どれだけ進んでいるかはわかりませんが、Windowsエクスプローラーを更新すると、出力シェープファイルのファイルサイズの変化を確認できるので、まだ進んでいることがわかります。 私のラスターはかなり大きいですが、それでもそれほど長くかかるとは思いません。私のラスターは35,486列、23,682行で、セルサイズは1メートルです。これは、値1がデータを表し、0がNoDataのバイナリラスタです。 ArcGISで、Conversion ToolboxのRaster to Polygonを使用してポリゴン化した場合、56秒かかりました。結果のシェープファイルは200MBですが、GDALPolygonizeによってまだ作成されているシェープファイルはまだ100MBしかありません。そのため、GDALは終夜実行した後、半分ほどの作業が完了したと思います。 仕様：Windows 7 64ビット、8 GB RAM、GDAL 1.10 64ビット、ArcGIS Desktop 10.2、64ビットバックグラウンドジオプロセシングfor ArcGISデスクトップ、Python 2.7.3 64ビット 更新 2日目-GDALPolygonizeはまだ実行中です。それは一晩で2晩続けて、終わらなかった。ArcGISは56秒かかりました。

9 python  gdal  polygonize