produce-gsc-6のファイル整理とベクトルタイル容量を削減する

はじめに

produce-gsc-6のファイル整理を行うと同時に、unvtのベクトルタイル容量を削減することで、パフォーマンス向上を目指します。この記事では、ベクトルタイルを作成する段階におけるベクトルタイル容量の削減を目指します。

使用レポジトリ

ベクトルタイル変換に関するproduce-gsc-6レポジトリを使用します。

バックアップのために、以下のローカルフォルダに20260102のデータを保存しておきます。
/Users/astro/Documents/GitHub/old/20260102produce-gsc-6

作業レポジトリ

作業レポジトリは、開発環境の以下のレポジトリとします。
/vtdata/test/20260102produce-gsc-6

設定ファイル（default.hjson)の削減

現在、設定ファイルは以下の２つがあり、使用しづらい状況です。
default-sample.hjson
default-sample2.hjson

そのため、違いを調べて、一つにまとめます。

ファイル相違点

２つのファイルの相違点を抜き出します。

default-sample.hjson

un-s: { 
  relations: [
   un_base::vectortile::unmap_bnda_cty_anno_03_p
   un_base::vectortile::unmap_bnda_cty_anno_04_p
   un_base::vectortile::unmap_bnda_cty_anno_05_p
   un_base::vectortile::unmap_bnda_cty_anno_06_p

un-l: {
  concurrent: 4
  relations: [
    un_base::vectortile::unmap_bnda_cty_anno_06_p

osm-l: {
  concurrent: 3
  concurrentE: 2

defaultDate: 2021-01-20
fetchSize: 300

everydayTilelist: [
ウクライナ地域が含まれていない。

default-sample2.hjson

un-s: { 
  relations: [
   un_base::vectortile::unmap_bnda_label_03_p
   un_base::vectortile::unmap_bnda_label_04_p
   un_base::vectortile::unmap_bnda_label_05_p
   un_base::vectortile::unmap_bnda_label_06_p

un-l: {
  concurrent: 6
  relations: [
    un_base::vectortile::unmap_bnda_label_06_p

osm-l: {
  concurrent: 6
  concurrentE: 6

defaultDate: 2022-08-20
fetchSize: 30000
  
everydayTilelist: [
ウクライナ地域が含まれている。

ファイル修正

ウクライナ地域は削除して、変換にかけたいので、
default-sample.hjson
をベースに修正します。
relationsの記載は、cty_annoから、labelに変更します。こちらの方が適切だと考えられるからです。
defaultDate: 2026-01-02、
fetchSize: 30000
とします。
concurrentとconcurrentEについては、すべて6にします。

インデントも調整します。

default-sample2.hjson
は削除します。

unmap_bnda_cty_anno_03_pとunmap_bnda_label_03_pについては、エクセルファイルVector tiles listには、unmap_bnda_label_03_pのみ存在します。

cty_annoも、labelも、すべてのデータは、"source-layer"が"lab_cty"として、ベクトルタイルに変換されています。

PostGISでデータ確認

データベースには存在するのかどうか、実際にPostGISで確かめてみると、どちらも存在しました。

実際にどのようなデータなのか確認してみます。

unmap_bnda_cty_anno_について

SELECT * FROM unmap_bnda_cty_anno_03_p LIMIT 1;

以下が属性として挙げられています。ちなみにanno_04,05,06も同様の属性でした。
objectid | annotationclassid | status | textstring | fontname | fontstyle

unmap_bnda_label_について

SELECT * FROM unmap_bnda_label_03_p LIMIT 1;

以下が属性として挙げられています。ちなみにlabel_04,05,06も同様の属性でした。
objectid | featureid | zorder | annotationclassid | element | symbolid | status | textstring | fontname | fontsize | bold | italic | underline | verticalalignment | horizontalalignment | xoffset | yoffset | angle | fontleading | wordspacing | characterwidth | characterspacing | flipangle | override | orig_fid | gdb_geomattr_data

スタイルファイルを確認すると、"source-layer": "lab_cty"はtextstringを使用しています。

地図上で見え方の確認

ベクトルタイルを作成して、２つのファイルの見え方がどう異なるのか確認します。現状では、unmap_bnda_cty_anno_で作成したベクトルタイルが表示されるので、unmap_bnda_label_で作成したものと比較してみます。

小縮尺であるズームレベル1-5については、違いは見られませんでした。おそくら、大縮尺でunmap_bnda_label_で作成したものの方がデータが多いのだと思われます。
大縮尺のデータも作成し、全てのデータを開発環境のホスティングサーバに保存していきます。
まずは、UNの大縮尺データを作成し、osmのeveryday areaのデータと統合しました。

以下の２つのタイルで、開発環境GeoPortalのUN Street Map(UNVT)と、本番環境と同等のものを比べましたが、違いは見られませんでした。
6-35-23（Kosovo）
6-39-32（Mombasa)

つまり、unmap_bnda_cty_anno_でなく、unmap_bnda_label_で作成したベクトルタイルでも問題ないことが確認できました。

produce-gsc-smallディレクトリ内のファイル削減

produce-gsc-smallには以下の６個のファイルがあり分かりづらいので、まとめます。

• index_osm-s-compact.js
• index_osm-s.js
• index_un-s.js
• modify-compact.js
• modify-old0922.js
• modify.js

index_un-s.js
は、修正の必要はありません。

modify-old0922.js
は、oldとついており、使用されていないので、削除します。

index_osm-s-compact.jsとindex_osm-s.jsの比較

index_osm-s-compact.js

const modify = require('./modify-compact.js')

if (table == 'roads_major_0408_l' ){
      sql = `
DECLARE cur CURSOR FOR 
SELECT ST_AsGeoJSON(ST_Simplify(ST_LineMerge(ST_Collect(ARRAY(SELECT geom FROM ${schema}.${table} WHERE z_order=1 OR z_order=3))),0.001, true))
` 
} else {

上記コードの解説はこちらの記事にあります。
0.001で調整していますが、もっと軽くするために、下の方の記事で調整して、最適な値にしています。

index_osm-s.js

const modify = require('./modify.js')

道路データをより軽くするための工夫をしている、index_osm-s-compact.jsのみ残し、index_osm-s.jsは削除しました。

modify-compact.jsとmodify.jsの比較

modify-compact.jsはroads_major_0408_l のみ対象としています。
そのため、modify.jsのみ残して、modify-compact.jsは削除する方針とします。

異なる部分を抽出すると以下のとおりです。

modify-compact.js

roads_major_0408_l: f => {
  f.tippecanoe = {
    layer: 'road-s',
  }

un_glc30_global_lc_ss_a: f => {
  f.tippecanoe = {
    layer: 'landcover',
    minzoom: 3,

modify.js

roads_major_0408_l: f => {
  f.tippecanoe = {
    layer: 'road-s',
  };
  delete f.properties['id'];
  delete f.properties['osm_id'];
  その他属性の削除が続く

un_glc30_global_lc_ss_a: f => {
  f.tippecanoe = {
    layer: 'landcover',
    minzoom: 0,


unmap_wbya10_a: f => {
  f.tippecanoe = {
    layer: 'watera-s',
    minzoom: 2,
    maxzoom: 5,
  };
  delete f.properties['objectid'];
  delete f.properties['fid_1'];
  return f;
},

unmap_bnda_cty_anno_03_p
unmap_bnda_cty_anno_04_p
unmap_bnda_cty_anno_05_p
unmap_bnda_cty_anno_06_p
上記４つのviewの記載あり

roads_major_0408_l
の記載は、
modify-compact.js
に合わせます。

roads_major_0408_lの地物にあった属性は、前段階の処理部分であるindex_osm-s-compact.jsにおいて一つにまとめられることで全て削除されるため、modify.jsで属性を削除する必要はありません。

un_glc30_global_lc_ss_a
は、minzoom = 0から必要なため、modify.jsの記載のままです。

unmap_wbya10_a
も必要なため、modify.jsの記載のままです。

unmap_bnda_cty_anno_03_p
unmap_bnda_cty_anno_04_p
unmap_bnda_cty_anno_05_p
unmap_bnda_cty_anno_06_p
については、必要ないので、削除します。

default.hjsonのレイヤとproduce-gsc-small/modify.jsのレイヤの比較

default.hjson

un-s: { 
  Z: 0
  relations: [
    un_base::vectortile::custom_planet_land_08_a
    un_base::vectortile::un_glc30_global_lc_ss_a
    un_base::vectortile::unmap_bndl_l
    un_base::vectortile::unmap_bndl05_l
    un_base::vectortile::unmap_bndl25_l
    un_base::vectortile::custom_ne_rivers_lakecentrelines_l
    un_base::vectortile::unmap_wbya10_a
    un_base::vectortile::unmap_bnda_label_03_p
    un_base::vectortile::unmap_bnda_label_04_p
    un_base::vectortile::unmap_bnda_label_05_p
    un_base::vectortile::unmap_bnda_label_06_p
    un_base::vectortile::unmap_phyp_label_04_p
    un_base::vectortile::unmap_phyp_label_06_p
    un_base::vectortile::unmap_phyp_p
    un_base::vectortile::unmap_popp_p
  ]
}

modify.js

roads_major_0408_l
custom_planet_land_08_a
un_glc30_global_lc_ss_a
custom_ne_10m_bathymetry_a
unmap_bndl_l
unmap_bndl05_l
unmap_bndl25_l
custom_ne_rivers_lakecentrelines_l
unmap_wbya10_a
unmap_bnda_label_03_p
unmap_bnda_label_04_p
unmap_bnda_label_05_p
unmap_bnda_label_06_p
unmap_phyp_label_04_p
unmap_phyp_label_06_p
unmap_phyp_p
unmap_popp_p

２つのファイルのレイヤを比較したところ、「roads_major_0408_l」と「custom_ne_10m_bathymetry_a」がmodify.jsのみに存在します。
roads_major_0408_lレイヤはindex_osm-s-compact.jsを実行時に必要なので、modify.jsに含めておきます。しかし、「custom_ne_10m_bathymetry_a」は使用されていないので、modify.jsから削除します。

編集後、modify-compact.jsは削除しました。そのため、modify-compact.jsを参照していた
index_osm-s-compact.js
も編集します。

index_osm-s-compact.js

修正前
const modify = require('./modify-compact.js')
⬇️
修正後
const modify = require('./modify.js')

上記のとおり修正しました。この３つのファイルで動くか確認します。

まずは、index_un-s.jsを実行し、正常にファイルが作成されました。
次に、index_osm-s-compact.jsを実行し、正常にファイルが作成されました。
２つのファイルをtile-joinして、作成したファイルをhostingサーバで立ち上げて、地図を確認したところ問題ありませんでした。

ちなみにデータ容量は、以下のとおりです。
unファイル: 22.1 MB
osmファイル: 2.7 MB
small-scale.mbtiles: 25.8 MB

produce-gsc-osmフォルダの整理

使用していない以下のファイルは削除します。
modify-2022-10-12.js
modify-2022-11-17.js
modify-old.js

default.hjsonのレイヤとproduce-gsc-osm/modify.jsのレイヤの比較

どちらのファイルにも存在する32レイヤ

• landuse_naturallarge_a
• landuse_naturalmedium_a
• water_all_a
• waterways_small_l
• waterways_large_l
• roads_major_l
• roads_medium_l
• roads_minor_l
• roads_other_l
• roads_special_l
• railways_all_l
• ferries_all_l
• runways_all_l
• pois_transport_a
• landuse_urban_a
• buildings_a
• pois_transport_p
• pois_transport_ap
• pois_public_p
• pois_public_ap
• pois_services_p
• pois_services_ap
• pois_worship_p
• pois_worship_ap
• pois_heritage_p
• pois_heritage_ap
• pois_other_p
• pois_other_ap
• pois_traffic_p
• pois_water_p
• landuse_parkreserve_a
• places_all_p

produce-gsc-osm/modify.jsにしか存在しない7レイヤ

• landuse_naturalmedium0609_a
• roads_all_a
• osm_planet_other_buildings
• barriers_all_l
• landuse_other_p
• places_all_a
• pois_services_a

使用されていない上記7レイヤはproduce-gsc-osm/modify.jsから削除しました。

修正したファイルで正常に動くか確認したところ、ベクトルタイルは正常に作成され、地図上でも問題ありませんでした。

produce-gsc-unフォルダの整理

使用していない以下のファイルは削除します。
index-z16.js
modify-backup20230320.js
modify-z16.js

default.hjsonのレイヤとproduce-gsc-un/modify.jsのレイヤの比較

どちらのファイルにも存在する29レイヤ

• custom_planet_land_08_a
• custom_planet_land_main_a
• custom_planet_land_antarctica_a
• custom_planet_coastline_l
• unmap_bndl_l
• custom_unmap_bndl_l
• un_unmik_bndl_l
• un_mimu_bndl
• un_unvmc_igac_bndl_l
• custom_ne_rivers_lakecentrelines_l
• un_glc30_global_lc_ms_a
• un_mission_lc_ls_a
• un_global_places_p
• unmap_popp_p
• unmap_phyp_label_06_p
• unmap_phyp_p
• unmap_bnda_a1_ap
• unmap_bnda_a2_ap
• custom_unmap_bnda_a1_ap
• custom_unmap_bnda_a2_ap
• un_unmik_bnda_a2_ap
• un_unmik_bnda_a3_ap
• un_unvmc_igac_bnda_a1_departments_ap
• un_unvmc_igac_bnda_a2_municipalities_ap
• un_unvmc_igac_bnda_a3_rural_units_ap
• unmap_bnda05_cty_a
• unmap_bnda_label_06_p
• un_minusca_pois_p
• un_global_pois_p

produce-gsc-un/modify.jsにしか存在しない2レイヤ

• custom_ne_10m_bathymetry_a
• unmap_bnda_cty_anno_06_p

使用されていない上記2レイヤはproduce-gsc-un/modify.jsから削除しました。

修正したファイルで正常に動くか確認したところ、ベクトルタイルは正常に作成され、地図上でも問題ありませんでした。

ベクトルタイル容量削減の調査対象ファイル

調査対象ファイルとしては、小縮尺と大縮尺のそれぞれのファイルを対象とします。

小縮尺ファイル
small-scale.mbtiles(25.8MB)

大縮尺ファイル
6-35-31.mbtiles(139.3MB)

海に近い地域だと海周辺地域のファイルサイズが小さい影響で、ファイルサイズ平均が小さくなるため陸域のみが存在するファイルを選択しました。また、Missionが存在する地域でもあります。

作業フォルダ

ローカルの以下のフォルダを作業ディレクトリとします。
/Users/astro/Documents/GitHub/20260116vt-optimizer-rs3/

作業方針

ベクトルタイル容量の減らし方として以下の２つがあります。

1. 頂点(vertices）の数を減らす
2. 使用していないレイヤを減らす

まずはインパクトの大きい1から実施します。

小縮尺ファイルのタイル容量、レイヤ等の確認

小縮尺ファイルは必ず表示されるため、UXに大きな影響を与えます。また、ズームレベル0や1などのタイルは、一つの画面に複数表示される場合もあるので、これらのサイズを小さくすることが重要です。

小縮尺ファイル small-scale.mbtiles: (vt-optimizer-rs: 23.95MB, 25.8MB)

zoom	#tiles	max(KB)	avg(KB)
0	1	443.84	443.84
1	4	602.10	285.42
2	16	692.64	157.42
3	62	428.63	66.46
4	222	261.95	31.08
5	737	145.28	12.76

name	# of vertices	# of features
landcover	8396273	1072372
bndl	1345647	124379
landmass	1296171	107716
road-s	1273712	302
un_water	224215	9399
watera-s	81536	3035
phyp_label	4349	4349
lab_cty	1380	1380
un_popp	696	696
lab_water	390	390

landcover、bndl、landmass、road-s のverticesが多いのでこれらのverticesの数を少なくします。

スタイルファイルで属性を利用しているのかの確認

もし、スタイルファイルで属性を使用している場合には、road-sで利用している線分を統合するような処理が出来ません。そのため、どのようなスタイル方法を利用しているのか、レイヤごとに確認します。

landcover

小縮尺においては、以下の２つのレイヤがあり、属性を使用しています。

style.json

"filter": ["any", ["==", "gridcode", 20]],
"id": "pg-landcover-20",

 "filter": ["any", ["==", "gridcode", 30]],
"id": "pg-landcover-30",

bndl

小縮尺においては、以下の3つのレイヤがあり、属性を使用しています。

style.json

 "filter": ["all", ["==", "bdytyp", 3]],
"id": "ls-admin-armistice",

"filter": ["all", ["==", "bdytyp", 2]],
"id": "ls-admin-special",

"filter": ["all", ["==", "bdytyp", 1]],
"id": "ls-admin-international",

landmass

UN GeoPortal、MapLibreどちらのスタイルにおいても属性は利用していません。

road-s

UN GeoPortal、MapLibreどちらのスタイルにおいても属性は利用していません。

PostGISでデータ構成確認

landcoverは約107万個の地物と、約840万個の頂点数があります。つまり一つの地物辺り、8個くらいしか頂点数がないことになります。

SELECT
  ST_AsText(ST_Transform(geom, 4326)) AS geom_wgs84
FROM custom_planet_land_08_a
ORDER BY random()
LIMIT 10;

として、調べたところ、頂点数が多いものが結構ありました。
よく分からないですが、ST_Simplifyとすれば良いかもしれませんので、やってみます。

試してみましたが、書き方が分からず難しいです。chatGPTによると、ポリゴンが壊れることもあり、難しいみたいなので、このやり方は諦めます。

tippecanoeを利用したタイルサイズ削減（index_un-s.js）

tippecanoeのオプションでsimplificationをして、タイルサイズ削減を図ります。
index_un-s.jsについてタイルサイズを削減します。osmについては、別に記載します。

feltのtippecanoeのサイトにあるとおり、ポリゴンとラインのverticesを減らしてベクトルタイルが作成出来ます。10くらいまでなら、そんなに見た目が変わらないと記載があります。

ちなみに'--drop-rate'はポイントの間引きに使います。今回は、ポイントは対象ではないので使用しません。

'--simplification=10'　　　15.6 MB(UNのみ）

問題なさそうです。

'--simplification=20'　　　13.2 MB(UNのみ）

これはカクカクしています。

'--simplification=30'　　　12.6 MB(UNのみ）

これもカクカクしすぎですね。

'--simplification=100'　　11.5 MB(UNのみ）

完全にアウトです。

--simplification=10を採用します。
再度、vt-optimizer-rsで解析します。
小縮尺ファイル small-scale.mbtiles: 18.1 MB

zoom	#tiles	max(KB)	avg(KB)
0	1	329.02	329.02
1	4	466.39	217.67
2	16	531.95	117.53
3	62	286.43	43.53
4	222	188.05	20.89
5	736	124.44	9.16

ズームレベル0では、443KBから329KBに26%くらいタイルサイズを減少させることができました。

name	# of vertices	# of features
landcover	4976081	1072090
road-s	1273712	302
landmass	574704	107667
bndl	388202	71147
un_water	76910	9399
watera-s	34214	3035
phyp_label	4349	4349
lab_cty	1380	1380
un_popp	696	696
lab_water	390	390

landcoverのverticesが8396273から4976081に、約40%減りました。

PostGISからデータ抽出時のデータ削減（index_osm-s-compact.js）

roads_major_0408_lのみ、osmから作成されます。

現在、ST_Simplifyの閾値が「0.001」となっていますが、これを調整します。
--simplificationは2のまま変更していません。

chatGPTによると、0.001度 ≒ 約111m（緯度方向）くらいの誤差であり、z5：1px ≈ 4.9kmくらいらしいです。そのため、0.005 ~ 0.02くらいがオススメとのことです。0.01, 0.02, 0.03, 0.1で試してみます。

0.01 2.4 MB(OSMのみ、元は2.7MB）

問題なさそうです。
vt-optimizer-rsを使用して解析してみます。

./target/release/vt-optimizer inspect ./Data/small-scale-simp10-osm001.mbtiles

road-sの「# of vertices」が1273712→1030257に19%減りました。

0.02 2.1 MB(OSMのみ)

問題なさそうです。

road-sの「# of vertices」が1273712→793099に38%減りました。

0.03 1.9 MB(OSMのみ)

細かくみると多少まっすぐなところがあり、これで良いかどうかは評価が分かれそうです。

road-sの「# of vertices」が1273712→706376に45%減りました。

0.1（より削減） 1.6 MB(OSMのみ）

これは簡略化され過ぎていてアウトです。

road-sの「# of vertices」が1273712→589549に54%減りました。

小縮尺ファイルの最終的なタイル容量やレイヤ

UNは'--simplification=10'として設定し、15.6 MB(UNのみ）
osmは0.02、--simplification=2として設定し、2.1 MB(OSMのみ)
Total size: (vt-optimizer-rs: 16.10MB, 17.5MB)

zoom	#tiles	max(KB)	avg(KB)
0	1	329.02	329.02
1	4	466.39	217.67
2	16	531.95	117.53
3	62	286.43	43.53
4	222	166.57	20.07
5	736	93.01	8.50

name	# of vertices	# of features
landcover	4976081	1072090
bndl	388202	71147
landmass	574704	107667
road-s	793099	302
un_water	76910	9399
watera-s	34214	3035
phyp_label	4349	4349
lab_cty	1380	1380
un_popp	696	696
lab_water	390	390

タイル容量全体：25.8 MB　→　17.5 MB (32%削減）
タイルサイズ：23% ~ 36%の削減
頂点数：landcover 40%削減、bndl 71%削減、landmass 56%削減、road-s 38%削減

大縮尺タイルのレイヤ数等

元の設定であったsimplification=2の
6-35-31.mbtiles (vt-optimizer-rs: 103.59MB, 139.3MB)
の結果は以下のとおりです。

ズームレベル7

zoom	#tiles	max(KB)	avg(KB)
6	9	283.15	34.93
7	16	232.53	36.55
8	36	153.90	26.17
9	100	115.68	14.26
10	324	91.05	6.71
11	1156	90.33	3.55
12	4356	78.19	1.65
13	16900	37.08	0.71
14	66564	163.22	0.39
15	264196	68.81	0.19

基本的には問題ないのですが、地図上で見てみるとズームレベル6,7,8で少しカクつきます。simplificationを上げてもいいかもしれません。

なぜ、ズームレベル6でタイルの数が9なのか不明です。他のタイル領域にも少し重なっているのかもしれません。

6-35-31.mbtiles のズームレベル6のレイヤ情報は以下です。

name	# of vertices	# of features
bnd_lab1	9	9
bnda_cty	618	14
bndl	3519	145
ferry	60	29
landcover	107227	6561
landmass	60	15
nature-m	38750	684
osm_place	16	16
road	1418	338
un_place	9	9
un_popp	1	1
un_water	634	35
watera	16577	535

landcover(un), nature-m(osm), watera(osm)などの値を取り除くのが重要だと思います。

produce-gsc-un > index.jsと、produce-gsc-osmのindex_everyday.jsなどの--simplificationを調整します。

--simplification=5の場合

ズームレベル7

元の画像との違いはわかりません。

6-35-31simp5.mbtiles (vt-optimizer-rs: 96.69MB, 131.5MB)
全体の容量は6%削減。

zoom	#tiles	max(KB)	avg(KB)
6	9	195.28	24.31
7	16	160.77	25.81
8	36	109.39	19.73
9	100	75.84	11.01
10	324	60.38	4.88
11	1156	63.12	2.77
12	4356	58.71	1.37
13	16900	33.71	0.65
14	66564	159.04	0.38
15	264196	67.18	0.19

ZL6: 283.15 →　195.28 (31%削減）
ZL11: 90.33 →　63.12 (30%削減）
ZL15: 68.81 →　67.18 (2%削減）

ズームレベル6

name	# of vertices	# of features
bnd_lab1	9	9
bnda_cty	359	14
bndl	1850	145
ferry	58	29
landcover	62417	6561
landmass	60	15
nature-m	20090	684
osm_place	16	16
road	966	338
un_place	9	9
un_popp	1	1
un_water	410	35
watera	11434	535

landcover(un)
107227 → 62417 (42%削減）

nature-m(osm)
38750 → 20090　(48%削減）

watera(osm)
16577 → 11434　(31%削減）

--simplification=7の場合

ズームレベル7

Bangui付近の道路が、少し直線気味になっています。

6-35-31simp7.mbtiles(vt-optimizer-rs: 93.86MB, 127.9MB)
全体の容量は8%削減。

zoom	#tiles	max(KB)	avg(KB)
6	9	176.06	21.99
7	16	139.74	22.68
8	36	95.22	17.48
9	100	65.54	10.01
10	324	52.96	4.34
11	1156	55.50	2.52
12	4356	52.21	1.28
13	16900	32.61	0.61
14	66564	155.94	0.37
15	264196	66.58	0.19

283.15 →　176.06

ズームレベル6

name	# of vertices	# of features
bnd_lab1	9	9
bnda_cty	316	14
bndl	1466	145
ferry	58	29
landcover	54294	6561
landmass	60	15
nature-m	16171	684
osm_place	16	16
road	888	338
un_place	9	9
un_popp	1	1
un_water	326	35
watera	10431	535

landcover(un)
107227 → 54294(49%削減）

nature-m(osm)
38750 → 　16171(58%削減）

watera(osm)
16577 → 　10431(37%削減）

--simplification=10の場合

ズームレベル7

6-35-31simp10.mbtiles(vt-optimizer-rs: 90.68MB, 124.1MB)
全体の容量は11%削減。

道路の細かな表現が出来ていない部分があります。

zoom	#tiles	max(KB)	avg(KB)
6	9	159.50	19.99
7	16	124.50	20.25
8	36	82.12	15.29
9	100	55.71	8.98
10	324	46.47	3.86
11	1156	49.20	2.28
12	4356	46.46	1.18
13	16900	31.77	0.57
14	66564	148.87	0.36
15	264196	65.51	0.19

283.15 →　159.50

ズームレベル6

name	# of vertices	# of features
bnd_lab1	9	9
bnda_cty	252	14
bndl	1147	145
ferry	58	29
landcover	48005	6561
landmass	60	15
nature-m	13182	684
osm_place	16	16
road	806	338
un_place	9	9
un_popp	1	1
un_water	255	35
watera	9372	535

landcover(un)
107227 → 48005

nature-m(osm)
38750 → 13182

watera(osm)
16577 → 9372

バンギが含まれる
6-35-31.mbtiles(139.3MB)
のみをtile-joinする方法。

/usr/local/bin/tile-join --no-tile-size-limit -f -o large_tiles/unosm/tile_every/6-35-31.mbtiles produce-gsc-un/mbtiles/un_tile/6-35-31.mbtiles produce-gsc-osm/mbtiles/osm_tile_every/6-35-31.mbtiles

検討した結果、simplification = 5が最適だということが分かりました。everydaylistの全てのタイルで作成して、本当に問題ないか確認してみます。
地図上で確認したところ、問題ありませんでした。

大縮尺ファイルの最終的なタイル容量やレイヤ

UNおよびOSMはともに'--simplification=5'として設定しました。
UNのフォルダ上での容量は33 MB、OSMは107 MB

6-35-31simp5.mbtiles (vt-optimizer-rs: 96.69MB, 131.5MB)
全体の容量は 139.3MBから6%削減。

各ズームレベルの最大タイルサイズの削減量

ZL6: 283.15 →　195.28 (31%削減）
ZL11: 90.33 →　63.12 (30%削減）
ZL15: 68.81 →　67.18 (2%削減）

ズームレベル6のvertices数の削減量

landcover(un)
107227 → 62417 (42%削減）

nature-m(osm)
38750 → 20090　(48%削減）

watera(osm)
16577 → 11434　(31%削減）

まとめ

produce-gsc-6のファイル整理を行うと同時に、unvtのベクトルタイル容量を削減しました。
不必要なファイルを削除することで、よりメンテナンスが行いやすくなりました。

Reference