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

スクリプト、アプリケーション、ソフトウェアなどのプロセスを改善または最適化する場合は、このタグを使用します。

3
GISデータベースに新しいルーティングアルゴリズム(ダイクストラ、A *より)はありますか?
Microsoftの研究者からのReach for A *や、カールスルーエUniからのSandersとSchtolz(名前を正しく綴った場合)によるHighway Hierarchiesなどの作品があります。どちらも計算順序を大幅に削減し、大きなグラフで千倍高速化します(リンクされたドキュメントの結果を参照)。後者の作業はオープンソースルーティングマシンにつながりましたが、残念ながら十分に普及しておらず、適応もしていません(一生懸命試しましたがコンパイルできませんでした)。 同時に、私が試したdbs、SpatialiteとPgRoutingは、彼らのドキュメントによると、DijkstraとA *アルゴリズムだけを提供しています。言及した双方向検索さえ見たことがなく、私の経験では計算時間を2回節約します。 データベースや他のアプリケーションのためのより良いアルゴリズムはありますか?

2
2億ポイントのPoint in Polygon分析の最速のソリューションを探しています[終了]
次の形式の2億の観測値を含むCSVがあります。 id,x1,y1,x2,y2,day,color 1,"-105.4652334","39.2586939","-105.4321296","39.2236632","Monday","Black" 2,"-105.3224523","39.1323299","-105.4439944","39.3352235","Tuesday","Green" 3,"-104.4233452","39.0234355","-105.4643990","39.1223435","Wednesday","Blue" 座標セット(x1 / y1およびx2 / y2)ごとに、それが含まれる米国国勢調査地区または国勢調査ブロックを割り当てたい(国勢調査地区TIGERシェープファイルをここからダウンロードした:ftp : //ftp2.census.gov/ geo / tiger / TIGER2011 / TRACT / tl_2011_08_tract.zip)。そのため、観測ごとにポリゴンのポイント操作を2回行う必要があります。一致が非常に正確であることが重要です。 ソフトウェアを習得する時間を含め、これを行う最も速い方法は何ですか?48GBのメモリを搭載したコンピューターにアクセスできます-これが関連する制約になる場合があります。 いくつかのスレッドは、PostGISまたはSpatialiteの使用を推奨しています(Spatialiteは使いやすいようですが、PostGISと同じくらい効率的ですか?)。これらが最良のオプションである場合、空間インデックス(RTree?)を設定することが必須ですか?もしそうなら、どのようにそれを行うのでしょうか(例:国勢調査シェープファイルの使用)サンプルコード(またはサンプルコードへのポインター)を含む推奨事項に非常に感謝します。 このサイトを見つける前の最初の試みは、ArcGISを使用して、米国国勢調査ブロックのデータのサブサンプル(100,000ポイント)の空間結合(x1 / y1のみ)を行うことでした。プロセスを強制終了するまでに5時間以上かかりました。40時間未満の計算時間でデータセット全体に実装できるソリューションを期待しています。 以前に尋ねられた質問をおApびします-私は答えを一読しましたが、どのように推奨事項を実装するのか疑問に思っています。私はSQL、Python、Cを使用したことがなく、ArcGISを使用したことが一度もありません-私は完全な初心者です。

6
ArcGISツールとして実行されるPythonスクリプトを高速化する方法[非公開]
これは非常に一般的な質問です。ツールボックスにインポートして実行するarcpyスクリプトを高速化するために、GISプログラマーがどのようなヒントとコツを使用したのかと思っています。 私はほとんど毎日、小さなスクリプトを書いて、オフィスの非GISユーザーがGISデータを処理できるようにしています。一般的に、ArcGIS 10.0の処理は9.3.1よりも遅く、Pythonスクリプトを実行するとさらに遅くなることがあります。 実行に24時間以上かかるスクリプトの特定の例をリストします。これは、バッファ内の各形状について、バッファ内のラスタの領域を集計するループです。バッファーには約7000の形状があります。私はそれがこれほど長く続くとは思わない。A while x <= layerRecords: arcpy.SetProgressorLabel("Tabulating Row: " + str(x) + " of " + str(ELClayerRecords)) arcpy.SelectLayerByAttribute_management(Buff,"NEW_SELECTION", "Recno = " + str(x)) # Selecting the record TabulateArea(Buff, "Recno", MatGRID, "VALUE", ScratchWS + "/tab" + str(z) +".dbf", nMatGRIDc) # Tabulate the area of the single row arcpy.AddMessage (" …

5
OSMデータのosm2pgsqlインポートの最適化
現在、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)ドキュメントですが、他にも良い意見/リソースはありますか?

