gsi-cyberjapan / gsimaps-vector-experiment Goto Github PK
View Code? Open in Web Editor NEW地理院地図Vector提供実験のソース
地理院地図Vector提供実験のソース
細かい点ですが、
地物の属性一覧の鉄道の項目、sngDblはsnglDblの誤りと思われます。
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 に準拠していないように思われます。
説明の誤りでしょうか?(実際はなんらかの独自仕様に従っている?)
railwayレイヤの路線と駅のコードrtCode,staCodeについて、具体的なコードと駅名の対応表はどこにありますでしょうか。
国土地理院ベクトルタイル提供実験の説明によれば、機械判読可能なオープンデータの提供をその趣旨の一つとされているとのことですので、オープンデータとして基本の要件といえるベンダ中立性を担保するという文脈での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>
質問で恐縮ですが、ベクトルタイル用の mokuroku.csv.gz
に該当するものは提供されていないのでしょうか?
https://github.com/gsi-cyberjapan/mokuroku-spec
zoom8-10で、利根川がriverではなくlakeのレイヤに入っています。これは意図したものでしょうか?
個別の地図の内容についてここでissueを挙げるのは適切ではないように思いますが、他に報告すべき場所があれば教えていただきたく思います。
高速道路番号のアイコン内の文字を描画する場合、text-fieldは"uRno"が正しいと思ったのですが、"nRno"となっている箇所がありました。間違っていないでしょうか?
※試験公開していただいているhttps://maps.gsi.go.jp/vector/は正しく描画されていそうです
地理院からダウンロードした任意のpbfをprotocol bufferで読み取ると,
レイヤ名が道路のstring_valueがところどころ文字化けしています.
具体的には,3m未?や市区町?道等など,一部分が0xEFBFBDになっています.
(0xEFBFBDはutf-8化に失敗している証拠)
もちろん,protocol bufferが原因ではなく,生のpbfをバイナリ解析すると該当部分が0xEFBFBDとなっていることからpbfに問題があるといえます.
確認および修正願えますでしょうか.
よろしくお願いいたします.
この実験は地図サービスだけではなく地図データの配信という側面を持つものと認識しています。加えてmapbox leafletに強く依存した配信は中立性の観点から課題を持つと考えます。
先日#14
で指摘したpbfデータはmapbox leafletに依存しない読み取り方法が確立しているものと思いますが、
スタイリングについてはまだ課題を持ったままと考えます。
(人間可読の)pdfのドキュメントでスタイリングのポリシーが提示されている一方、実装物についてはmapbox leaflet専用で提供されており、同実装の中立性がない。
そこで提案ですが、より簡易なスタイリングであれば、geoJsonに対して、ベンダに依存しない複数の実装が存在する仕様があると考えます。それは、gsi-cyberjapanでも類似の仕様が規定されていることも含めてgeojson(のproperties)にスタイルを埋め込む仕様です。
具体的には以下の二つの仕様が候補になると考えます。(できればこれら二つの仕様の統合化が好ましいです)
これらの仕様に準拠したスタイリングをgeojsonデータに対して実行できるコード・データなどの実装が公開されることが好ましいと考えます。もちろんこれらの仕様の範囲では従来のスタイリングと比べて不十分な点があり得ると考えますが、実装容易性とより緻密なスタイリングにはトレードオフが又あると考えますのでシンプルなスタイリングは中立性を高める意味でも重要と考えます。
「地物コード及び表示ズームレベル一覧」において道路のftCodeの下位2桁が01-04しかなくダブっていますが、11-14,21-24,31-34も実際のデータに存在するようです。表の間違いではないでしょうか。
自サイトに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フォント?)
で発生しています。ベクトルタイルデータそのものは大丈夫のようです。
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か1(その他のftcodeではNull)
・gcpNameで(付)とあるものが1でそうでないものが0
・gcpNameで(付)とあるものとでそうでないものの位置は同じ、標高だけが違う、標高も5m程度(付)のほうが低い
以上です、検索してみてもgcpCodeFlagは2件しかヒットせず、データそのものがでてきてしまうので、お問い合わせさせていただいた次第です。よろしくおねがいします。
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
こんにちは。鉄道や道路など属性を多く持つ地物について、公開されている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において、具体的にどのような基準でレイヤーを分割しているかの仕様などがもし公開されていれば大変助かるのですが、いかがでしょうか。
以下の資料「地物コード及び表示ズームレベル一覧」にて、道路で 2200 番台と 2400番台の ftCode
を持つ地物がズームレベル 17 となっていますが、ズームレベル 16 でも存在しておりました。
https://maps.gsi.go.jp/help/pdf/vector/dataspec.pdf
2200番台と2400番代に関する記述がない。
これは、仕様書の方の記載漏れという理解で正しいでしょうか? それともタイルの方の誤りでしょうか?(ズームレベル16から2200番台と2400番台のftCodeをもつ地物が削除される可能性がある?)
情報提供と質問です。
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 を継続使用していくような方針でしょうか?
技術的な(そしておそらく採用が困難であろう)提案です。参考意見としてお聞きください。
現在、地理院地図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 を調べてみると、(2件の例外があったものの) 基本的にはすべての 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
}
},
技術的には合理的、と思うのですが経済的には合理的ではないかもしれません。
もしも大規模な改修がある場合に思い出していただければ、と思います。
dataspecには存在せずblank2.jsonには含まれているデータがいくつかあるようです。これは意図したものでしょうか?
以下に見つけた範囲での一覧を示します。blank2.json以外のスタイルファイルについては調べられていません。またこの他にも差分があるかもしれません。
タイル内の各地物に id がセットされていないため、たとえば map.setFeatureState()
などのメソッドが動作しないと思われます。
参考:
feature.id
が必須になっている。id
という要素があります。必須では無いようですが、値があれば Mapbox GL JS のメソッドがすべて動作するのであったほうがいいかなと思いご報告しました。
提供実験の取り組み大変ご苦労様です。
さて、道路のデータについて2点ほど気づいた点があります。
私の処理の間違いかも知れませんし、元にした図面にも起因するのかとも思います。
1.レベル16の道路データ2701<=ftcode<= 2734のデータをいくつかの都道府県データについて眺めました。
ところどころ非常に微小ではあるものの、不連続があります。タイル間の不整合なのかそうでないのかわかりませんが、タイル間のものもあるようです。
QGIS3.10LTRでPBFを直接開いてから、もしくはGDALで変換処理してからの気づきですので、もしかするとソフトやプログラムの問題かもしれません。
2.地物等の属性一覧での定義表にないデータがある場合がある
地物等の属性一覧はhttps://maps.gsi.go.jp/help/pdf/vector/attribute.pdfを参考にしました。
共通属性と個別の属性などがありますが、この表にない数値が出現する場合があります。
例)PDF 5ページ目のmedSect
表では0、1、99となっていますが、2~18の間の数値が入っている場合がありました。
以上です。提供実験であることは重々承知しております。
今後もこのような素晴らしい取り組みを続けていただくためにも、微力ながら応援してまいります。
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.