サーバー構成の詳細

ArcGIS Hub は、オープンなジオサービス REST 仕様を使用して任意の数のサーバーと通信します。 これらのサーバーでは、10.1 ~ 10.9.1 のさまざまなバージョンの ArcGIS Server が実行されており、信頼できる機関が管理するインフラストラクチャ上で稼働していたり、ArcGIS Online でホストされたクラウドの場合があります。 この大量で多様な情報を Web で提供するさまざまなサーバーのパフォーマンスに対応するために、データを公開するときには以下の詳細事項を検討することをお勧めします。

サービス プロパティ

サービス プロパティを構成するためのベスト プラクティスには次のようなものがあります。

最大レコード数は 5,000 未満にする

サービスを公開するとき、デフォルトの最大レコード数は 1,000 または 2,000 に設定され、サーバーからクライアントへのパフォーマンスが最適になるように図られています。 最大レコード数は、1 つのリクエストで返すことのできるフィーチャの最大数を決定します。 サービスで設定された値が大きすぎると、クライアントは 1 つのリクエストですべてのデータを要求しようとします。この場合、データの生成に時間がかかり、大量のデータがインターネット上で送信されることになります。

レイヤーまたはテーブル内のフィーチャの数が全部で 2,000 をわずかに超える程度や 4,000 前後の場合は、この値をデフォルトの範囲より増やしても問題ないでしょう。

しかし、最大レコード数が 5,000 を超えるサービスの場合、管理者は、ArcGIS Hub から値を下げることを勧める警告メッセージを受信します。 これにより、マップ上に表示できるフィーチャ数は減少する可能性がありますが、クライアントはマップが描画されるまで余分に待機しなくても済むようになります。 マップが一度にすべてのフィーチャを表示できないときは、グリッド形式のビジュアライゼーションが表示されます。

最大レコード数が 10,000 を超えるサービスの場合、ArcGIS Hub によってインデックスが作成されず、管理者にエラーが報告されます。 これも、表示のたびにすべてのデータを収集するのはサーバーの負荷になり、データの表示に時間がかかるというパフォーマンス上の理由によるものです。

ArcGIS Hub は、最大レコード数に関係なく、すべてのデータの 1,000 レコードを一度にクエリし、CSV、KML、SHP、GeoJSON のファイル ダウンロードをサポートするために集約するので注意してください。

OGC リンク

WMS、WFS、WCS の各リンクは、サービスの公開者が特定のサービスに対して有効化した場合に、各サイトのアイテム ビューの API セクションに追加されます。 公開者がこれらの機能を公開時に有効化しなかった場合、サービスを編集して、有効化できます。 有効にしたら、管理者は特定のデータセットまたはサイト全体 (多くのデータセットに影響する場合) のインデックスを再作成する必要があります。 OGC リンクは ArcGIS Server 10.2 以上のサービスでのみ表示されるので注意してください。

フィーチャ アクセスは必要ない

ArcGIS Hub は、フィーチャ サービスからフィーチャをクエリするのと同様に、マップ サービスからフィーチャをクエリします。 フィーチャ アクセスは、有効にする必要性が他にない限り、無効のままにしておくことをお勧めします。

縮尺の依存性は問題ない

ArcGIS Hub は、マップ サービスまたはフィーチャ サービスにリクエストを送信し、範囲に関係なくデータをクエリします。 地図の見栄えを考え、小縮尺では住所座標のポイントを表示したくない場合でも、ArcGIS Hub はすべてのデータをクエリして、位置のサマリーを表示するか、フィルター処理が可能でフィーチャの密度を表示するグリッド形式での表示により、上質なビジュアライゼーションを提供します。 これらのビジュアライゼーションはカスタマイズできません。

サービスの整理

サービスを整理するためのベスト プラクティスには次のようなものがあります。

サービスはパブリックにアクセス可能である必要がある

ArcGIS Hub には、サーバーから統計情報をクエリしてデータのサマリーを表示したり、データの 1,000 レコードを一度に要求してダウンロード ファイル タイプをサポートするキャッシュを構築したりするプロセスが含まれています。 この自動 ETL (抽出 - 転送 - 読み込み) プロセスは、利用者がデータをダウンロードしようとすると実行されます。一度キャッシュされると、ダウンロード リクエストはキャッシュから処理され、サーバーの負荷を軽減します。 インデックスの作成とキャッシュ構築のサービスは、どちらもファイアウォールを通じてサーバーと通信する必要があります。

インフラストラクチャをクラウドに拡張する

サーバーがある時点で容量に達したり、組織がセキュリティ上の理由から ArcGIS Server を一般ユーザーに公開しない場合があります。 どちらの場合も、管理者はデータ レイヤーを ArcGIS Online に公開し、99.9% の稼働を提供するホストされたアーキテクチャを活用することができます。 ArcGIS Online でデータをホストするにはクレジットを消費しますが、データをすべての人に配信できるオプションの方法です。

組織として、Web トラフィックをサーバーからクラウドに振り分けるために、特に大きいまたは人気のあるデータセットを ArcGIS Online にホストすることを選択できます。 このハイブリッド アプローチは、オープンデータでは非常に一般的です。プロバイダーも、データを多くの COTS アプリケーションでアクセス、保守、編集、使用できるため、ArcGIS プラットフォームでホストするクラウドの利点を認識しています。

ラスター データはイメージ サービスとしてサポートされます