7
ポイントCSVをポリゴンシェープファイルと空間的に結合する最速の方法
10億ポイントのCSVファイルと、約5,000のポリゴンを持つシェープファイルがあります。ポイントとポリゴンを空間的に結合する最速の方法は何ですか?各ポイントについて、包含ポリゴンIDを取得する必要があります。(ポリゴンは重なりません。) 通常、両方のデータセットをPostGISにロードします。より速く仕事を終わらせる方法はありますか? オープンソースのソリューションを探しています。

1
ポイントセット操作の代替インデックス方法
多数の機能を使用する場合、パフォーマンスを向上させるために、境界ボックス空間インデックスを使用するのが一般的です。多数の頂点を持つ個々のジオメトリに対して操作が実行される場合、同様の最適化戦略が存在しますか? たとえば、ポリゴンのポイントまたはユニオン操作を高速化できるデータ構造はありますか?

3
SQL Server 2008の7000万点のクラウドで最近傍クエリを最適化する
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] ) …

2
ArcPyを使用して関連レコードを効率的に選択しますか?
以下は、ArcMapの「関連テーブル」ボタンを複製するために使用しているコードです。ArcMapでは、そのボタンは、別の関連フィーチャクラスまたはテーブルのフィーチャの選択に基づいて、あるフィーチャクラスまたはテーブルのフィーチャを選択します。 ArcMapでは、そのボタンを使用して、選択を関連テーブルに数秒で「プッシュ」できます。ボタンを複製するarcpyに組み込まれたものを見つけることができなかったため、同じタスクを実行するためにいくつかのネストされたループを使用しました。 以下のコードは、「治療」のテーブルをループします。各処理について、「ツリー」のリストをループします。治療のIDフィールドとツリーの間で一致が見つかると、ツリーレイヤーで選択が行われます。治療に一致するものが見つかると、コードは追加の一致のためにツリーレイヤーを検索し続けません。処理テーブルに戻り、次の処理を選択して、再びツリーフィーチャクラスを検索します。 コード自体は正常に機能しますが、非常に遅くなります。この場合の「治療テーブル」には16,000レコードがあります。「ツリー」フィーチャクラスには60,000レコードがあります。 あるテーブルから別のテーブルに選択をプッシュするときに、ESRIが実行していることを再作成する別のより効率的な方法はありますか?テーブルのインデックスを作成する必要がありますか?注:このデータはSDEに保存されます。 # Create search cursor to loop through the treatments treatments = arcpy.SearchCursor(treatment_tv) treatment_field = "Facility_ID" for treatment in treatments: #Get ID of treatment treatment_ID = treatment.getValue(treatment_field) # Create search cursor for looping through the trees trees = arcpy.SearchCursor(tree_fl) tree_field = "FACILITYID" for tree in trees: …

3
スキャンした複数の紙のマップで色、明るさ、コントラストを均等にする方法
私は主にベクターの男ですが、現在のプロジェクトでは、スキャンした古い紙の地図(ロンドンの場合はww2爆弾被害マップ、興味があるなら!) マップをスキャンしてジオリファレンスし、Webサイトで提供するためのタイル合成レイヤーを作成したいと考えています。明らかに境界線を切り取りますが、ここでは問題ではありません。 問題は、マップシート間で見苦しい視覚的な色と明るさの違いがあることです。一貫性のある視覚的な外観を与えるためにそれらを均等化する方法について私は少し迷っています。ヒストグラムイコライズについて調べましたが、現在のツールボックス(Manifold GIS、GDAL、GeoServer)に必要な機能がないようです。 すでにジオリファレンスされた4つのスキャンの例:

3
MySQLで空間インデックスを使用するとパフォーマンスが低下する
これがより良いフォーラムであると示唆されたとき、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)'), …

2
セグメント間の距離に基づく線の集約
私が持っているVectorTileの私は(個々のタイルのサイズを小さくすることに取り組んで)、最適化していますことをベースマップを、タイルサイズの大きなチャンクは、道路データ(ジオメトリと属性)です。ズームレベルに基づいて個々の道路形状を単純化し、ズームレベルに基づいて道路を集約する作業を行っています。 道路はPostgisテーブル(各ズームレベルの個別のテーブル)に格納されており、表示されるズームレベルに基づいて道路を集約します。たとえば、ズームレベル5の表では、互いに一定の距離内にある道路を集約し、道路セグメントに対して1本の線を作成します。 そのズームレベルで個々の道路を作成することはできないため、 道路セグメント間の距離に基づいて道路ジオメトリを集約するにはどうすればよいですか? PS:LinuxでPostGISとQGISに取り組んでいますが、オープンソースのプラットフォームまたはテクノロジーを使用したソリューションにはオープンです。

