gsi-cyberjapan / gsimaps-vector-experiment Goto Github PK

View Code? Open in Web Editor NEW

94.0 17.0 12.0 11.13 MB

地理院地図Vector（仮称）提供実験のソース

JavaScript 92.06% HTML 1.82% CSS 6.11%

gsimaps-vector-experiment's Introduction

地理院地図Vector（仮称）提供実験

ベクトルタイルの仕様

本提供実験によるベクトルタイルは、地理院タイル（ラスタ）と同じ方式で配信します。 https://cyberjapandata.gsi.go.jp/xyz/{t}/{z}/{x}/{y}.{ext}

本提供実験によるベクトルタイルは、タイルに分割したVector tile specification形式のファイル群。
拡張子は「pbf」。

ズームレベルについて

本提供実験によるベクトルタイルにおけるズームレベル（{z}）は、現在「地理院地図」で提供している地理院タイル（ラスタ）（ https://maps.gsi.go.jp/development/ichiran.html ）のズームレベルと同一ではありません。

画面上で同じ大きさで表示される際のズームレベルは、ベクトルタイルにおける数値が、地理院タイル（ラスタ）のズームレベルと比べて1小さい数値となります。そのため、ベクトルタイルにおけるズームレベル11のデータは、ズームレベルが12の地理院タイル（ラスタ）と同じデータを用いて作成しています。

また、ベクトルタイルにおいて画面に表示されるタイルの大きさは、地理院タイル（ラスタ）でズームレベルが1大きい（大きさが小さい）タイルの4枚分に相当します。

対応するズームレベルの範囲
本実験で提供するベクトルタイル	地理院タイル（ラスタ）
4～7	5～8
8～10	9～11
11～13	12～14
14～16	15～17
17	18

タイル一覧

提供実験中のデータであるため、URL やデータ構成、データの内容（属性の有無や名称等）が変わる可能性があります。

地理院地図Vectorで表示
URL	https://cyberjapandata.gsi.go.jp/xyz/experimental_bvmap/{z}/{x}/{y}.pbf
データソース	数値地図（国土基本情報）- 地図情報　等
ズームレベル	4～16 ※ズームレベル17の情報は、ズームレベル16に含んだうえでオーバーズームして表示
提供開始日	2019年7月29日（関東の一部地域） 2020年3月19日（全国）
データ更新情報	2023年7月1日時点 ※最新の状況が反映されていない場合があります。

属性等の仕様詳細

地物コード及び表示ズームレベル一覧

PDF版　 Excel版
地物等の属性一覧

PDF版　 Word版

mokurokuの提供

本提供実験によるベクトルタイルについて、「地理院タイル目録」を試験提供します。更新は不定期です。
URLは以下のとおりです（70MB程度の大きなファイルですのでネットワーク環境にご注意ください）。 https://cyberjapandata.gsi.go.jp/xyz/experimental_bvmap/mokuroku.csv.gz
「地理院タイル目録」の仕様については、mokuroku-specをご覧ください。

style.json

地図のデザインを規定しているファイル。Style Specificationをベースにしたうえで、若干の拡張を施しています。
仕様については、以下のファイルからご確認いただけます。
- 地理院地図Vector（仮称） style.jsonの仕様
※地理院地図Vector（仮称） style.jsonの仕様は検討中のものであり、今後変更する可能性があります。
2020年3月19日現在の地理院地図Vector「おすすめの地図」から閲覧できるstyle.jsonは下表のとおりです。
下表のリンクを右クリックし、「名前をつけて保存」からダウンロードすることができます。
保存したファイルは、地理院地図Vectorの「地図デザインの追加」-「地図デザインファイルを開く」から読み込むこともできます。

標準地図	淡色地図	白地図
	写真＋注記の注記	大きい注記の地図
標準地図2	淡色地図2	白地図2

※　「2」がついているものは、若干初期表示は遅いが、道路の立体交差を表現しているものです。

この他、地理院地図の「標準地図」にできる限り表現を近づけたstyle.jsonは下記リンクからダウンロードできます。このファイルも、「地図デザインの追加」-「地図デザインファイルを開く」から読み込むことができますが、初期表示に長い時間がかかりますので、ご注意ください。
- 地理院地図の「標準地図」にできる限り表現を近づけたstyle.json

地理院地図Vector（仮称）

地理院地図Vector（国土地理院が運営しているもの）：https://maps.gsi.go.jp/vector/
地理院地図Vector（本レポジトリを用いたデモ）：https://gsi-cyberjapan.github.io/gsimaps-vector-experiment/
地理院地図Vectorは、Mapbox GL JSをベースに構築されています。

提供の位置づけ

国土地理院ベクトルタイル提供実験におけるデータの提供の位置づけは次のとおりです。

