railwayレイヤの路線と駅のコードrtCode,staCodeについて、具体的なコードと駅名の対応表はどこにありますでしょうか。

提供実験の取り組み大変ご苦労様です。
さて、道路のデータについて2点ほど気づいた点があります。
私の処理の間違いかも知れませんし、元にした図面にも起因するのかとも思います。

１．レベル16の道路データ2701<=ftcode<= 2734のデータをいくつかの都道府県データについて眺めました。
ところどころ非常に微小ではあるものの、不連続があります。タイル間の不整合なのかそうでないのかわかりませんが、タイル間のものもあるようです。
QGIS3.10LTRでPBFを直接開いてから、もしくはGDALで変換処理してからの気づきですので、もしかするとソフトやプログラムの問題かもしれません。

２．地物等の属性一覧での定義表にないデータがある場合がある
地物等の属性一覧はhttps://maps.gsi.go.jp/help/pdf/vector/attribute.pdfを参考にしました。
共通属性と個別の属性などがありますが、この表にない数値が出現する場合があります。
例）PDF　5ページ目のmedSect
表では0、1、99となっていますが、2~18の間の数値が入っている場合がありました。

以上です。提供実験であることは重々承知しております。
今後もこのような素晴らしい取り組みを続けていただくためにも、微力ながら応援してまいります。

自サイトにcloneして動かしてみた所、一部のファイルで、cross originのエラーが出ます。
response headerに access-control-allow-originが設定されていないようです。

対象ファイルは、
https://maps.gsi.go.jp/layers_txt/layers1.txt
等と
https://maps.gsi.go.jp/xyz/noto-jp/NotoSansCJKjp-Regular/
以下のファイル(Webフォント?)

で発生しています。ベクトルタイルデータそのものは大丈夫のようです。

不具合という訳ではないのですが、データを見ていて気になった点があります。
waterareaのデータが妙に大きいと思って見てみましたが、エリアがだいぶ重複してポリゴン化されてるようです。試しに半透明で塗ってみましたが、堀に比べ川の部分が濃くなっていて、重複して描画されていることがわかります。

これはこういうものなのでしょうか。

style.json について以下の説明があり、リンク先として https://docs.mapbox.com/mapbox-gl-js/style-spec/ が指定されています。

地図のデザインを規定しているファイル。Style Specificationに従って記述されています。

Style Specification では少なくともルートオブジェクトのプロパティとして version sources layers が必須とされているのですが、 https://maps.gsi.go.jp/vector/data/std.json を始めとした各 style.json ファイルには version sources layers といったキーワードは含まれておらず、とくに Style Specification に準拠していないように思われます。

説明の誤りでしょうか？（実際はなんらかの独自仕様に従っている？）

技術的な（そしておそらく採用が困難であろう）提案です。参考意見としてお聞きください。

現状

現在、地理院地図VECTOR の提供する MVT ファイルでは、 symbol, label, road, boundary といった layer-name がセットされています。
しかし、これらの layer-name は「大分類」に相当するもので、 layer-name が決まったからといって即座にそこに所属する feature のスタイルが決まる、という性質のものではないと考えています。

