いち早く Snowflake NativeApp リリース
2023年 9月 7日、 弊社truestar より Snowflake NativeApp 、「PODBReverseGeocodingBeta」を Maketplace で無料にて公開いたしました。
こちらのApp は、お手持ちの緯度経度情報（Snowflake上のテーブル）に対して町丁目情報を付加した新規テーブルを作成するものです。逆ジオコーディングのサービスは他にもありますが、Snowflake上で走るため大量のデータを瞬時に処理することができます。また町丁目情報は弊社のPODBデータを使っており、デフォルトの機能は無料でお試しいただくことができます。
機能詳細、使い方につきましては、【Snowflake】ネイティブアプリ『逆ジオコーディング』をリリース！をご参照ください。
ここでは、アプリ化するにあたって、開発者目線で考慮した点や試行錯誤した状況をお話できればと思います。
コンシューマー側の使い勝手を考慮
・大量の緯度経度情報に一気に町丁目情報を付加します。10万件データを10秒で処理することが可能です。
・逆ジオコーディング後のデータに頻繁にアクセスすることを考慮し、VIEWではなくTABLEで提供いたしました。
・逆ジオコーディング後のデータに頻繁にアクセスすることを考慮し、VIEWではなくTABLEで提供いたしました。
・日時処理の中で呼び出してデータ更新できるように、Streamlitの画面ではなく、あえて関数形式で提供いたしました。
（今後はStreamlitでの提供も考慮中です）
アプリ化で苦労したこと
１．アプリ化の作成にいち早く取り組み、例がほとんどなかったことから、以下の点で苦労しました。
・プロバイダ側のテーブルを見せないようにすること
・コンシューマ側のテーブル（緯度経度情報）を参照すること
・コンシューマー側に新しいテーブルを作成すること
これらはアプリ作成時のプロバイダ側の設定、およびコンシューマ側でインストールするときに権限設定をすることで実現できます。詳しくは 初めてのSnowflakeNativeAppパッケージ化に記載しています。
２．バージョンおよびパッチを どう設定すればよいか迷いました。わかった点を以下に記載いたします。
・バージョンおよびパッチ番号は、アプリ単位で管理される。（ソースを上げる親フォルダの名前と思っていい）
各ファイル単位でバージョンおよびパッチ番号が管理されているわけではない。
１つのソースを変更する場合でも、新規の親フォルダを作成し、そこにアプリリソース全てを入れる。
・バージョン更新は仕様変更や大きなバグ改修時に、パッチ番号更新はバグ対処時に行う等、アプリ単位でポリシーを決めるとよい。
・Snowflakeのステージ上に 複数のバージョン 複数のパッチ番号のリソースを保持して、コンシューマー側で取り込まれるデフォルトのバージョンおよびパッチ番号を指定する。
・バージョンおよびパッチ番号を上げずに、フォルダ内のソースを更新した場合はリスティング情報を更新しなければならない。
・バージョンやパッチ番号を更新した場合、リスティング情報を更新する必要はない。
リスティング情報を更新しない場合は、コンシューマー側でアプリの取り込み直しを行う必要がない。
（リスティング情報を更新した場合は、コンシューマー側でアプリの取り込み直しが必要）
開発環境が整ってこそ
弊社のPODBサービスにある、都道府県、市区町村、町丁目情報 にはGEOGRAPH情報が上位から下位へJOINできる形で入っています。そして定期的に更新されています。
また、Snowflakeは地理空間関数が充実していること、大量データも瞬時に処理できること、Maketplaceの仕組みがあるので楽に提供できること、これらの開発環境が整ったため、このような逆ジオコーディングのアプリを作成できました。
是非、お試しください！
NativeApp 開発および申請支援について
弊社では NativeAppについて、開発だけでなくMaketplaceへの申請手続まで支援可能です。
PODBには公共データ等を取り揃えており、それらを活用したAppも作成できます。
Maketplaceで公開するもの、自社内で活用する処理等、お気軽にお声がけください。
PODBには公共データ等を取り揃えており、それらを活用したAppも作成できます。
Maketplaceで公開するもの、自社内で活用する処理等、お気軽にお声がけください。
