ArcGIS Online ブログ: ホストされたフィーチャ レイヤーで変換を制御する

KellyGerrow

<\/HEAD>

こちらのArcGIS ブログ<\/A>をご覧ください。著者はPaul Barker<\/A>です。<\/P>

もし世界にたった一つの投影法しかなかったら、どれほど簡単だったでしょうか。地球を紙やデバイスの画面に平面化しようとする過程で、私たちは目的に応じて多くの投影法を作り出しました。それぞれの投影法には目標があり、同時に妥協点もあります。変換は、データをある投影法から別の投影法に変換するために使用されます。<\/P>

私は常々、変換は言語間の翻訳に似ていると思っています。例えばフランス語と英語の場合。今日ではGoogle Translateを使えば、大部分でかなり良い変換が得られます。それは広い意味で機能し、時には奇妙な表現が<\/SPAN>翻訳の過程で失われることがあっても<\/EM>、伝えたいことを伝えることができます。しかし、もしあなたの聴衆がフランス系カナダ人、ハイチ人、またはスイス人だったらどうでしょうか？言語の地域差によりよく合うように特定の単語の翻訳を少し調整するかもしれません。<\/P>変換も同様に機能します。世界、または大陸や国全体にまたがるデータを変換するためのより一般的な変換があります。それらはかなり良い仕事をしますが、ローカルスケールにズームインすると精度が落ちる傾向があります。そこで地域や場所固有の変換が非常に効果的です。これらは特定の地域の座標をある投影法から別の投影法へ変換するよう設計されています。<\/P>ArcGIS Online は、フィーチャ レイヤーをある投影法から別の投影法へ変換する際に、あまり考えずとも非常にうまく処理してくれます。データの詳細を見て、そのデータをマップの投影法に変換するために最も適切だと思われる変換を適用します。しかし時には、その「最も適切だと思われる」ものがあなたの望むものではない場合があります。その結果、データがわずかに、あるいはかなり目立ってずれて見えることがあります。<\/P>

<\/A><\/P>

誤った変換やマップ領域に対して精度が低い変換が使用されると、異なる投影法のマップ上に重ねた際にデータがずれることがあります。<\/SPAN><\/P>そのような状況になった場合、問題を解決するために利用できるいくつかのオプションがあります。<\/P>

事前にデータを投影変換する<\/H2>これは新しい方法ではなく、「ベストプラクティス」のトップにも常にあります。データの再投影方法を完全に制御したい場合は、作業しているマップと同じ投影法にデータを再投影できます。ArcMap や Proでは、使用するWebマップと同じ投影法のマップまたはデータフレームにレイヤーを追加し、そのマップまたはデータフレームプロパティで適用したい変換を設定します。そしてレイヤーを ArcGIS Online に公開します。公開プロセス中に指定した変換を使ってデータがマップまたはデータフレームの投影法に再投影されます。この方法は独自のカスタム投影や関連するカスタム変換がある場合でも機能します。ただしワークフローによっては、この方法だと公開したレイヤーを元のデータセットに統合する際に余分な手順が発生します。<\/P>リアルタイムであなたが操作して投影変換する<\/H2>上記の方法は一部の方には有効ですが、すべての人が望むわけではありません。時には、自分たちの組織で最も理にかなった投影法でGISデータを保持したいという方も多いでしょう。その多くの場合、それは Web Mercatorではないでしょう。ArcGIS Online に対して、自分たちのデータを Esri のベースマップ上で追加するときにリアルタイムでどのように再投影するか指示できれば便利です。そのシナリオでは両方の利点があります。自分たちの GIS データとベースマップで作業しているときは再投影されません。しかし組織とは異なるベースマップ上でそのデータを重ねたい場合には、公開前に適切な変換を選択できます。最新リリースの ArcGIS Onlineではホストされたフィーチャ レイヤー公開時にまさにそれが可能です。公開前にマップまたはデータフレームで設定したサポートされている任意の変換は引き継がれ、そのホスト フィーチャ レイヤー使用時にも適用されます。<\/P>つまり Web Mercator以外の投影法でデータを公開し、そのレイヤー投影法から WGS1984 のような別の投影法へ移行するための変換を追加できます。そのデータが WGS1984 ベースマップ上で表示される際には選択した変換によって再投影されます。この方法は Esri のデスクトップ ソフトウェアで標準サポートされている任意の変換で動作するはずです。<\/P>注意：ユーザー定義／カスタム変換や通常サードパーティ製グリッドシフト データベース（GSB）のダウンロードが必要なグリッドベース変換は現時点ではサポートされていません。予期せぬ問題回避のため公開前にそれらをデータフレームから削除してください。それぞれの方法について詳しい手順はArcGIS Online ヘルプ<\/A>をご参照ください。<\/EM><\/P><\/BODY><\/HTML>

DavidColey

Interesting.  What we do at Sarasota County GIS to provide the best of both worlds is this: For downloads from our Open Data site, we publish layers as hosted feature feature layers to our AGOL org, making them visible to the Open Data group so that they are visible to our Open Data site. For this use case, we keep the layers in their native State Plane coordinate system. We then overwrite those layers each week using a python driven workflow. 

For mapping purposes, we transform our data on the backend to Web Mercator, and then serve those layers in a variety of themed map services.  I then make those layers available to our org as referenced feature layers.  This may seem like a lot of work but it's really not unless you sitting down and adding some 200 layers all at once.  In that case we can use the ArcGIS API.  

The trick is to simply provide well-worded descriptions in Overview sections of both your hosted (State Plane) and referenced (Web Mercator) feature layers so that the uses know which layers are suitable for download and which layer are suitable for mapping. Of course, users can and do extract our referenced layers through a variety of Web Application Builder apps or from the overview pages themselves, but they know what they are getting either way.

Finally, we'll have to see what efficiencies we gain as we move to ArcEnterprise, federate our ArcServer site with Portal (and designate hosting!) then set up collaboration between our Portal and our ArcGIS Online environment!