ベクトルデータをエクスポートして同期する

ChristineBrunner

<\/HEAD>

製品ファミリーであるArcGIS Runtime SDKs<\/A>は、バージョン10.2以降オフライン対応となっています。これにより、背景地図やベクターデータをサービスからエクスポートでき、ベクターデータの場合は同期も可能です。これらの機能を示すために、Esri Deutschlandはデモアプリケーションを開発しました。このアプリはCollector for ArcGIS<\/A>のオフライン機能を、ArcGIS Runtime SDK for .NET<\/A>およびJava<\/A>で再現しています。このデモはCollector Lightと名付けられ、GitHub<\/A>で公開されています。また、すでにブログ<\/A>も掲載されています。<\/SPAN><\/P>

この記事では、Javaデモを例に、ベクターデータのエクスポートと同期の流れを詳しく見ていきます。<\/SPAN><\/P>

<\/H2>いくつかの準備が必要です<\/SPAN><\/H2>デモはデータソースとしてWebMap<\/A>を使用していますが、必須ではありません。ベクターデータをエクスポートするにはFeatureServiceが必要です。これはArcGIS Online<\/A>、Portal for ArcGIS<\/A>、または独自のArcGIS for Server<\/A>上でホストされている可能性があります。サービスで「同期」操作が有効になっていることが重要です。ArcGIS for ServerではArcGIS Server Managerの該当サービスの機能 -> Feature Accessで設定できます。<\/SPAN><\/SPAN><\/P>

<\/P>

ArcGIS OnlineおよびPortal for ArcGISではサービスのプロパティ内で設定します。<\/SPAN><\/P><\/SPAN><\/P>この機能を有効にすると、サービスは追加のRESTインターフェースを提供します。「Create Replica」操作でデータをオフライン取得でき、「Synchronize Replica」でデータ同期、「Unregister Replica」でデータ削除が可能です。詳細は後述します。<\/SPAN><\/P><\/P>

<\/H2>いよいよプログラミング開始です<\/SPAN><\/H2>これらRESTインターフェースを直接実装する必要はありません。ArcGIS Runtime SDK for Javaが既にラップしており、それに対応するJavaクラスとメソッドが用意されています。ベクターデータエクスポートの使用例はデモのaction.CreateOfflineProjectクラス内、具体的にはcreateGeodatabaseFromServiceメソッドにあります。 <\/<SPAN>\n<\/<SPAN>\nWebMap使用による若干のデータ整形後、興味深い部分は330行目から始まるGenerateGeodatabaseParameters<\/_A>の生成です。 <\/<SPAN>\n

// パラメーター設定
                                      
GenerateGeodatabaseParameters params = new GenerateGeodatabaseParameters(
       ArrayUtils.toPrimitive(layerIds.toArray(new Integer[layerIds.size()])),
       extent,
       map.getSpatialReference(),
       false, 
       SyncModel.GEODATABASE,
       map.getSpatialReference());


ここでエクスポート対象データを制限できることがわかります。一つはサービス内の特定レイヤー選択、もう一つは範囲(extent)指定による領域制限です。添付ファイルも読み込めますが必須ではありません。また、適切な座標系をパラメーターとして渡すことが重要で、これにより後で地図上に正しく表示されます。その後、二つのコールバッククラスが必要です。一つは実行中のステータス情報受け取り用、もう一つはタスク完了時に結果受け取り用です。そして実際の呼び出しgenerateGeodatabaseを行うクラスGeodatabaseSyncTask<\\/A>が登場します。<\\span>

// ------------------------------------------------------------------------ 
// サービスからジオデータベース生成とダウンロード
// ------------------------------------------------------------------------ 
GeodatabaseSyncTask gdbTask = new GeodatabaseSyncTask(featureServiceUrl, PortalConnector.getUser(true));
gdbTask.generateGeodatabase(params, pathToGdb, false, statusCallback, gdbResponseCallback);

このクラス生成にはFeatureServiceのURLだけが必要です。セキュリティ保護されたサービスの場合、この例のように認証情報(Credentials)も渡す必要があります。認可と認証については別ブログで詳述しています。<\\span>

私のデータはどこ？<\\span>

この例のgdbResponseCallbackでは、新しいデータが利用可能になったことだけProjectManagerに通知しています。そこで疑問になるのが「私のデータはどこ？」という点です。それらは呼び出し時パラメーターpathToGdbとして渡したパスと名前の場所にあります。名前には拡張子.geodatabaseが付加されます。データはSQLite形式というデータベース構造で保存されており、市販のSQLiteツールで閲覧可能です。<\\span>

