• [x] 凍結した旧バージョンのIssuesをClose
• [ ] リポジトリーのファイル群を一般公開版 G6 に変更

• 常にマウスカーソルは表示され、他のウィンドウとも容易にマウスカーソルを移動できるように変更する。（現在はマウスカーソル非表示、ウィンドウを切り替えるかメニューモードでなければマウスカーソルを自由には扱えない）
• マウス操作の操作モード状態がわかりやすい「表示」を追加する
  • マウス右クリック中: カメラ回転モードなのでマネキンまわりに回転っぽい半透明矢印を出し、アクティブな回転方向は光らせる
  • マウス中クリック中: 移動モードなのでマネキン回りに移動っぽい半透明矢印を出し、アクティブな移動方向は光らせる
• マウス操作でもメインメニューを呼び出せるよう、HUDの右下か左下の隅にでもメインメニュー呼び出し用のボタンを付けるか、あるいは左長押し、トリプルクリックなどでメインメニューを出せるようにする。（これによりマウスだけでも多くの操作、メニューの遷移が可能になる。）

• はじめてG4を起動した直後
• メインメニュー > チュートリアル

これらのタイミングで基本操作の in-app チュートリアルを実装し、ユーザーがマニュアルを確認せずとも基礎的な操作はすぐに行なえ、また操作について再確認したくなった際にも app 内のメインメニューから呼び出してチュートリアルを行えるようにしたい。

4.0.0.11 現在の標準設定はさほど検討せずに適当に実装済みの操作をアサインしたもので、操作性、操作感が一般的に多くのユーザーにとってよいものにはなっているわけではない。

また、ほとんどのユーザーはキーアサインを独自設定せず標準で、少なくともいったんは使おうと試みる。

そこで、一般的な3Dフィールドを移動するゲームでの操作対応を参考に、標準のアサインを一般的に同様のフィールド操作を伴うゲームと互換性の高いように変更し、ユーザーが操作の学習なしに扱いやすいよう工夫したい。

• 地形の読み込みが未完了のエリアには進入不可、既に侵入している場合は移動不可として、誤操作により読み込み未完了のエリアに対してユーザーが地形を前提とした操作を不意に行ってしまう可能性を排除し、操作に安定感を与える。
• 進入禁止・移動禁止のエリアは「地形データを構築中」の旨が容易に視認できるエフェクトを施す。
• この機能は on/off できる。標準設定は on とする。

現在は地形の読み込みの完了が遅れている場合でもそのエリアへ侵入したり、高度変更の操作を継続できる。これによりユーザーが地形を前提とした機能を不意に地形データの存在しないタイミングで操作してしまう可能性があり、意図せずそのような挙動に遭遇したユーザーは動作が不安定と感じると推量される。そこで本チケットの対応を施す事とした。

relative: https://github.com/godai-kaihatsu/gondwana/issues/23#issuecomment-353082916

relative: https://github.com/godai-kaihatsu/gondwana/issues/23#issuecomment-353082916

GeoTIFF フォーマットのデータを地物としてロードする機能を追加する。適当に細分割した板にテクスチャーをはったような地物としてロードすればよいのではないか、と考えている。

JSON-RPC-2.0 は開発や通信内容の解析がヒューマンフレンドリーだが、アプリケーション間の通信ではオーバーヘッドが大きく、将来的にこれをきらう連携アプリは少なからず発生すると見込まれる。そこで、原則的には JSON-RPC-2.0 と同様の RPC を msgpack でも /api/msgpack/ で提供したい。

なお、開発リソースの都合、 JSON-RPC-2.0 の API すべてに msgpack を対応し互換性を維持する事は難しいため、特に頻繁に連続して呼び出す必要のある API やテキスト処理のオーバーヘッドによるレイテンシーが気になる API について、先ずは対応する。

現在はロケーション検索を行うと即座に最有力候補の座標へ移動するが、必要に応じて、移動する前に候補の選択肢を表示し、選択して確定してから移動できるオプションが欲しい。ただし、多くの場合には検索から即座に移動で問題無いため、それで十分な場合に対して操作が煩雑とならないよう実装して欲しい。

現在のGUI（地球上の経緯度高度による絶対座標）:

経緯度標高について現在の位置から相対的に移動するモードとして次の2つが欲しい:

1. rel-alt (m), rel-lat(deg), rel-lon(deg)
2. rel-alt (m), rel-lat(m), rel-lon(m)

逆射影を計算して上から見たテクスチャーとして保存できるペイント機能がいいかな、と考えている。

切土、盛土などに対応する地形の編集操作はG3のユーザーニーズとして強かったものの、G3では地形システムの設計都合導入が非常に難しかった。G4ではその点を当初から想定した設計を行ったため内部的には既に実装がある。

本チケットでは Terrain API 機能として、APIレベルで地形編集の基礎的な機能を試験提供し、ユーザーからの地形編集機能へのフィードバックを得られる状態とする。

APIを基本とするか、GUIを基本とするかは要検討だが、何れにせよ縦横断図機能が欲しいという要望がある。

ref. https://en.wikipedia.org/wiki/GeoJSON#TopoJSON

地形は LOD=15 のままでもある地図レイヤーは LOD=18 また別の地図レイヤーは LOD=13 のように地図レイヤーのLODレベルをレイヤー単位で地形から独立させたい。

現在はLOD切り替わりタイミングで地表が消えて背景の宇宙が透けて見える。ユーザー的には心臓に悪いと思うので切り替わり前のデータから合成した地形をダミーで入れるなどしたい。