イメージ サービスのレイヤーは ArcGIS Hub によってインデックスが作成され、JPEG、PNG、またはジオリファレンスされた TIFF ファイルなどのサポートされたエクスポート形式でダウンロードできます。 ダウンロードできる画像のサイズは、サービス レベルで構成されます。 ラスター レイヤーがマップ サービスの一部である場合、管理者はサービス内にサポートされていないデータがあることを通知されます。

大きなサービスはタイム アウトする

データを複数のサービスに整理すると、すべてのデータを 1 つのサービスにまとめるより高速になります。 まとめることは技術的に可能ですが、すべてのデータが 1 つのエンド ポイントを通してのみ利用可能になるため、パフォーマンス上のボトルネックが生じます。 プロバイダーは、Web サイトでのダウンロードにおける使用状況を管理するために、サービスの最小および最大インスタンスを管理できるように 1 つのサービスを使用してきました。 既存のサービスをオープンデータとして共有したくない場合は、データをカテゴリ別に整理した複数のサービスを公開します。 サービスあたりのレイヤー数は 20 以下にしましょう。

サービスあたりのデータまたはレイヤーの数を最適化すると、サーバーへのクエリの応答性を確保し、利用者に優れた操作性を提供できます。 レコード数を取得するためのサーバーへのクエリに 90 秒以上かかる場合、データセットはインデックスが作成されず、管理アプリケーションにエラーが通知されます。

データの管理

以下のベスト プラクティスを利用すると、一貫性がありユーザーが使いやすい形式でデータを表示できます。

注意:

ユーザーが常に最新のデータを受信できるよう、編集情報の記録を有効化することをお勧めします。

フィールド エイリアスを使用するか、ユーザーにわかりやすい名前を使用する

データを作成するとき、最終的にわかりにくい名前が属性列に使用される可能性があります。これは、ハブで表示されても利用者の役に立ちません。 これらのわかりにくい名前は、サポートしている他のビジネス アプリケーションのために必要な場合もあるので、列の名前を変更する代わりに、フィールド エイリアスを適用できます。 公開前に ArcMap で設定されたフィールド エイリアスは、(オンプレミスまたはホストされた) サーバーで使用され、既存のサービスを上書きするオプションを使用してもう一度変更および公開することで更新できます。

重要でないフィールドは無効にする

作成および管理するデータが、内部のアプリケーションをサポートするために使用されたり、他のシステムから取得され、通常は他のデータとリンクするキー値を表したりする場合がよくあります。 これらの余分なフィールドは、データ利用者の混乱を招く可能性があり、レイヤーを公開する前にマップ ドキュメント内で非表示にする必要があります。これは、既存のサービスを上書きするオプションを使用してもう一度変更および公開することで更新できます。

トポロジはサポートされない

オープンな機械可読形式データは、コンピューターが読み取れるオープンな形式で配信されることが想定されています。 ArcGIS Hub 内の自動組み込み ETL プロセスは、コンピューターが読み取れる形式を CSV、KML、シェープファイル、および GeoJSON として提供しています。 これらのデータ形式は、ArcGIS 内の処理の ArcObjects レベルで理解されるジオデータベースの振舞いを認識しません。 そのため、トポロジ (ネットワーク データセット、パーセル ファブリック、ジオメトリック ネットワーク) などの振舞いや、さまざまなリレーションシップ クラスとしてデータベースで保守されるリレーションシップはサポートされていません。 フィーチャクラス内のデータは、これらの形式で処理できますが、その他の機能は引き継がれません。

リレーションシップ クラスや他の形式の関連データを操作する場合、空間フィーチャクラスに加えて、個別のテーブルをデータとして共有できます。 関連内容を記述するデータの説明を活用したり、適切なタグを使用したり、サービスを整理したりすることが重要です。 非空間テーブルやフィーチャクラスは同じサービスから取得でき、ArcGIS Hub で関連性が表示されます。

コード値ドメインはサポートされる

前のセクションとは反対に、コンピューターで読み取れるオープンな形式を生成するときに、サポートされているジオデータベースの振舞いが 1 つあります。 データを ArcGIS Hub で表示するときにコード値ドメインが適用され、データがダウンロードされるときに、未処理の値がコード値に置き換えられます。

CSV が 5 MB より大きくオープンデータ グループで共有されている場合、ArcGIS Hub はデータのダウンロードのリンクを提供します。 これらの大きな CSV ファイルを動的にするには、ArcGIS Online にアップロードするときにサービスとして公開するオプションを選択します。 サービスが作成されたら、任意のオープンデータ グループで共有できます。ArcGIS Hub は、ユーザーがデータをクエリ、フィルター処理、グラフ化できるようにするとともに、開発者向け API エンド ポイントを提供します。

データは統計情報をサポートする必要がある

データを ArcGIS Server 10.03 以降に公開するとき、大多数のデータセットはネイティブに統計情報をサポートしています。 これにより、アプリケーションがデータのサマリーを利用者に提供できるため、利用者はデータに格納されている値を簡単に確認できます。 統計情報をサポートしていないデータセットに関連するエラーが管理者に通知された場合は、サーバー ログを調べて、必要に応じてテクニカル サポートに連絡することをお勧めします。

利用者の効率性の向上とクエリ時の負荷軽減のために、アプリケーションはデータセットの最初の 20 列の統計情報のみを構築します。

5 MB 未満の CSV ファイルは動的である

CSV ファイルを ArcGIS Online にアップロードするとき、データをマップ上にジオコードして、空間データとして提供できます。 データに位置情報がない場合も、CSV を ArcGIS Online にアップロードできます。 CSV が 5 MB 未満でオープンデータ グループで共有されている場合、ArcGIS Hub はデータに対する対話操作と、開発者向けの API エンド ポイントを提供します。