どうやって地図にデータを表示する？<\\span>

しかし我々は他ツールではなく、自分たちの地図上でデータを見たいわけです。そのためにArcGIS Runtime SDK for JavaにはFeatureLayer<\\/A>クラスがあります。このクラスは様々なデータソースから基盤として生成できます。この点がこのクラスの素晴らしいところです。データソースに依存せず扱い方は常に同じです。その中でもGeodatabaseFeatureTable<\\/A>というものがあります。我々はこれらテーブルへアクセスするために、自分たちのSQLite<\ クラス <A href="https://developers.arcgis.com/java/api-reference/" rel="nofollow noopener noreferrer" target="_blank">Geodatabse を使ってデータベースを初期化します。各レイヤーごとに GeodatabseFeatureTable が生成されます。<\/SPAN><\/P><\/P>Geodatabase localGeodatabase = new Geodatabase("PathToGeodatabase");
  for (GeodatabaseFeatureTable table : localGeodatabase.getGeodatabaseTables()) {
  FeatureLayer featureLayer = new FeatureLayer(table);
  featureLayer.initializeAsync();
} <\/PRE><\/P>家に電話したい<\/H2>さて、これでデータはオフラインになりました。私たちはデジタル文明から離れて自由に移動し、データを収集、変更、または削除することができます。しかしいつかは、自分の変更を同僚と共有したい時が来ます。また、私の不在中に彼らが何をしていたのかも気になるかもしれません。ですので、母艦（FeatureService）と連絡を取る必要があります。デモではこれは action.SyncProject クラスで行われます。すでにおなじみのクラス GeodatabaseSyncTask のメソッド syncGeodatabase がこれを助けてくれます。<\/SPAN><\/P><\/P>gdbTask.syncGeodatabase(syncParams, gdb, statusCallback, syncResponseCallback);<\/PRE><\/P>ステータスメッセージ用と結果用の2つのコールバックが再び見られます。その他のパラメーターとしては Geodatabase (gdb) と特別な SyncGeodatabaseParameters が必要です。Geodatabase は前のステップでデータの可視化のためにすでに作成しています。また SyncParameter についても心配する必要はありません。これらは Geodatabase によって生成されるからです。<\/SPAN><\/P><\/P>final SyncGeodatabaseParameters syncParams = gdb.getSyncParameters();<\/PRE><\/P>これには、複雑なデータベース構造を知らなくても変更点を抽出できるという利点があります。なぜなら転送されるのは常にデルタ（差分）のみであり、完全なデータベースではないからです。同期時にはサービス側のすべての変更もローカルデータベースに転送されるため、最新の状態で作業を続けることができます。ここでもデルタのみが転送されます。このことは以下の図にも示されており、全体のワークフローが模式的に表されています。<\/SPAN><\/P><\/P><\/P>複数の同僚が同じデータセットに変更を加えた場合、常に最後の変更が優先されます。ただしここで考慮されるのは変更時刻ではなく同期時刻のタイムスタンプです。将来的にはサービスごとに設定可能な他の競合解決オプションも提供される予定ですが、現時点ではまだ利用できません。<\/SPAN><\/P><\/H2>隠遁生活を終わりにしましょう<\/H2>いつかはオフィスに戻り、ローカルコピーのデータが不要になるでしょう。その際には単純に削除するのではなく、事前にサービスから Unregister を行うことが重要です。当然ながらここでもクラス GeodatabaseSyncTask が利用可能で、今回はメソッド unregisterGeodatabase を使います。<\/SPAN><\/P><\/P>gdbTask.unregisterGeodatabase(gdb, unregisterCallback);<\/SPAN><\/PRE><\/P>この呼び出しはデモでは action.DeleteProject クラス内で見られます。しかしなぜこの呼び出しが重要なのでしょうか？FeatureService は各コピーごとに Replica と呼ばれるものを生成します。この中には最後の同期時刻などコピーに関する情報が格納されています。この情報は同期メカニズムを実現するために必要です。Unregister 時にはこの Replica が削除され、サービス側はローカルコピーが不要になったことを認識します。サービスディレクトリでもサービスの Replicas を確認できます。<\/SPAN><\/P><\/P><\/P>