↓動画参照

https://imgur.com/Z1muxid

level_of_detail_max=15 にするとしばしば以下のような描画結果を見る事になる。

現在は GeoObject は1つだけの管理システムで全てを一括管理している。グルーピングを行いたければタグ機能を使えば好いだろうと考えての実装だ。

しかし、GUIを通して制御する上でユーザーがタグによるグルーピング、検索での絞り込みからの制御を巧く行えない様子があれば、管理システムを単一から複数にし、管理システムごとに GeoObject 群を管理可能にする Slot 化を検討しようと思う。

地物システムは現在タイルとは独立した実装となっている。本チケットではタイルシステムと地物システムを合わせた地物タイルの実装を行い、GSIの提供するGeoJSON形式のタイルサービスを地図レイヤーと類似した感覚でユーザーが扱えるよう対応する。

1. GeoObject システムのタイル対応改修
2. タイルシステムの GeoObject 対応改修
3. 地物タイルのメニューGUIの追加

https://github.com/godai-kaihatsu/gondwana/issues/70#issuecomment-380308757 より。

これを地物HUDのオンカーソルで出したら面白い。実用性も高まるだろう。 preview-7 より後に検討を開始する。

改修 #112 に伴い動作の大幅な軽量化と完全非同期化によるG4本体のフリーズフリーな動作の実現に併せて、タイルによる地形やテクスチャーの読み込み、隣接調整など、その状況に応じてタイルのエリアを直方体モデルベースの光柱表現で視覚化し、そのエリアが現在どのようなロード、計算などの準備処理を行っている状態か、あるいは完成した表現のエリアであるか簡単にユーザーが把握できるようにしたい。

preview-7よりも後、OBTよりも後になると思うが、ボタンなどのUIデザインを綺麗なものにしたい。

理想: http://www.capcom.co.jp/monsterhunter/world/news/

課題: GeoJSONからのインポート、ジオコードAPIからのインポートを行う場合など、複数の GeoObject を生成する事になる場合が多いが、生成後に個々の id は取得できるが、グループ化したい場合には個々の id それぞれに改めてタグ付与する必要がある。

本チケットでの対応: 地物群を一括生成する際に、以下の2つのタグ付与機能を追加する。

1. 任意のタグを同時設定可能: API にパラメーターを追加し、任意のタグを同時生成可能にする。
2. 複数オブジェクトを生成する場合には steady_clock な tick などで少なくともマシン固有の簡単な id を自動的に生成し、同じ瞬間に生成された地物オブジェクトすべてに設定可能にする。この機能は余計な事も有り得るので生成時のパラメーターで無効化可能にしておく。

[/Script/G4.ProceduralPlanet]
lod0_max=15

• コンフィグを削除して標準の設定で起動すると発生しやすい
  • 位置により起こりやすい可能性あり？
• 13 だと crash しない。

rel. https://github.com/godai-kaihatsu/gondwana/issues/94#issuecomment-375840985

地物システムでマーカーを表示する場合にマーカーとは別にマーカーを目立たせたり、逆に目立たないようにしたりするための「マーカーエフェクト」を設定可能にする。

目立たせるエフェクトの例としてわかりやすいのは "ここにマンションが建ちます" でお馴染みになりつつある光り輝く土地エフェクトだろう。ああいうのを実装する。

注視点を中心に周囲 N km 四方とかで標高や地図タイルをエクスポートする機能。

• 複数の出力形式、出力ファイル群などに対応する。
• .x + .png(s) や CITIES Skyline 対応の標高データなども対応する

current: ぽち→一瞬でワープ this-work: ぽち→config可能なイージング処理により滑らかに時間変化により"移動"

ユーザーにとって脳が追いつくように処理を低速化する事はよりよい体験となる。少なくとも十分に訓練を積むまでは。

基本機能を拡張し "Massively Multiplayer Online" 機能を実装する。

• chat にサーバーとルーム機能を追加
• chat サーバー機能を追加（既存のチャットサービスにAPI接続で連携するのが認証上の安全策としてよいかもしれない）
• ユーザーレベルの権限設定機能
• chat のユーザーIDを元にした friend 機能、 party 機能
• main-view に friend の注視点、視点を表示
• friend, party の視界を picture-in-picture で表示するHUD機能（MMORPGならパーティーメンバーのHPや状態異常を表示するようなに対応すると考えてもよい）

G4上でフレンズと virtual map discussion できるシステム。

既知の地形情報＋地形傾向の分析から未知の分解能の地形情報を仮想生成する技術をG4へ実装する。

GeoObject mode

1. 3d object; O3
2. 3d area; 3A
3. 2d area; 2A
4. 3d lines; 3L
5. 2d lines; 2L
6. 3d points; P3
7. 2d points; P2

object, area, lines, points

• object; 一般、特にCG屋さんが polygon って言うもの。一般的な 3DCG データ。標準のマーカーは ● ＋ 破線状の △ 囲い。
• area; 主に土木屋さんが polygon って言うもの。可視化時に1頂点につき alt 軸方向に2点に展開し thickness = number:length-in-meter パラメーターの厚みにする。HUD上の代表位置は幾何学的重心位置。標準のマーカーは ● ＋ 破線状の □ 囲い。
• lines; 2つの頂点からなる線分の集合として可視化。HUD上の代表位置は最初の line の中間位置。2つ目以降の全ての line の中間位置への指示もHUDで行う場合は point_to_all = true する。標準のマーカーは ○ ＋ 破線状の ○ 囲い。
• points; 点群。2つ目以降の全ての point 位置への指示もHUDで行う場合は point_to_all = true する。標準のマーカーは ● ＋ 破線状の ○ 囲い。

