lmdb を試してみる

date: 2022-11-26
status: accepted

Context

• bdon は https://protomaps.com/blog/one-man-map-tech-stack で LMDB を勧めている。
• https://github.com/minad/lmdb に LMDB の Ruby binding がある。

Decision

• lmdb を試してみる。
• 特に、Tansei 3号で COPC のメタデータを収集するのに使ってみようと思う。
• さらに抽象的なレイヤとして https://github.com/moneta-rb/moneta があるようであるが、これはとりあえず採用しない。

Consequences

status の選択肢を定める

date: 2022-11-19
status: accepted

Context

ADR 方式で書いていくにあたり、status が取れる値を理解しておきたい。

Decision

See also にある文献をベースに、とりあえず次の選択肢があるものとする。他の値を取ることを妨げない。

• proposed: the project stakeholders haven't agreed with it yet.
• accepted: agreed on the decision
• deprecated: changed the decision -> refer to the replacement
• superseded: reversed a decision -> refer to the replacement

Consequences

思考の節約になる。とりあえず、proposed か accepted かで書いていけば良いだろう。

See also

• https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
• https://developer.mamezou-tech.com/blogs/2022/04/28/adr/

COPC メタデータは copc.js で取り出す

date: 2022-11-23
status: proposed

Context

• Tansei 3号では COPC メタデータを蓄積せずとりあえず自家用オブジェクトストレージにデータを上げている。
• 自家用オブジェクトストレージにアクセスしながら、COPC 範囲情報を取り出してベクトルタイルを作る必要がある。
• Tansei 2号では mc cp でいちいちローカルに落としてきて PDAL でメタデータを取り出していたが、これでは遅い。
• そもそも COPC なのだから、メタデータを含む箇所を選択的に取り出すことができるはず。

Decision

• copc.js を使ってメタデータを取り出すことを試みる。

Consequences

• copc.js に習熟する必要がある。
• Tansei 3号のストレージを満たす時間をうまく活用しながらコーディングしていくことになる。

自家用オブジェクトストレージ Tansei プロジェクトを複数フェーズで実施する

date: 2022-11-21
status: accepted

Context

• 点群は従来の地理空間情報と比較して1000倍程度大きい。
• 遅くても非常に安価なストレージを取り扱えるようにすることが必要。
• 通常、そのようなストレージとしてオブジェクトストレージがある。
• しかし、行政のカルチャーではクラウドのオブジェクトストレージを使用することにためらいがあることも多い。
• このため、インハウスオブジェクトストレージを実装することを考える。
• 具体的には、オープンソース・ソフトウェアである MinIO と Raspberry Pi 4B と USB HDD で経験値を貯める。
• しかし、MinIO のトポロジーは複数あり、いきなり高度な構成を実現することは現実的ではない。
• よって、MinIO を用いるプロジェクトを複数フェーズで実施する。

Decision

• MinIO で自家用オブジェクトストレージを実現し、静岡点群の COPC ファイルをホストさせるプロジェクトを Tansei プロジェクトと名づける。そのためのリポジトリを https://github.com/optgeo/tansei に設ける。
• 次のフェーズで実施する。
  • Tansei 1号: Single-Node Single-Drive. s3fs を経由して https://optgeo.github.io/tansei で静岡点群の COPC 点群データ 897GB, 12847オブジェクトをホストしている。
  • Tansei 2号: Single-Node Multi-Drive. USB HDDを4つのパーティションに分割して、これを4つのドライブとして認識させる運用をした。Erasure Coding が有効になり、heal 機能を試すことができるようになった。
  • Tansei 3号: Multi-Node Multi-Drive. Tansei 2号と類似構成のセット3台を Multi-Node 運用させた。Erasure Coding を用いた冗長性は入れつつも、シングルドライブではやや得にくい容量についてシングルバケットで取り扱う実験を行うことができた。
• Tansei 3号あたりからPrometheusを用いたモニタリングも導入することができた。（環境変数をしっかり設定して minio を再起動したら、見事に認識された。）

Consequences

• MinIO 運用のためのノウハウを少しずつ貯めることができた。
• MinIO を運用するためには Raspberry Pi よりもかなり強力な計算機が必要であるように思える。実際、https://min.io/product/reference-hardware によれば、8コア、8ドライブ、25GbE、128GB RAMが最小、と言われている。

COG (Cloud Optimized GeoTIFF) への着手は遅延させる

date: 2022-11-26
status: proposed

Context

• COG は話題になっている。
• 多数の単写真を閲覧させるシステムで、サーバ側のデータベースを使わせるパターンが多いが、そのやり方では脆弱でありスケールもしにくい。
• 多数の GeoTIFF ファイルからメタ情報を取り出してベクトルタイルにし、COG ベースでウェブ地図に表示できればスタティックになるように思えた。
• しかし、実際に調べてみると、COG からウェブ地図への接続は必ずしも容易でないように思える。
• COG の基本設計にはウェブ地図がそれほど入り込んでいないように見える。あくまで、デスクトップ GIS にデータを提供する手段であるかのように考えられている感じがする。

Decision

• 私の COG への着手は遅延させる。

Consequences

• 多数の単写真の閲覧システムを Jamstack 風に再構成する話の進捗が遅延する。

ADRを書いて共有する

date: 2022-11-14
status: proposed

Context

• 設計判断がドキュメントされていないことにより、説明を繰り返している状況がある。
• 設計判断がドキュメント化されて形式知になっていないので、判断自体のクオリティも限定的である。

Decision

• Architectural Decision Record を GitHub Issues に気軽に書いていけるようにする。
• GitHub Issue Template を用いるなどして、URL 付きの ADR を容易に作れるようにする。

Consequences

• ADR が蓄積される。
• 結果として DWG7 on Smart Maps のカルチャーが醸成される。
• Smart Maps Meetup UNopenGIS/7#27 でも話題にできる。

Title

date: 2022-12-17
status: proposed

Context

• 地理院地図などで GeoJSON ベクトルタイルが使われているが、救済されていない。
• 地理院地図で使われている GeoJSON ベクトルタイルには mokuroku.csv.gz が随伴する場合が多い。

Decision

• 単写真主点の GeoJSON ベクトルタイルからベクトルタイルの PMTiles ファイルを作る optgeo/shutendoji をゆっくり進める
• optgeo/shutendoji を実際に進めるためのツールとして unvt/yasumasa を作る。
• unvt/yasumasa は、mokuroku の URL と取り出しズームレベルを入力として GeoJSON Text Sequence を返すものとする。

Consequences

• GeoJSON ベクトルタイルの救済が加速される。