以下は gsimaps-vector-style-spec-converter で出力した標準地図の style.json のレイヤー定義の冒頭部分ですが、
ここでは、 filter の中で ftCode が 4202 であるようなもの に絞り込むこんだ上で、それに対してスタイルを適用、という手法が取られています。

    "layers": [
        {
            "id": "gsibv-vectortile-layer-1",
            "type": "line",
            "source": "gsibv-vectortile-source-1-4-16",
            "source-layer": "structurel",
            "metadata": {
                "layer-id": "layer-29",
                "title": "坑口",
                "path": "構造物-坑口",
                "added": 1
            },
            "minzoom": 14,
            "maxzoom": 17,
            "filter": [
                "all",
                [
                    "in",
                    "ftCode",
                    4202
                ]
            ],
            "layout": {
                "line-cap": "square",
                "visibility": "visible"
            },
            "paint": {
                "line-color": "rgba(100,100,100,1)",
                "line-width": 1.5
            }
        },

同 style.json を調べてみると、（２件の例外があったものの） 基本的にはすべての layer 定義に対して ftCode による絞り込みを行う filter が設定されています。

スタイリングを行う作業者の意識としても、 より具体化された分類である ftCode （＋それぞれの独自属性） に対してスタイルを設定する、というのが自然な感覚だと思っています。

提案

もし仮に、 MVT の layer-name に対して ftCode がセットされているものとします。

すると、上記のスタイルは source-layer への指定だけで完結し、 filter は不要になります。

    "layers": [
        {
            "id": "gsibv-vectortile-layer-1",
            "type": "line",
            "source": "gsibv-vectortile-source-1-4-16",
            "source-layer": "4202",
            "metadata": {
                "layer-id": "layer-29",
                "title": "坑口",
                "path": "構造物-坑口",
                "added": 1
            },
            "minzoom": 14,
            "maxzoom": 17,
            "layout": {
                "line-cap": "square",
                "visibility": "visible"
            },
            "paint": {
                "line-color": "rgba(100,100,100,1)",
                "line-width": 1.5
            }
        },

メリット

• style.json の記述が簡潔になる
• style.json のファイルサイズが小さくなり、ファイル転送のオーバーヘッドを削減できる
• filter 処理が不要になることによる、レンダリング速度の向上
• 個々の MVT ファイルから symbol, label 等の既存のレイヤー名を除去できるので、MVT ファイルの軽量化・通信量削減効果がある

デメリット

• 既存の symbol, label 等を使用しているユースケースに対して破壊的変更である点
• すべての MVT ファイルの変更およびすでに作成された style.json に対する変更が必要である点

まとめ

技術的には合理的、と思うのですが経済的には合理的ではないかもしれません。
もしも大規模な改修がある場合に思い出していただければ、と思います。

「地物コード及び表示ズームレベル一覧」において道路のftCodeの下位2桁が01-04しかなくダブっていますが、11-14,21-24,31-34も実際のデータに存在するようです。表の間違いではないでしょうか。

タイル内の各地物に id がセットされていないため、たとえば map.setFeatureState() などのメソッドが動作しないと思われます。

参考:

• setFeatureState - feature.id が必須になっている。
• Vector tile specification - わかりにくのですが、「Final vector tile」に id という要素があります。

必須では無いようですが、値があれば Mapbox GL JS のメソッドがすべて動作するのであったほうがいいかなと思いご報告しました。

以下の資料「地物コード及び表示ズームレベル一覧」にて、道路で 2200 番台と 2400番台の ftCode を持つ地物がズームレベル 17 となっていますが、ズームレベル 16 でも存在しておりました。

https://maps.gsi.go.jp/help/pdf/vector/dataspec.pdf

ズームレベル14-16のページでの記載内容

2200番台と2400番代に関する記述がない。

ズームレベル17のページでの記載内容

これは、仕様書の方の記載漏れという理解で正しいでしょうか？ それともタイルの方の誤りでしょうか？（ズームレベル16から2200番台と2400番台のftCodeをもつ地物が削除される可能性がある？）

dataspecには存在せずblank2.jsonには含まれているデータがいくつかあるようです。これは意図したものでしょうか？
以下に見つけた範囲での一覧を示します。blank2.json以外のスタイルファイルについては調べられていません。またこの他にも差分があるかもしれません。

1. 「主要な道路トンネル」ftCode=52702
2. 「その他の特定地区界」ftCode=6111

zoom8-10で、利根川がriverではなくlakeのレイヤに入っています。これは意図したものでしょうか？

個別の地図の内容についてここでissueを挙げるのは適切ではないように思いますが、他に報告すべき場所があれば教えていただきたく思います。

Source-layer symbolのデータにgcpCodeFlagがあるのですが、これに対する説明の記載を見つけることができません。
電子基準点で付属金属標の位置＆高さのデータが1で、電子基準点の位置＆高さのデータがが0、その他はNullかと思うのですが、公式にはどのように0と1を定義されているのでしょうか？

https://maps.gsi.go.jp/help/pdf/vector/attribute.pdf
ではgcpCodeについても記載がないですし、https://fgd.gsi.go.jp/otherdata/spec/FGD_DLFileSpecV3.0.pdf
でもgcpCodeは基準点コードとありますが、gcpCodeFlagはありません。

データを見る限りだと以下の通りとなっています。
・ftcode＝7101の電子基準点で0か１（その他のftcodeではNull）
・gcpNameで（付）とあるものが1でそうでないものが0
・gcpNameで（付）とあるものとでそうでないものの位置は同じ、標高だけが違う、標高も5m程度（付）のほうが低い

以上です、検索してみてもgcpCodeFlagは2件しかヒットせず、データそのものがでてきてしまうので、お問い合わせさせていただいた次第です。よろしくおねがいします。

情報提供と質問です。
2019-08-29 にリリースされた mapbox-gl-js v1.3.0 で text-writing-mode というレイアウトプロパティが導入されました。vertical というキーワードを指定するとテキストを縦書きで表示することができるようです。

https://docs.mapbox.com/mapbox-gl-js/style-spec/#layout-symbol-text-writing-mode

現在の地理院地図 VECTOR は mapbox-gl-js v 0.52.0 を使用しており、縦書きには独自のプラグインで対応していると思うのですが、今後、例えば正式運用の際に mapbox-gl-js v1.3.0 にバージョンアップしてスタイルも刷新される、といったことは予定したほうがよいのでしょうか？あるいは 0.52.0 を継続使用していくような方針でしょうか？

細かい点ですが、
地物の属性一覧の鉄道の項目、sngDblはsnglDblの誤りと思われます。

国土地理院ベクトルタイル提供実験の説明によれば、機械判読可能なオープンデータの提供をその趣旨の一つとされているとのことですので、オープンデータとして基本の要件といえるベンダ中立性を担保するという文脈でのISSUEとなります。

本リポジトリのREADMEによると、データはMapbox社が提唱するVector tile specificationに基づいた、pbf形式で配信されているとされています。
同仕様書によれば、pbf形式を判読するためには、google 社が提唱するgoogle protocol bufferに基づく読解が必要とされ、このために下記の.protoファイルが提供されています。
https://github.com/mapbox/vector-tile-spec/blob/master/2.1/vector_tile.proto
そこで、このファイルを用いてpbfファイルを読み取るためのツールとして、同Mapbox社が提供している
pbf.jsを用いることができるそうですので、これを用いて実際に解読を試みてみましたがうまく解読できていません。

mapbox社のleafletに依存しない、独立したデータの読み取り方法の具体的なオープンソース開示をいただければと思います。おそらくVector tile specificationの文書が同社の内部的にアウトデートしているなどの理由で、.protoファイルのバージョンが違うもしくは何らかの独自拡張が施されているのではないかと推測しますが、leafletの解析は当方のスコープ外のためこれ以上の調査はしていません。

なお、当方で具体的に実施し、読み込みができなかった手順を以下に記します。

mapbox_vector_tile仕様データの読み取りライブラリの構築。(vector_tile.protoは、上記vector-tile-specリポジトリの最新バージョンと思われるスペックにあるファイル)

npm install -g pbf
pbf vector_tile.proto --browser > mapbox_vector_tile.js

読み取りのテスト

<html>
<script src="https://unpkg.com/[email protected]/dist/pbf.js"></script>
<script src="./mapbox_vector_tile.js"></script>

<script>
onload=async function(){
	var data = await getPbf();
	console.log(data); // 空のデータとなる
}
async function getPbf(){
	var url ="33024-33279.pbf";
	let response = await fetch(url);
	if (response.ok) {
		var bufferRes = await response.arrayBuffer(); // arrauBufferは作られている
		pbf = new Pbf(new Uint8Array(bufferRes));
		var obj = Tile.read(pbf); 
		return obj;
	} else {
		console.error("error:", response.status);
	}
};
</script>
<body>
</body>
</html>

dataspec.pdf / 地物コード及び表示ズームレベル一覧 を元に、たとえば本来存在しない ftCode を指定していないか、とか、本来「線」であるのに「点」のスタイルをアサインしていないか、といったようなスタイルのバリデーションのようなことをできないかと思っています。

そのためには、dataspec.pdf のデータを何らかの方法でプログラムにロードできるように加工しないといけないのですが、現状の PDF から機械可読なデータを作成するのはあまり簡単ではありません。（仮にPDF から表形式への機械的変換がうまくいったとしても、セルの連結解除がかなり扱いづらい点、またページごとにデータ項目が微妙に異なるので人力での正規化が必要な点が課題と思っています）

現状の dataspec.pdf に加えて、 dataspec.csv のような機械可読形式でデータ仕様を提供していただくことは可能でしょうか？

以下はズームレベル4〜7(地物)の一部とズームレベル4〜7(注記)の一部を手作業で表形式データとして作成してみたものですが、このような、ズームや地物注記によらずに共通化したレコードレイアウトの CSV 形式でデータが入手できると大変助かります。
https://gist.github.com/frogcat/058c57ce3aed169594c1cbb77b16e9db#file-dataspec-csv

地理院からダウンロードした任意のpbfをprotocol bufferで読み取ると，
レイヤ名が道路のstring_valueがところどころ文字化けしています．
具体的には，3m未?や市区町?道等など，一部分が0xEFBFBDになっています．
(0xEFBFBDはutf-8化に失敗している証拠)
もちろん，protocol bufferが原因ではなく，生のpbfをバイナリ解析すると該当部分が0xEFBFBDとなっていることからpbfに問題があるといえます．
確認および修正願えますでしょうか．
よろしくお願いいたします．

質問で恐縮ですが、ベクトルタイル用の mokuroku.csv.gz に該当するものは提供されていないのでしょうか？
https://github.com/gsi-cyberjapan/mokuroku-spec

この実験は地図サービスだけではなく地図データの配信という側面を持つものと認識しています。加えてmapbox leafletに強く依存した配信は中立性の観点から課題を持つと考えます。

先日#14
で指摘したpbfデータはmapbox leafletに依存しない読み取り方法が確立しているものと思いますが、
スタイリングについてはまだ課題を持ったままと考えます。
(人間可読の)pdfのドキュメントでスタイリングのポリシーが提示されている一方、実装物についてはmapbox leaflet専用で提供されており、同実装の中立性がない。

そこで提案ですが、より簡易なスタイリングであれば、geoJsonに対して、ベンダに依存しない複数の実装が存在する仕様があると考えます。それは、gsi-cyberjapanでも類似の仕様が規定されていることも含めてgeojson(のproperties)にスタイルを埋め込む仕様です。
具体的には以下の二つの仕様が候補になると考えます。（できればこれら二つの仕様の統合化が好ましいです）
これらの仕様に準拠したスタイリングをgeojsonデータに対して実行できるコード・データなどの実装が公開されることが好ましいと考えます。もちろんこれらの仕様の範囲では従来のスタイリングと比べて不十分な点があり得ると考えますが、実装容易性とより緻密なスタイリングにはトレードオフが又あると考えますのでシンプルなスタイリングは中立性を高める意味でも重要と考えます。

https://github.com/gsi-cyberjapan/geojson-with-style-spec

https://github.com/mapbox/simplestyle-spec

https://github.com/gsi-cyberjapan/gsimaps-vector-experiment/blob/7bc33da1b80f888dafa159703373b4cc921ecd97/data/std.json

高速道路番号のアイコン内の文字を描画する場合、text-fieldは"uRno"が正しいと思ったのですが、"nRno"となっている箇所がありました。間違っていないでしょうか？

※試験公開していただいているhttps://maps.gsi.go.jp/vector/は正しく描画されていそうです

MacのRetinaディスプレイのような高DPI環境で「画像として保存」を使用すると、地図上で指定した領域と画像として出力される領域が異なるものになってしまうようです（下図参照）。なお、これは「表示されている範囲全体」でも「範囲を固定」でも発生します。おそらく devicePixelRatio を考慮した切り出しになっていないのではないかと思います。

こんにちは。鉄道や道路など属性を多く持つ地物について、公開されているstyle.jsonのレイヤーのfilterがどのように決定されているか公開されていますでしょうか。

こちらのdataspecを見ると、例えば鉄道はすべて単一のレイヤーに入っています：
https://maps.gsi.go.jp/help/pdf/vector/dataspec.pdf
style.jsonでは、rtCodeなど以下に記載されている属性値に応じてそれをフィルターしたものが各レイヤーとして分割されているという認識です：
https://maps.gsi.go.jp/help/pdf/vector/attribute.pdf

しかし、例えばblank.jsonにおいて、「市区町村道・その他」においては「通常部（有料）」というtollSectで絞り込まれたレイヤーが存在する一方、「県道」においてはそのようなレイヤーが存在しません。
各style.jsonにおいて、具体的にどのような基準でレイヤーを分割しているかの仕様などがもし公開されていれば大変助かるのですが、いかがでしょうか。