flags

1. mode: enum { object, area, lines, points }

upgrade

1. マルチパート対応。1つの go に複数の object, area, line, point を格納可能にする。対応は indices のマルチパート化のみで行い、 go の他のフラグやプロパティー等は go 単位で共有する。

「地形に対応した落書きを行う機能」として従来から検討していたもの。 #65 に関連してHUD実装を進めるうちにいくらかアイデアが追加されたのでチケット化して進める。

• 先ずは「落書き」HUDとして実装する。想像例としては写真系SNSやプリクラへの落書きの感覚、あるいは実際の地図を挟み込んで透明のフィルムを掛けた上へ水性ペンで書き込みを行うような業務現場でのシーン。
  • ポインティングデバイスモードを「操作」、「カーソル」、「ペイント」の循環切り替えに拡張。
  • 対応モード時にはHUDに簡単なペイントツールを表示し落書きできる。落書きはピクセル化せずベクターなりオブジェクト単位で扱えるようにしたい。
    • 太さと色・不透明度を変えられるペン
    • 始点と終点から直線、矩形、円を描ける
    • 文字列を描ける
    • 画像ファイルを読み込んで任意の位置へ拡大縮小しつつ貼れる
• 次に、「落書き」HUDに以下の機能を追加する。
  • メインビュー＋落書きを画像ファイルとして保存
  • 落書きのみ画像ファイルとして保存（透過画像）
  • シェア（SNS、メール）
• 次に「落書きを地図タイル化」機能を追加する。
  • スクリーンスペースでしかない落書きを地形に基いて地図タイル化する。

タイル化機能は落書きを任意視点化したい場合に使う。落書き機能の発想当初はそもそもタイル上に射影して落書きできる事だけを考えていたが、スクリーンスペースでの落書きとタイル化の2段階の機能とするとどちらにも需要があり良いだろうと考え、調整した。

視点を離すほど派手に発生する。

推量: 深度処理に問題がある。

レーザープロファイラーの一般的なデータフォーマット LAS に対応する。具体的な対応方法、描画方法の検討から本チケットで行う。

LASer (LAS) File Format Exchange Activities https://www.asprs.org/committee-general/laser-las-file-format-exchange-activities.html

試験用データは静岡県ポイントクラウドデータベースを使えばよいだろう。

https://pointcloud.pref.shizuoka.jp/ https://pointcloud.pref.shizuoka.jp/lasmap/ankenmap?ankenno=28XXX00030004 https://pointcloud.pref.shizuoka.jp/lasmap/ankendetail?ankenno=28XXX00030004

• binary format: http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
• library: http://shapelib.maptools.org/

• 点を params で与えると規定のマーカー様のモデルを用いた GeoObject を作成できる高レベルAPIを実装する。
• optional にマーカーオブジェクトを幾つか選択可能にする。
  • pin 系のほか、地点を中心に一定の正規格子状のグリッド、円で距離を示せるものを用意したい。

地形編集にも対応するリアルタイム動作可能な等高線機能を追加する。

実装方法、精度、表現方法などは調査と実験を行い決める。

4.0.0.15 時点ではカメラが注視点から大きく離れると僅かな距離の操作でも大きく変化し過ぎてしまい器用に制御しようとしてもなかなか上手く目的のカメラと注視点の距離にセットし難い。

どうにか工夫したい。

また、地理院地図のレイヤ定義ファイルは既に様々なシステムから参照されていることから、恐れ入りますが拡張子は現行のままとさせていただきます。

そのために 301 Moved Permanently も提案しているのですが失礼ながらご検討頂いた上でのご判断でしょうか？よりよいプロジェクトの未来のためにあくまでも建設的にご確認頂ければ幸いです。

もちろん、検討の上で、否定理由はコメント頂かない上でも仕様としてそうするのだとAuthorさんが決めれば、サードパーティー開発者等々はそれはそれでただ従うだけの事ではあります。しかし、より合理的で美しく現実的な既存実装や慣れのユーザビリティーにも配慮できる選択肢があると考えて起票しましたので、起票に際して提案した方策について否定される場合は十分な理由も明示頂けると起票者としても心中すっきりいたします。

Authorが決定し、ユーザー開発者はさだめられた仕様を間違いなく実装しエンドユーザーに便利を促せればそれでよいと考えます。

よってこれは蛇足ではありますが、ソフトウェアや仕様、特に生きたウェブサービスに関連した仕様では、プロジェクトにおけるマイルストーン(githubにも機能として実装されていますね)やメジャーバージョン(一般的にgitリポジトリーではtagで実装していますね)という概念があります。

本件のほかにも、おそらく仕様について現行から「既に様々なシステムから参照」を理由にAuthorさんも歯がゆい部分もあるでしょう。今後のバージョニングやマイルストーンの活用方法に巧く活かし、保守性や仕様の発展性を良好に保つ事、サードパーティー開発者にもフレンドリーな仕様とする事、新規参入者への"オマジナイ・ルール"の減少（特に本件のようなものはケース・センシティブが当然の処理系での実装時にバグの温床、余剰の負担を開発者に強いてしまいますしね）について超長期的な方策も視野に入れるときっと便利で、10年後も愛され、利用され続け、発展し続けられる活きたプロジェクトとしての継続性を獲得するヒントになるかもしれません。

