ありがとうございます。最後の1行は変換ミスと思われます。
→渡航再開後、早期にカウンターパート機関での本格的なトレーニングを実施したい。

@john1-1 ご指摘通り、変換ミスでした。ご提案通り原文を修正しました。ご指摘ありがとうございました。

@hfu UNVTについていまひとつ私は理解できていないのですが、UNVTのオーガニゼーションの下にあるリポジトリがそれぞれどの役割を持っているのか、ちゃんとわかるようなドキュメントが必要と思います。
今回ルワンダ全国のParcelsデータのタイル化をした際にUNVTの仕組みを使えば簡単にできるかなと思いましたが、そもそもツールを使い始めるためのスタート地点がどこかがよく分からず断念しました。
どこかに初めから最後までのステップを省略せずにまとめたチュートリアルなどはあるのでしょうか？

あとUNVTを分かりにくくしているのはリポジトリの名前もあるのかと思います。これは@hfuのこだわりなのかもしれませんが、本当に広く普及させたいなら英語でわかりやすい名前をつけるべきです。新参者には全てのリポジトリが暗号のように見えます。

@JinIgarashi ありがとうございます。ドキュメントの不足はご指摘のとおりと思っております。他方で、ドキュメントの充実における私の能力は非常に頼りない、とここ3年にわたり痛感しているところです。

一つには、 UNVT 自身が継続的に改善されているものであることから、また一つには、UNVT の実施においては多様なソースデータ、多様な配備先環境に合わせて UNVT 自身が融通無碍に変化する必要があることから、パッケージとして UNVT が固まるということは当面はないのかもしれないと思っています。特定のソフトウェアパッケージとしてとりまとめ、そのパッケージの活用を推進することを目的とするプレイヤーが少なくとも現在は存在しない、というのが私の現状認識です。

初めから最後までのステップを省略せずにまとめたチュートリアルは、存在しないと理解しています。それに多少近いのが unvt/washi#1 だと思いますが、これ自身もここ半年、ここ一年で subject to change です。

レポジトリ名が分かりにくいというのもご指摘通りだと思います。要因の一つは、「レポジトリを作るとき、作っている私自身がこのレポジトリがどうなるか分からない」ということです。

内容を具体的に示す名前をつけようとすると、内容をあらかじめ整理しなければなりませんが、内容をあらかじめ整理するというアプローチを藤村はとれずにおります。また、あまり意味のある名前をつけてしまうと、something の改良版として something2 のような名前をつけなければならず、まさに私のこだわりとして、そういった名前を意図的に回避しているというところがあります。

ある意味、現時点において、私自身は「本当に広く普及させたい」という思いを持っていないということかもしれません。あらゆる新参の方に、レポジトリの名前を見れば分かるようにプロジェクトを設計する能力を、藤村は持っていません。私自身が持っている個別具体のプロジェクトを回しながら、共有できるものを共有している、というのが実態だと思います。

新参の方がいらっしゃって、具体的に UNVT で何かを実施したいとお考えの場合には、現時点では「このドキュメントを読め」というご案内ではなく「どういうことをなさりたいのか伺う」というアプローチをとると思います。

技術論としては、いま本格的なドキュメントを整理しようとすると、作るはじから陳腐化してしまうだろうということを恐れています。

また、汎用性のある唯一の UNVT を作る、ということは手に余ることから、今後も、例えば依拠する計算機環境に応じて、複数の UNVT パッケージが作られ、維持され、ユーザがいなくなればそのいくつかは消えていくということを予想しています。

とはいえ、何らか具体的な研修員層に対して、何らか具体的な能力構築を行う、という機会を捉えてドキュメントを作っていきたいと思います。

「UNVTのオーガニゼーションの下にあるリポジトリがそれぞれどの役割を持っているのか」について、ちょっと書いてみますね：

unvt レポジトリそれぞれの役割

現在主要なもの

• pm: プロジェクト管理用のレポジトリ
• washi: 地理空間情報当局での能力構築を想定したドキュメント
• equinox: Raspberry Pi OS のための UNVT インストーラ
• nanban: Docker に UNVT を導入するための Dockerfile
• naru: osm.pbf ファイルのためのベクトルタイル設計ファイルとベクトルタイル図式ファイル

その他のレポジトリを少し見てみましたが、作った私からみても、現在において説明するに値しないレポジトリであるように認識しています。

@hfu ありがとうございました。まだツールとして発展途上でドキュメント整備が難しい点理解しました。まずは藤村さんが色々なデータソースから作っていると思われるoptgeoの中のリポジトリについて今後新しく作る際に、どういった手順で実行していったのか、きちんと残していくというのはどうでしょうか？

そうすることによって、将来的に例えば

• シェープファイルのデータソースの場合はこのリポジトリのREADMEが参考になる
• PostGISの場合はこのリポジトリ
• ・・・
  みたいにリンク集を作れば、それだけでも、UNVTツールを使いたい人にとっては理解を促進させるものになると思います。
  現状のoptgeoのリポジトリは作成した結果しかなく、その過程がないので、UNVTでどこまでできて、どこからは自分でやらないといけないのかが見えないです。

名前が大事と思ったのは、この前mapbox-gl-jsのドキュメントにPR出した時に、Mapboxの人に名前と実態があってないのがあるからと言われたことがきっかけでした。

@JinIgarashi ありがとうございます。

ドキュメントよりも作業のほうに適性がある私のような人間にとって、ご指摘の通り「作業をしながら記録を残していく」というのは有望な方法のような気がします。

記録を残すにあたり、スクリーンショットを気軽に貼り込めるという点で GitHub Issues を使うのが良さそうだと思っています。

スウェーデンのベクトルタイル 作成については、リンク先のような形でドキュメントを書いています。
optgeo/terrangkartan-vektor#1

書き方にはまだ工夫の余地がありそうです。またヒントをいただければ嬉しいです。

ベクトルタイルの設計情報や描画情報を作るにあたって、どのような過程をとることを勧められるか、見えてきたあたりでドキュメントをうまく作っていければと思いました。

広く普及させる段階では、名前は特に重要ですね。広く普及させるに足るパッケージを作り出せた際には、良い名前を考えたいと思います。

引き続きよろしくお願いします。

@hfu スウェーデンのベクトルタイル生成の手順書すごくいいですね。後でちゃんと手順追って、UNVTを理解できるようにしたいです。

私も水道ベクトルタイルで作ったツールとかについてドキュメントに少しずつまとめています。
https://docs.water-gis.com

hugoのLearnというテーマを使って作っているのですが、スクリーンショットから直接イメージは貼れませんが、marmeidを使ってマークダウンでシーケンス図とかフロー図とかかけるので、すごく便利です。
Github Actionsでプッシュされたホームページをビルドするようにしたので、ちょっとした更新ならGithubのブラウザ上で簡単にできます。

@JinIgarashi ありがとうございます。https://docs.water-gis.com/en/ 素晴らしいですね。