1
インテリジェントな巡回セールスマンはいますか?
冗談はさておき、私はほとんど巡回セールスマンの問題(TSP)であるルーティングの問題がありました。 開始点が定義されています 終点は始点と一致します 各ノードを訪問する必要があります 総コストを最小限に抑える必要があります 2年前、TSPは完全に一致すると考えていたため、いくつかのサンプルデータをtsp_solveConcordeで実行しました。幸いなことに、TSPの最短パスが実際の最短パスではないことがすぐに明らかになりました。これは、ノードを一度だけ正確にアクセスすることを非現実的に要求することで問題が簡単になるためです。この図は、計算されたソリューションの最適化を1ステップで手動で試みたものであり、すでに使用されている最も長いエッジの距離を節約しています。 マッピング/監視サイトのサブセットへの最適なルートを見つけようとしているため、問題が表面化しました。ロケーションおよび道路ネットワークのデータは非常に正確かつ正確であるため、このような演習は理にかなっています。 TSPの一般化を見てきましたが、適切なアルゴリズムが見つかりませんでした。最小スパニングツリーは、ブランチからの戻りを考慮していません(ここでの最初の解決策にはさらに3つのコストがかかります)。私が理解していることから、最短経路の問題は最終的に2つのノードのみを考慮し、最適な経路から外れたノードは除外されます。車両のルーティングの問題の特殊なケースが最適であるように見えますが、それが非直接経路を考慮するかどうかはわかりません。 私の質問:この種の問題(家族)の定まった名前、定義はありますか?どのアルゴリズムとツールを使用して解決しますか? 計算量が多いと確信していますが、一般的な(無限のリソース)答えと実用的な答えの両方に興味があります。

5
OpenStreetMap PostGISクエリの高速化
浸透スキーマを使用して、オランダの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の実装が大幅に改善されたと聞いたことがありますが、アップグレードは役に立ちますか?

4
ST_Intersectionスロークエリ
2つのレイヤー間の交差を実行しようとしています。 一部の道路を表すポリラインレイヤー(最大5500行) さまざまなポイント(約47,000行)の周りの不規則な形状のバッファーを表すポリゴンレイヤー 最終的に、私がやろうとしているのは、ポリラインをこれらの多くの(場合によってはオーバーラップする)バッファーにクリップし、各バッファーに含まれる道路の全長を合計することです。 問題は、物事がゆっくり実行されていることです。これにどれくらい時間がかかるかはわかりませんが、34時間を超えるとクエリを中止しました。私は誰かが私のSQLクエリで間違いを犯した場所を指摘するか、これを行うより良い方法を教えてくれることを望んでいます。 CREATE TABLE clip_roads AS SELECT ST_Intersection(b.the_geom, z.the_geom) AS clip_geom, b.* FROM public."roads" b, public."buffer1KM" z WHERE ST_Intersects(b.the_geom, z.the_geom); CREATE INDEX "clip_roads_clip_geom_gist" ON "clip_roads" USING gist (clip_geom); CREATE TABLE buffer1km_join AS SELECT z.name, z.the_geom, sum(ST_Length(b.clip_geom)) AS sum_length_m FROM public."clip_roads" b, public."buffer1KM" z WHERE ST_Contains(z.the_geom, b.the_geom) GROUP …

4
Googleマップタイル作成プロセスのパフォーマンス
私は質問がかなり曖昧であることを知っていますが、w / meを負担してください。私は、Google / Bingマップタイルを作成するために使用したさまざまな方法論について、人々がどのような製品パフォーマンス(特にタイミング)を見てきたかを把握しようとしています。これを実行する方法は多数あります(gdal2tiles、FME、maptilerなど)。まともなLinuxサーバー上で、単に大きなPNGを取得し、imagemagickを使用してタイルを作成するという最初の試みでは、かなり長い処理時間が生じました。新しいタイルは少なくとも毎日生成する必要があるため、これに要する時間は非常に重要です。 唯一の実際の要件は、Linuxサーバーで実行できることです。明らかに、無料の方が良いのですが、私はそれだけに制限したくありません。入力には、生のグリッド/ラスターデータまたは大きな画像を使用できます。出力は、GoogleまたはBingマップでそのまま使用できる画像タイルである必要があります。 比較のためだけに、タイミングはGoogleマップのズームレベル7に合わせるべきだと言います。 皆様のご協力に感謝します。この質問がいかに曖昧であるかをおaび申し上げます。 更新:入力に関しては、現在、NetCDF、GRIB、GRIB2などのさまざまな形式の複数の(生の)データソースがあります。生データ自体に加えて、そのデータの非常に大きな画像を生成し、その画像をスライス/タイル化することもできます。 理想的には、画像を切り刻むだけですが、最速の結果が得られるものであれば何でも試してみたいと思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.