The infographic suggests that Cell can only be used with Copy types. But you can move anything into a Cell. See the replace method.

Note: I'll plan to merge rev-2-preparing branch to master in the next weekend.

この仕様の事実上の公式の実装がgsimapsしかないので現実の開発者の混乱を避ける効果としてはそれでよいのかもしれないですね。理想としては 「"本レポジトリでいうウェブ地図レイヤ定義ファイル"として扱う対象」 の方を仕様で明確かつ個別具体の実装を仕様側からは触れない綺麗な定義ができればより美しいとは思いますが、現実の問題を回避でき、現実的な対応コストで現行よりよい仕様になればさしあたりはよいのだろうと思います。

@goto-bus-stop Unfortunately yes, this problem occur in there any versions:

• surf = "1.0.3"
• surf = {git = "https://github.com/http-rs/surf", tag = "v2.0.0-alpha.0"}
• surf = {git = "https://github.com/http-rs/surf", tag = "v2.0.0-alpha.1"}
• surf = {git = "https://github.com/http-rs/surf", tag = "v2.0.0-alpha.2"}
• surf = {git = "https://github.com/http-rs/surf", tag = "v2.0.0-alpha.3"}
• surf = {git = "https://github.com/http-rs/surf", tag = "v2.0.0-alpha.4"}
• surf = {git = "https://github.com/http-rs/surf", tag = "v2.0.0-alpha.5"}

Example repro code

main.rs

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Sushi {
    sushi: String,
}

fn main() {
    // UTF-8N; `{ "sushi": "🍣" }`
    let mut r = smol::block_on(surf::get("http://localhost:50000/n-sushi.txt")).unwrap();
    let sushi = smol::block_on(r.body_json::<Sushi>()).unwrap();
    println!("n{:?}", &sushi);
    // UTF-8 BOM; `\u{feff}{ "sushi": "🍣" }`
    let mut r = smol::block_on(surf::get("http://localhost:50000/bom-sushi.txt")).unwrap();
    let sushi = smol::block_on(r.body_json::<Sushi>()).unwrap();
    println!("b{:?}", &sushi);
}

Example UTF-8N and UTF-8 BOM files

1. hexdump --canonical n-sushi.txt # It's UTF-8N(Reference)