本提供実験は、ベクトルタイル提供における技術的・施策的課題を国土地理院が把握するとともに、外部からの技術的な提案を受け取り、外部との技術的な議論を通じてベクトルタイルの適切な提供方法を研究開発することを目的とするものです。
本提供実験の期間は、2019年7月29日から本提供実験終了までとなります。
本提供実験のデータは、国土地理院コンテンツ利用規約に従って利用できます。データを利用する際は、「国土地理院ベクトルタイル提供実験」などと、出典の明示を行ってください。
本提供実験のベクトルタイルは基本測量成果と位置付けているものではありませんが、基本測量成果としての提供を検討するにあたって、提供を行うものです。
本提供実験の利用により生じた損失及び損害等について、国土地理院はいかなる責任も負わないものとします。

履歴

2019-07-29 提供実験開始。提供範囲は20万分1地勢図「宇都宮」「水戸」「甲府」「東京」「千葉」の範囲（縮尺によっては、その周辺も提供）
2019-08-07 中心十字線のON/OFF切替え機能の追加
2019-08-09 最小表示ズームレベルを4に変更。また、ズームレベル4から情報を表示。
2019-08-09 描画ハッチ等の改良
2019-08-27 注記が重なった場合、ふりがなを優先的に消す仕様に変更
2019-08-27 エラー修正（ズームレベル13で市区町村道が表示できないエラー）
2019-09-03 エラー修正（一部データの文字化けに伴い注記や道路が描画されないエラー）
2019-11-19 エラー修正（ポリゴンデータの中抜きが表現されないエラー）
2020-03-19 印刷、作図、自分で作る色別標高図、現在位置表示等の機能を追加
2020-03-19 全国データ公開開始
2020-09-18 style.jsonの仕様を公開
2021-02-08 全国データを2020年11月1日時点のデータに更新
2021-03-22 画像として保存、方位記号の表示／非表示の切替え等の機能を追加
2021-05-17 全国データを2021年4月1日時点のデータに更新
2021-08-23 全国データを2021年7月1日時点のデータに更新
2021-11-16 全国データを2021年10月1日時点のデータに更新、地物コード及び表示ズームレベル一覧を更新
2022-03-01 全国データを2022年1月1日時点のデータに更新
2022-06-07 全国データを2022年4月1日時点のデータに更新
2022-09-13 全国データを2022年7月1日時点のデータに更新
2022-11-25 全国データを2022年10月1日時点のデータに更新
2023-02-27 全国データを2023年1月1日時点のデータに更新
2023-06-06 全国データを2023年4月1日時点のデータに更新
2023-08-15 全国データを2023年7月1日時点のデータに更新

gsimaps-vector-experiment's People

Contributors

Stargazers

Watchers

Forkers

frogcat sengine-xyz tattii seotaro wata909 snakano0121 hisahisabanbi 75ha kapurikoyamanocat ryocat yoichigmf qchizu

gsimaps-vector-experiment's Issues

dataspec.pdf の機械可読形式データについて

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

地物の属性一覧ドキュメントの誤り

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

`ftCode` に関する記載の誤り

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

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

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

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

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

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

pbfデータのmapbox leaflet独立な読み込み方法の開示について

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

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

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

waterareaのダブリについて

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

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

mapbox, leafletへの依存を減らしたスタイリング

この実験は地図サービスだけではなく地図データの配信という側面を持つものと認識しています。加えて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

道路のftCode

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

MVT の layer name として ftCode を使用するのはどうか？

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

現状

現在、地理院地図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 に対する変更が必要である点

まとめ

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

feature.id がタイルにセットされていない

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

参考:

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

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

道路の接合と道路凡例のコードについて

提供実験の取り組み大変ご苦労様です。
さて、道路のデータについて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の間の数値が入っている場合がありました。

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

Source-layer symbolに含まれるgcpCodeFlagの意味について

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件しかヒットせず、データそのものがでてきてしまうので、お問い合わせさせていただいた次第です。よろしくおねがいします。

ベクトルタイル用の `mokuroku.csv.gz` は提供されていないのでしょうか？

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

style.jsonでのレイヤーのfilterの決定基準について

こんにちは。鉄道や道路など属性を多く持つ地物について、公開されている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において、具体的にどのような基準でレイヤーを分割しているかの仕様などがもし公開されていれば大変助かるのですが、いかがでしょうか。

道路のstring_valueが文字化け？

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

style.json が Style Specification に従っていない

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 に準拠していないように思われます。

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

高DPI環境での画像出力について

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

一部のファイルでcross originエラー

自サイトに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フォント?)

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

縦書きテキストのためのスタイル指定

情報提供と質問です。
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 を継続使用していくような方針でしょうか？

地図内容について

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

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

路線コード駅コードについて

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