ArcGIS のホスト サービスについて : フィーチャ サービス、ベクター タイル サービス、マップ タイル サービス
本記事では米国 Esri 社 ArcGIS Blog において、ラウル・ヒメネス・オルテガ氏が投稿したArcGIS のホスト サービスに関する 8 本のシリーズ記事について、その導入の 1 本目「ArcGIS Hosted Services Explained: Feature, Vector & Map Tiles Services」を翻訳してご紹介します。
はじめに
ArcGIS におけるフィーチャ サービスとはいったい何で、なにが特別なのか？
フィーチャ サービスとベクター タイル サービスの違いはなにか？
これらのサービスを組み合わせ、パフォーマンスとコストを最適化するにはどうすべきか？
作成とメンテナンスを自動化するにはどうすればよいか？
これら疑問の中に 1 つでも共感できるものがあれば、本シリーズ記事はあなたのためのものであり、これらすべてのトピックについてそれ以上の内容で探っていきます。また、開発者、ソリューション アーキテクト、データ エンジニア、およびその他の技術的意思決定者が、広く使用されている ArcGIS のホスト型データ サービス (使用量ベースのモデルで利用可能) の違いと、それぞれが多様な使用状況に合わせてどのように最適化されているかを理解できるように記事を構成しています。
- ホスト マップ タイル サービス：大規模な静的地理空間データ用
- ホスト べクター タイル サービス：更新頻度の低い大規模な地理空間データ用で、カスタマイズと基本的な対話をサポート
- ホスト フィーチャ サービス：効率的に更新する必要がある大規模で対話性の高い編集可能なデータ用
もし初めて地理空間データを扱うという場合には、本シリーズ記事の前に「地理空間データの特徴」を読むことを強くおすすめします。先にこの記事を読むことで、これらのサービスがもたらす価値をより深く理解することができます。
※その他の ArcGIS におけるデータ サービスについて
本シリーズ記事で取り上げる 3 つのサービス以外にも、ArcGIS のシステム内には、イメージ (ホスト イメージ レイヤーとイメージ サービス)、3D サービス (シーン サービス、3D Tiles サービスなどを含む)、リアルタイム データセット (ストリーム サービス)、ビッグ データを操作するためのその他の一般的なデータ サービスなど、目的に最適化されたその他のデータ サービスがあります。
本シリーズ記事の焦点
本シリーズ記事では、Esri が提供するこれら 3 つのホスト サービスに焦点を当てており、 および ArcGIS Location Platform において、それぞれ Software as a Service (SaaS) と Platform as a Service (PaaS) として利用できます。
これらのサービスは、 によるオンプレミス環境でも利用できますが、異なる考慮事項を含んでおり、焦点を明確にするために本シリーズ記事では説明していません。
また、コード サンプルはなく、実装手順もほとんど示していません。ただし、ポータルとデータ サービス ガイドの関連リソースや、必要に応じてその他のドキュメント ページへのリンクを記載します。
ArcGIS のホスト サービスについて学ぶ理由
インフラストラクチャーを拡張し、運用負担の低減が必要な場面があると思います。マネージド サービスを使用すると、技術的に複雑な部分を軽減できます。地理空間データを効率的に保存、検索、更新することが可能なクラウド ホスト サービスを使用すれば、重要な部分にのみ集中し、エンド ユーザーに真の価値を提供することができます。
ここで、ArcGIS のホスト サービスの出番です。これらは、地理空間分野で数十万におよぶ組織をサポートしてきた数十年の経験の結果であり、既存のインフラストラクチャーをシームレスに補完、負荷を軽減し、作業を楽にできます。
また、OGC APIs などのオープン スタンダード、タイル Web マップ (XYZ タイル)、MVT などのデファクト スタンダードや、GeoJSON などの広く採用されているプレーン テキスト形式を使用して公開可能なため、相互運用性の利点もあり、Esri クライアントとサードパーティー クライアントの両方から容易にアクセスできます。
このシリーズでは、すでに使い慣れている他のテクノロジーとの比較をすることで、ArcGIS サービスがそれらと、なにが共通し、どこが異なり、どの点で際立っているか理解するのを手助けします。
なぜ本シリーズ記事を執筆したか
これらサービスについて、すでに公式ドキュメントが存在しているのに、なぜ本シリーズ記事を書くことにしたのか疑問に思われるかもしれません。
主な理由は次のとおりです。
- 非常に基礎的な技術詳細の一部は、公式ドキュメントで触れられていません。サービスを使用するために必須の知識ではありませんが、サービスの違いを理解し、要件に最適なものを選択するために役立ちます。
- 高度に自動化された活用法を対象にした、発展的なワークフローやツールがいくつかありますが、あまり知られていません。
- 技術文書とビジネス文書は必ずしも密接に関連しているとは限らないため、両方の視点を含む意思決定を行うことがより困難な状況です。
そのため、このシリーズを作成しました。焦点を絞った利用可能なリソースを提供することで、以下のようなことを支援します。
- 各データ セットとワークフローに最適なサービスを評価する。
- 学習過程を短縮することで、統合プロセスをスピードアップし、必要なメンテナンス作業を削減する。
- アプリケーションのエンド ユーザー エクスペリエンスを向上させる方法を学ぶ。
- 関連コストを削減する。
ただし、テクノロジーとビジネス モデルは共に急速な進化を遂げるため、本シリーズ記事で触れている内容の一部は経過によって古くなる可能性があることに留意してください。そのため、各記事には、最新情報を見つけることができる公式ドキュメントへのリンクを記載しています。内容に矛盾がある場合は、公式ドキュメントが他のすべてのコンテンツよりも優先されます。
本シリーズ記事を読み終える頃には、これらのサービス間の機能、使用事例、トレードオフを明確に区別できるようになり、違いを示した以下の図を完全に理解できると思います。
さらに、自分たちが求める要件や好みに基づいて、各データセットをホスティングするのに最も適したオプションを把握し、アプリケーション内でそれらをどのように組み合わせるかについても理解することができるようになります。
次のステップ
冒頭で述べた通り、本シリーズ記事はこれらサービスの使用について、さまざまな役割をご紹介しています。以下の表で、各記事が取り上げる内容、対象者、およびそれを読むことで何が得られるかをまとめています。
記事タイトル | 対象者 | 内容 |
プロダクト マネージャー、プロダクト オーナー、ソリューション アーキテクト | 各サービスが何に最も適しているかについて、明確な認識を築きます (詳細に入る前に)。 | |
データ エンジニア、開発者、ソリューション アーキテクト、テクニカル プロダクト マネージャー | 各サービスの利点と制限、および基礎的な実装の詳細を理解して、適切なサービスを選択し、長期的な保守性を計画できるようにします。 | |
バックエンド開発者、データ エンジニア、ソリューション アーキテクト、DevOpsスペシャリスト | 各タスクに適したツールを使用して、データ サービスのライフ サイクル全体 (セットアップから自動化まで) を管理し、手作業を減らして運用を合理化する方法を学びます。 | |
Web SDK とネイティブ SDK の両方で作業するクライアント側アプリケーション開発者 | サービス全体のクライアント側のパフォーマンスに影響を与えるものと、各SDKの長所、制限、最適化について説明します。 | |
フロント開発者、UX/UI デザイナー、テクニカル リード、ソリューション アーキテクト、テクニカル プロダクト マネージャー、パフォーマンス スペシャリスト | これらのサービスを最大限に活用して、可能な限り最もユーザーフレンドリーで強力なユーザー インターフェイスを作成する方法をご覧ください。 | |
プロダクト マネージャー、CTO、その他の意思決定者 | 価格、割り当て、および条件に基づいて ArcGIS Online とArcGIS Location Platform をいつ使用するかを明確にし、ニーズに最適なものを選択できます。 | |
FinOps、プロダクト マネージャー、DevOps、ソリューション アーキテクト | 使用パターンと実際のコストを結び付けて、経費の予測、予算の計画、サービス構成の最適化に備えます。 |
関連リンク
ESRIジャパン製品ページ
Esri 社（米国）Web サイト