00000000  7b 20 22 73 75 73 68 69  22 3a 20 22 f0 9f 8d a3  |{ "sushi": "....|
00000010  22 20 7d                                          |" }|
00000013

2. hexdump --canonical n-sushi.txt # It's UTF-8 BOM (Target of this test)

00000000  ef bb bf 7b 20 22 73 75  73 68 69 22 3a 20 22 f0  |...{ "sushi": ".|
00000010  9f 8d a3 22 20 7d                                 |..." }|
00000016

Repro procedure

1. simple-http-server -p 50000
2. cargo run

And then I got the result:

// cargo process

    Finished dev [unoptimized + debuginfo] target(s) in 0.41s
     Running `target\debug\se.exe`

// The result part of the first UTF-8N reference

nSushi { sushi: "🍣" }

// The result part of the second UTF-8 BOM testing

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: expected value at line 1 column 1', src\main.rs:15:56
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\se.exe` (exit code: 101) 

不具合の位置

• https://github.com/gsi-cyberjapan/gsimaps/blob/bed0467e2c9ca5c546777832ecc5d57126144251/layers_txt/layers6.txt#L3809

↑ここから src で参照が定義されている https://maps.gsi.go.jp/sar/layers_txt/layers_alos2_vol_nishinoshima.txt に問題があります。

note: 但し、問題のあるファイル layers_alos2_vol_nishinoshima.txt は地理院地図として配置済みの状態ですが gsimaps のソースコードには存在しません。 commit 漏れであればそちらもご対応下さい。

不具合の内容

このファイルの先頭には 0xEE 0xBB 0xBF からなる UTF-8 文字コードに対する BOM が埋め込まれています。

00000000  ef bb bf 09 7b 0d 0a 20  20 09 22 6c 61 79 65 72  |....{..  ."layer|
00000010  73 22 3a 20 5b 0d 0a 20  20 20 20 20 20 20 20 20  |s": [..         |
00000020  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000030  20 20 20 7b 0d 0a 20 20  20 20 20 20 20 20 20 20  |   {..          |
00000040  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000050  20 20 22 74 79 70 65 22  3a 20 22 4c 61 79 65 72  |  "type": "Layer|
00000060  22 2c 0d 0a 20 20 20 20  20 20 20 20 20 20 20 20  |",..            |
00000070  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000080  22 69 64 22 3a 20 22 75  72 67 65 6e 74 5f 76 6f  |"id": "urgent_vo|
00000090  6c 63 61 6e 6f 5f 6e 69  73 68 69 6e 6f 73 68 69  |lcano_nishinoshi|

厳密には https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md で UTF-8N とは定義されていませんし、この仕様で定義される JSON (EMCA-404, RFC8259) 規格でも UTF-8 の採用について BOM の有無には触れられていないため、現在は"潜在的な不具合"としました。

一般に UTF-8 に積極的に BOM を付ける事は推奨されていません。UTF-8 文字コードの実情として JSON = UTF-8N として処理を試みようとするライブラリーも存在します。そのため、 layers.txt に UTF-8N (現在確認済みの他の多くの layers.txt 系ファイル群で採用) と UTF-8 BOM が混在する状況はこうした低レベルの文字コード処理に一定の前提知識を持たない場合、原因の特定が難しい不具合の温床となる可能性があります。)

期待される対応

1. 問題のファイルの文字コードを UTF-8N に変更し、 layers.txt の仕様にも "JSON ( UTF-8N; BOM なし ) 形式" のように定義し仕様の安全も確保します (推奨)
2. 現行の仕様に違反しているわけではなく問題はないと判断し以降事例として現状の混在のまま運用する (非推奨)

• 対象のファイルは github のソースには存在しないため PR できないため、問題のファイルへのアクセス権限のある方、対応をお願いします。
• 現在の他の layers.txt ファイル群が UTF-8N でほとんど統一されている事実からも、おそらく暗黙的に layers.txt の仕様としても UTF-8N を想定していて、この問題のファイルはたまたま何らかの変換処理か操作上のミスから BOM 付きになってしまった状態ではないかと推量し、不具合よりの報告として Issue 化しました。地理院地図を使用するアプリを作る側としても layers.txt が BOM あり/なし混在の仕様では実装に余剰な付帯的コストが必須となってしまう事、 UTF-8 にはそもそも BOM は不要で一般的にも推奨されてはいない事など鑑み、対応(1)で Issue が解決される事を望んでいます。よろしくお願いいたします。

• ご対応頂いた状況から仕様文書側のタスクとして https://github.com/gsi-cyberjapan/layers-dot-txt-spec/issues/7 を起票しました。
• gsimaps 側はファイルから BOM が除去されている事を確認できたため Close します。

ありがとうございます。

状況

• [ ] specifications.md に layers.txt の JSON ファイルの文字コードは UTF-8N; BOM なし 形式を仕様とする事を明示します
  • 例: JSON を定める部分を JSON ( UTF-8N; BOM なし ) 形式 へ変更

この Issue がタスクとして起票された理由

• https://github.com/gsi-cyberjapan/gsimaps/issues/100#issuecomment-690915307

↑を踏まえ、 gsimaps の Authors の意図として "layers.txt の JSON ファイルは UTF-8N" を想定する方針を読み取れます。よってこの Issue は仕様に文字コード UTF-8N を明記するタスクについて Issue 化します。

問題の位置

• https://github.com/gsi-cyberjapan/gsimaps/blob/b84c34667b90fc656163e0955fb2efa715db9048/layers_txt/layers.txt

問題の内容

• https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md の仕様で規定されていない未定義の構造です。

期待される解決方法

1. この layers.txt の仕様を明確に定義し https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md に記述を追加します。
2. (or) gsimaps 側で layers.txt を現在の仕様にあわせる修正を行います。

Related: https://github.com/gsi-cyberjapan/layers-dot-txt-spec/issues/6

問題の位置

• https://github.com/gsi-cyberjapan/gsimaps/blob/b84c34667b90fc656163e0955fb2efa715db9048/layers_txt/layers.txt

↑ gsimaps 実装の layers_txt/layers.txt です。

問題の内容

• ↑で示した gsimaps 実装の layers_txt/layers.txt は layers-dot-txt-spec の仕様で規定されていない未定義の構造です。

期待される解決方法

1. この layers.txt の仕様を明確に定義し https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md に記述を追加します。
2. (or) gsimaps 側で layers.txt を現在の仕様にあわせる修正を行います。

概要

https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md#%E9%81%A9%E7%94%A8%E7%AF%84%E5%9B%B2

（※）ウェブサーバ及びオペレーティングシステムにおける拡張子の登録状況を考慮し、拡張子をtxtとしている。

と記述されているが、

1. この記述が追記された 2015-09-18 時点でも JSON は十二分に普及したフォーマットでした。おそらく、この判断を行った時点でも本質的な問題も「ウェブサーバ及びオペレーティングシステムにおける拡張子の登録状況」ではなく HTTPd に設定すべき MIME (本仕様側ではなくHTTPdの設定課題) というだけの事ではなかったのかな、と思います。
   • https://github.com/gsi-cyberjapan/layers-dot-txt-spec/commit/ca0abfe5c41572222243459828bc46e736938880#diff-ea143bba157429c58a3ba7f3185734dfR6
2. 2020-09 現在、 JSON の扱いが MIME 上問題になる一般的な HTTPd は存在しないし、OSの拡張子登録状況は事実上まったくこの仕様やこの仕様を用いるアプリ実装には関係ないのではないかと思います。

つまり、これただの微妙に迷惑な謎仕様というだけなのではないかと思います。

期待される解決

1. 仕様として .txt ではなく .json に変更する。
2. 仕様から拡張子やOSについての曖昧な謎理由の注記も撤去する。
3. (optional) 格納ディレクトリーの仕様も layers_txt から layers または適当な意図を表すだけの名称に変更する。
4. 現在の URL を直接参照しているサードパーティー製のアプリなどの配慮を明確に決め実施する。
   1. 変更の事前の十分な期間での告知: アクティブな8割以上のサードパーティーアプリの開発者が対応できるように少なくとも1ヶ月以上、ながければ3ヶ月程度前には告知するのが望ましいでしょう。
   2. 変更は gsimaps においては HTTPd で 301 Moved Permanently を ./layers_txt/.txt -> ./layers_txt/.json となるように設定し、可能な限り恒久的にこの設定を保持する
   3. (optional) 格納ディレクトリーも変更する場合はディレクトリーレベルでの 301 Moved Permanently も設定する

もし、謎仕様ではなく有効な具体例が実在する場合は仕様書に明確に「ｘｘがｘｘでｘｘするのは問題なので合理性の観点から .txt 拡張子及び text/plain MIME を用いる」のように理由を列挙し、謎仕様ではないことを明確に示し、将来的に仕様を一般的な設定に合わせられるとすれば一体どのような課題を解決すればよいのか、あるいは事実上解決できないから仕様として諦めるよりほかないのか、自明な表現にします。

問題の位置

• https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md#%E8%A6%8F%E5%AE%9A

↑規定の Layer, LayerGroup 項の a. 属性値 列 と b. デフォルト 列。

問題の内容

a. 属性値 列

1. 用語として「属性値」を用いているのに実際には「型」が記述されています。
   • Layer はかろうじて属性値といえなくもありませんが、その場合も一般的には "Layer" のように文字列値である事がリテラルから自明な表現にします。そのようにしない場合は一般的に仕様書の読者は対象を型としての Layer と読んでしまう可能性がとても高く、仕様書から期待されない意図を読んでしまいます。
   • 推量として Property-value を和訳した語を充てたのだろうと思いますが、コンテキスト上その意味での「属性値」は具体的な値の事を指し、ここで現在表現されている 文字列 や L.TileLayerと同じ はおそらく「型」です。 L.TileLayerと同じ のリンク先でも table では Type = 型 の部分への対応を想定しているような気配ですから、「属性値」では仕様の表現に不具合があります。
2. この列の記述には「型」と「許容される値」が混在してしまっています。一般的に仕様書としては仕様が明確に伝わらないためよくありません。具体的な例としては:
   • Layer は「許容される値」で 文字列リテラルとわかるよう "Layer" とした上で「属性値」ではある
   • 文字列 は「型」なので「属性値」ではありません。
   • URL は「型」としては String かつ、「許容される値」としては "Layer" のような variant の1つではなく URL を満たす文字列値という制約条件(whereされるconditionとか言語によっては Trait や Interface だったりするようなもの)です。
   • true/false は「許容される値」です。これは Boolean 型のすべての variant なので、つまり「型」を間接的に規定しているような具合です。
   • L.TileLayerと同じ は参照先の table では Type しかないので、参照元が「属性値」では不整合で仕様を読む開発者に混乱を招きます。この点からも「型」列への置き換えが良好な選択肢として示唆されます。
3. この列は事実上「型」を定義していますから、「文字列」のような部分的な和訳表現、型の名前の和訳表現ではなく、型のシンボル、キーワードそのものを記述するのが開発者向けの仕様としては望ましいです。「文字列」ではなく String です。もし、「属性値」の制約条件として間接的に記述したい場合は「文字列」ではなく「任意の値」が妥当かもしれません。

b. デフォルト 列

1. コンテキスト上は一般的に、デフォルト = default は未定義 ≈ undefined のプロパティーが参照される事があった場合またはそれに準じる null などの無効値に変えて返される有効な何らかの規程 "値" の事を言います。
   • 例: あるオブジェクトの .hoge プロパティーには Number が設定されている事が期待されるが、 undefined または null または Number 以外の値が入っていた場合は -1 をデフォルト値として読み出す
2. (必須) は"デフォルト値"を表す表現ではないので、その行のプロパティーが undefined を許容するか、しか定義できていません。おそらく、 undefined を許容しない ≈ 省略不可の意図を仕様化したかったであろう事は推量できます。但し、繰り返しとなりますがそれは"デフォルト"で表現される事ではありません。
3. true, "" などは列のヘッダー "デフォルト" から文字通り、おそらく意図通りのデフォルトとして扱うべき値である事を読み取れます。それら自体には問題ありません。しかし、この仕様の記述、デフォルト列の記述方法では、前述(2)のように「デフォルト」と「省略可否」が混用されているため、結果として true, "" などデフォルト値が正しく記述された各行では省略可能なのかが仕様書の読者には不明瞭です。

期待される解決方法

以下のすべてを行います:

a. 属性値 列

1. ヘッダーの「属性値」を「型」へ表現変更します。
2. Layer はその行の型 String にし、「意味」列に Layer である事を示す。値は "Layer" に固定され他の値は許容されない。 のように制約条件の記述を移動する。
   • 値に明確な制約条件の表示が必要な場合は現在は Layer のみなので、わざわざ制約条件の列を table へ追加する必要はないかな、と思います。
   • LayerGroup も同様
3. 文字列 は String に変更
4. URL は String に変更。「意味」列で URL の制約条件を満たさない場合は無効である事が自明なため特に制約条件としてURLを満たす文字列云々の明示は事実上不必要と思います。
5. true/false は Boolean に変更
6. Layer 及び LayerGroupの配列 は [ Layer | LayerGroup ] と記述すれば仕様を必要とする開発者にはフレンドリーです。 [ Layer or LayerGroup ] または [ Layer または LayerGroup ] のように記述しても配列要素の型に相当する variant は仕様を必要とする開発者におそらく明確に伝わります。
   • Note: 一般に、または法律用語などでも「及び」は AND を意図することばとして用いられるため、この表現では「または」 OR として表現のうちの何れかの意図が明瞭にするのがよいと思います。

b. デフォルト 列

1. 「省略可否」列を追加し、その行のプロパティーが undefined (≈省略) を仕様として許可するか読者が明確に判断できる表現を行います。列名はECMAScript開発者向けに正確さを優先したい場合は「undefined の許容」のような表現としてもよりわかりやすいかもしれません。
   • この列に記述する内容は 可/否 または 可/不可 のような表現にします。
   • 現在「デフォルト」列で (必須) が設定されている行はおそらく、この列に 不可 と記述して表現を移動する事になります。
   • 現在「デフォルト」列で （entries属性かsrc属性のいずれかが必須） が設定されている行は 可 ( 但し entries または src の何れかは有効な事) のような記述になります。
2. 「デフォルト」列の内容の変更
   • 現在 (必須) が設定されている行は n/a となりますので空欄または n/a 表記とします。
   • undefined または規定された内部表現の型として有効ではない場合 (≈ null, Number が期待される行で "hoge" 文字列値が入っていたなど)
3. 「デフォルト」を読み出す条件を明確に定義し、仕様に追加します。
   • undefined -> default として扱うか
   • null -> default として扱うか
   • 期待しない内部表現型 -> default として扱うか
   • 期待しない内部表現型だが型の変換が有効な場合 -> 型の変換を許容し有効な値とするか、型の変換を許容せず default として扱うか

c. その他の些細な修正

1. 「属性名」、「型」、「デフォルト」はコードとして有効なキーワードや値に準じるものなので、 markdown のソースとしてはバッククォートで囲み意図を明確に伝えやすい表現が行われるように修正します。 (JSON=ECMA-404では厳密には String 表現なので "type" のようにはなりますが、これは便宜上 type としても開発者が意図を読み違える事はまずありません)

問題の位置

• https://github.com/gsi-cyberjapan/gsimaps/blob/09796daa6322655ac2603c96b3904fe848539220/layers_txt/layers_topic_20200703oame.txt#L7

↑のように gsimaps では open プロパティーが実用されています。しかし、 open の仕様は定義されていません。

期待される対応

1. open について仕様を追記

Target

• body_json function of Response struct
  • https://docs.rs/surf/1.0.3/surf/struct.Response.html#method.body_json

Detail

• body_json function could not convert from an UTF-8 BOM source file

Repro

1. Prepare an UTF-8 BOM JSON file.; BOM bytes is 0xef 0xbb 0xbf.
2. Deploy the JSON file and run a httpd.
3. surf::get and body_json => SerdeJsonError(Error("expected value", line: 1, column: 1))

Workaround

// It will be the error if response has the BOM.
// let my_struct = my_response.body_json::<MyStruct>();

1. Raw implementation:

let my_response_body_string = my_response.body_string();
let my_response_body_string = if my_response_body_string.starts_with("\u{feff}") { &my_response_body_string[3..] } else { &my_response_body_string[..] };
let my_struct: MyStruct = serde_json::from_str(my_response_body_string);

2. Or use strip_bom:

use strip_bom::StripBom;

let my_response_body_string = my_response.body_string();
let my_response_body_string = my_response_body_string.strip_bom();
let my_struct: MyStruct = serde_json::from_str(my_response_body_string);

Notes:

1. This error is SerdeJsonError, but a character encoding issue might not issue of serde_json or serde crate. Because, serde_json is designed for UTF-8 stream body only, not for a file directly or BOM. Thus, I think the BOM issue is not a serde_json or serde issue, it is a library user side issue. If you authors think it is not a surf issue, it is a serde_json or serde issue then I'll throw the issue to serde_json or serde repos.
   • serde_json::from_reader (for an IO stream, ≈ Input UTF-8 character stream)
   • serde_json::from_str (≈Input UTF-8 character stream).
2. It might be not a std::string::String issue because https://github.com/rust-lang/rfcs/issues/2428
3. JSON (ECMA-404, RFC8259) is defined the character encoding to use only UTF-8, but the BOM is not defined. Thus, JSON file with UTF-8 BOM is not an invalid in specification. Yes, of course I was think nobody who use UTF-8 BOM to JSON file before today, but a Japanese government institution used it. 🥺

不具合の位置

• https://github.com/gsi-cyberjapan/gsimaps/blob/bed0467e2c9ca5c546777832ecc5d57126144251/layers_txt/layers6.txt#L3809

↑ここから src で参照が定義されている https://maps.gsi.go.jp/sar/layers_txt/layers_alos2_vol_nishinoshima.txt に問題があります。

note: 但し、問題のあるファイル layers_alos2_vol_nishinoshima.txt は地理院地図として配置済みの状態ですが gsimaps のソースコードには存在しません。 commit 漏れであればそちらもご対応下さい。

不具合の内容

このファイルの先頭には 0xEE 0xBB 0xBF からなる UTF-8 文字コードに対する BOM が埋め込まれています。

00000000  ef bb bf 09 7b 0d 0a 20  20 09 22 6c 61 79 65 72  |....{..  ."layer|
00000010  73 22 3a 20 5b 0d 0a 20  20 20 20 20 20 20 20 20  |s": [..         |
00000020  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000030  20 20 20 7b 0d 0a 20 20  20 20 20 20 20 20 20 20  |   {..          |
00000040  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000050  20 20 22 74 79 70 65 22  3a 20 22 4c 61 79 65 72  |  "type": "Layer|
00000060  22 2c 0d 0a 20 20 20 20  20 20 20 20 20 20 20 20  |",..            |
00000070  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00000080  22 69 64 22 3a 20 22 75  72 67 65 6e 74 5f 76 6f  |"id": "urgent_vo|
00000090  6c 63 61 6e 6f 5f 6e 69  73 68 69 6e 6f 73 68 69  |lcano_nishinoshi|

厳密には https://github.com/gsi-cyberjapan/layers-dot-txt-spec/blob/master/specifications.md で UTF-8N とは定義されていませんし、この仕様で定義される JSON (EMCA-404, RFC8259) 規格でも UTF-8 の採用について BOM の有無には触れられていないため、現在は"潜在的な不具合"としました。

一般に UTF-8 に積極的に BOM を付ける事は推奨されていません。UTF-8 文字コードの実情として JSON = UTF-8N として処理を試みようとするライブラリーも存在します。そのため、 layers.txt に UTF-8N (現在確認済みの他の多くの layers.txt 系ファイル群で採用) と UTF-8 BOM が混在する状況はこうした低レベルの文字コード処理に一定の前提知識を持たない場合、原因の特定が難しい不具合の温床となる可能性があります。)

期待される対応

1. 問題のファイルの文字コードを UTF-8N に変更し、 layers.txt の仕様にも "JSON ( UTF-8N; BOM なし ) 形式" のように定義し仕様の安全も確保します (推奨)
2. 現行の仕様に違反しているわけではなく問題はないと判断し以降事例として現状の混在のまま運用する (非推奨)

• 対象のファイルは github のソースには存在しないため PR できないため、問題のファイルへのアクセス権限のある方、対応をお願いします。
• 現在の他の layers.txt ファイル群が UTF-8N でほとんど統一されている事実からも、おそらく暗黙的に layers.txt の仕様としても UTF-8N を想定していて、この問題のファイルはたまたま何らかの変換処理か操作上のミスから BOM 付きになってしまった状態ではないかと推量し、不具合よりの報告として Issue 化しました。地理院地図を使用するアプリを作る側としても layers.txt が BOM あり/なし混在の仕様では実装に余剰な付帯的コストが必須となってしまう事、 UTF-8 にはそもそも BOM は不要で一般的にも推奨されてはいない事など鑑み、対応(1)で Issue が解決される事を望んでいます。よろしくお願いいたします。

対象の位置

"LayerGroup" 項 の "属性名" id の デフォルト 列 の (必須) の記述

不具合と推量する内容

• 現在の記述: (必須)
• 正しいかもしれない記述: "" またはそもそも LayerGroup に id は仕様上定義されない

推量に至る経緯

• gsimaps での実装 layers_text/layers1.txt の LayerGroup に id が存在しない。
• gsimaps での実装 layers_text/layers_topic_20200703oame.txt の LayerGroup に id が存在しない。

gsimaps でのすべての Layers.txt の実装における LayerGroup の id について確認してはいませんが、 Layers1.txt 及び Layers.txt で top が true に設定されている layers_topic_20200703oame.txt のように主要または目立つ実装が仕様と異なる事から、仕様または仕様の記述または実装の何れかに不具合があると推量します。

期待される対応

1. "specifications.md" の記述上の誤りで、ほんらい仕様では LayerGroup に id は定義されない場合 => 記述を修正した上で告知を出して周知する
2. 仕様の不具合で LayerGroup に id は定義されないはずだったが定義される事になってしまっていた場合 => 仕様を修正し告知
3. 仕様としては LayerGroup の id は必須で gsimaps での実装に不具合がある場合 => gsimaps へ修正 Issue を立て、この Issue へリンクし、この Issue は Close して対応を gsimaps 側へ引き継ぐ
4. 仕様としては LayerGroup の id は必須だが、主要な実装で未定義で使用されている状況に対応し仕様側を修正 => 仕様を更新し LayerGroup の id を (必須) から "" または null, undefined 等の無効値を デフォルト の仕様に修正し、告知

対象の位置

"Layer" 項 の "属性名" 列の "styleurl" 行

不具合と推量する内容

• 現在の記述: "styleurl" // lowercasenonseparator
• 正しいかもしれない記述: styleUrl // camelCase

推量に至る経緯

• 他のフィールドはすべて camelCase が使用されています。

期待される対応

1. 仕様の記述が表記として誤っているだけの場合 => styleUrl へ修正 (推奨)
2. 仕様の不具合として修正すべきだが実用状況から直ちに修正はできない場合 => 修正予定を設定し告知 or 集成予定は設定せず styleurl を現行仕様とするバージョン範囲を明確に設定 (暫定措置としてやむを得ない場合は推奨)
3. case-insensitive を仕様に追加し、 styleurl でも styleUrl でも、あるいは StYleuRL であれ仕様上許容される揺らぎとし、必要に応じて処理系で正規化される実装を期待する事にする (非推奨; 本リポジトリー、仕様としては解決するが仕様に対して完全な実装を行いたい場合に余剰の付帯的コストが増えてしまいます)

参考

• gsimap における実用状態の検索: https://github.com/gsi-cyberjapan/gsimaps/search?q=styleurl&unscoped_q=styleurl

さしあたり、対応方針が不明なので PR はしません。

For example:

1. EPSG:31256 ; MGI / Austria GK East 👉 https://epsg.io/31256
2. EPSG:6680; JGD2011 / Japan Plane Rectangular CS XII 👉 https://epsg.io/6680

These are not a UTM CRS definitions. Could you show me a crs: definition example?

    let source_coordinates = CoordinateSource::CoordinateBuf(Box::new(
        CoordinateBuf {
            data: vec![(x, y)],
            crs: ???? // <-- Help, please.
            ellipsoid: ellipsoid,
        }
    ));

I got it. Thanks for the answer.

• "citis" => "cities" 🤣