MBTiles规范完全指南一文看懂地图瓦片格式的终极入门教程【免费下载链接】mbtiles-specspecification documents for the MBTiles tileset format项目地址: https://gitcode.com/gh_mirrors/mb/mbtiles-spec打开手机地图轻轻拖动、缩放屏幕上无数张小图片瞬间加载——这些图片就是地图瓦片。而MBTiles正是行业通用的地图瓦片格式打包规范它把成千上万张瓦片装进一个 SQLite 数据库文件让地图数据「即拿即用、随传随到」。本文面向零基础新手带你彻底看懂 MBTiles 规范它是什么、文件里到底装了什么、瓦片坐标如何定位以及 1.0 到 1.3 各版本如何一步步演进看完即可上手。什么是 MBTiles为什么地图瓦片需要统一规范MBTiles全称 MBTiles Specification是一个用于将瓦片地图数据存储在 SQLite 数据库中的开放规范由 Mapbox 等社区维护。按照该规范生成的.mbtiles文件被称为tileset瓦片集一个文件就代表一张完整的地图。为什么需要它在没有统一规范之前各家地图工具生成的瓦片格式五花八门换个软件就无法读取。MBTiles 用一套「最小但严格」的约定解决了这个问题️统一容器底层就是标准 SQLite 数据库任何支持 SQLite 的语言都能读写单文件分发一个.mbtiles文件 一整张离线地图拷贝即用无需部署服务器高效传输瓦片按金字塔层级存储客户端只下载当前视口需要的部分加载飞快。MBTiles 属于「存储规范」而非「原始数据规范」——它存的是渲染好的瓦片图片或矢量数据这与 GeoJSON、Spatialite 等存原始要素的方式有本质区别。MBTiles 文件内部结构一张瓦片集的「三张底牌」MBTiles 文件本质上是一个 SQLite 数据库规范要求它必须包含若干特定表。想快速理解记住这三张表就够metadata元数据、tiles瓦片数据、以及可选的grids/grid_data交互数据。metadata 元数据表地图的「身份证」metadata表只有name和value两列是一个键值对key/value存储用于描述整张地图的基本信息。MBTiles 1.3 中以下字段是必须存在的字段含义示例name瓦片集的人类可读名称TIGER 2016format瓦片数据格式pbf、jpg、png、webp另外四个建议字段也很有用字段含义示例bounds地图覆盖范围WGS84左/下/右/上-180.0,-85,180,85center默认视图中心经度,纬度,缩放级别-122.1906,37.7599,11minzoom最小缩放级别0maxzoom最大缩放级别5此外还可以有attribution版权声明、description描述、typeoverlay覆盖层或baselayer底图、version瓦片集版本等可选字段。tiles 瓦片表真正存放图片的地方tiles表是 MBTiles 的绝对核心它有四列zoom_level缩放级别、tile_column瓦片列号、tile_row瓦片行号和tile_data瓦片二进制数据。每一行就是一张瓦片tile_data以 BLOB 形式保存 PNG、JPEG 或矢量瓦片数据。grids / grid_data 交互表让地图「可点击」这两张可选表用于存放UTFGrid交互数据grids表保存 gzip 压缩的网格数据grid_data表保存网格键到 JSON 值的映射。有了它们鼠标悬停在地图上就能弹出「这里是法国」「这条是高速公路」之类的提示信息。详细存储规则见 1.1/utfgrid.md 与 1.1/interaction.md。瓦片坐标定位原理zoom_level / tile_column / tile_rowMBTiles 采用经典的金字塔瓦片模型缩放级别 zoom 越大地图被切分得越细。在缩放级别 z地图被分成 2^z × 2^z 张瓦片列号从西到东、行号从北到南编号这样就得到了每一张瓦片的唯一坐标(z, x, y)。这里有一个新手最容易踩的坑 ⚠️MBTiles 遵循TMSTile Map Service规范其 Y 轴方向与常见的「XYZ」网络瓦片坐标相反。例如 URL 中常见的11/327/791这张瓦片在 MBTiles 中要写成zoom_level11, tile_column327, tile_row1256——因为1256 2^11 - 1 - 791。同时规范强制要求使用global-mercator球形墨卡托投影这一点在 1.3/spec.md 中有明确说明。MBTiles 1.3 矢量瓦片json 元数据与 tilestats从 1.3 版本开始规范重点补充了矢量瓦片format 为pbf的支持。这类瓦片集必须在metadata表中额外提供一个json字段字符串化的 JSON 对象其中包含两个关键部分vector_layers列出瓦片中出现的所有图层以及每个图层的字段名与类型Number、Boolean、String帮助渲染端提前了解数据tilestats可选字段统计每个图层的属性取值范围和示例值方便客户端做样式预判。例如一个包含美国县级行政区与主干道路的矢量瓦片集其json字段就清晰描述了tl_2016_us_county图层及其GEOID、NAME等字段。完整的元数据与示例可见 1.3/spec.md 中的「Vector tileset metadata」小节。MBTiles 版本演进从 1.0 到 1.3 改了什么不同年代的工具生成的 MBTiles 文件可能对应不同版本了解演进史能帮你快速排查兼容性问题版本核心变化1.0最早的规范metadata表仅要求name、type、version、description四键瓦片仅支持 png/jpg1.1新增必须的format字段与建议的bounds字段引入可选 UTFGrid 交互规范1.2将 UTFGrid 拆分为独立规范版本号同步交互逻辑移交给 UTFGrid 1.21.3新增矢量瓦片pbf支持补充json元数据与tilestats元数据字段按实际使用修订完整变更记录参见 CHANGELOG.md各版本规范分别存放于 1.0/spec.md、1.1/spec.md、1.2/spec.md 和 1.3/spec.md。如何快速验证一个 MBTiles 文件想亲手验证某个.mbtiles文件是否合规由于它本质是 SQLite 数据库直接用命令行工具就能探查以下为示意命令# 查看元数据 sqlite3 world.mbtiles SELECT name, value FROM metadata; # 查看瓦片数量与格式 sqlite3 world.mbtiles SELECT format, COUNT(*) FROM tiles; # 查看瓦片坐标范围 sqlite3 world.mbtiles SELECT MIN(zoom_level), MAX(zoom_level) FROM tiles;如果metadata表含name与format两行、tiles表结构正确这个文件基本就符合规范了。想要进行更严格的 UTFGrid 兼容性测试仓库还提供了包含 65501 个不同键的测试网格 1.1/demo.json供实现者校验坐标与键的映射是否正确。新手常见问题FAQQ1MBTiles 与普通的图片瓦片文件夹有什么区别普通瓦片以「文件夹/层级/x/y.png」的目录结构散落存放管理混乱、传输慢MBTiles 用单个 SQLite 文件整合全部瓦片便于拷贝、压缩和快速检索。Q2MBTiles 支持哪些瓦片格式1.2 及以前仅支持png和jpg1.3 起支持pbf矢量瓦片、webp以及其他 IETF 媒体类型。Q3MBTiles 是矢量数据格式吗不是。它本质是已渲染瓦片的容器只有 format 为pbf时内部才存放 Mapbox Vector Tile 矢量数据。Q4一个 MBTiles 文件可以放多张地图吗规范约定一个文件只代表一个 tileset一张地图多张地图请使用多个.mbtiles文件。结语如何深入掌握 MBTiles 规范MBTiles 之所以长盛不衰正因为它「小而美」容器只用 SQLite定位只用一套坐标交互数据可选——简单到极致反而成就了极高的兼容性与生态广度。无论是做离线地图 App、GIS 数据分发还是自建瓦片服务理解这份规范都能让你事半功倍。想要通读原文克隆仓库到本地即可边看边实践git clone https://gitcode.com/gh_mirrors/mb/mbtiles-spec从 README.md 出发按 1.3/spec.md → 1.2/spec.md → 1.1/spec.md 的顺序阅读你就能完整掌握这份地图瓦片格式规范的精髓。祝你在瓦片地图的世界里玩得开心【免费下载链接】mbtiles-specspecification documents for the MBTiles tileset format项目地址: https://gitcode.com/gh_mirrors/mb/mbtiles-spec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
MBTiles规范完全指南一文看懂地图瓦片格式的终极入门教程【免费下载链接】mbtiles-specspecification documents for the MBTiles tileset format项目地址: https://gitcode.com/gh_mirrors/mb/mbtiles-spec打开手机地图轻轻拖动、缩放屏幕上无数张小图片瞬间加载——这些图片就是地图瓦片。而MBTiles正是行业通用的地图瓦片格式打包规范它把成千上万张瓦片装进一个 SQLite 数据库文件让地图数据「即拿即用、随传随到」。本文面向零基础新手带你彻底看懂 MBTiles 规范它是什么、文件里到底装了什么、瓦片坐标如何定位以及 1.0 到 1.3 各版本如何一步步演进看完即可上手。什么是 MBTiles为什么地图瓦片需要统一规范MBTiles全称 MBTiles Specification是一个用于将瓦片地图数据存储在 SQLite 数据库中的开放规范由 Mapbox 等社区维护。按照该规范生成的.mbtiles文件被称为tileset瓦片集一个文件就代表一张完整的地图。为什么需要它在没有统一规范之前各家地图工具生成的瓦片格式五花八门换个软件就无法读取。MBTiles 用一套「最小但严格」的约定解决了这个问题️统一容器底层就是标准 SQLite 数据库任何支持 SQLite 的语言都能读写单文件分发一个.mbtiles文件 一整张离线地图拷贝即用无需部署服务器高效传输瓦片按金字塔层级存储客户端只下载当前视口需要的部分加载飞快。MBTiles 属于「存储规范」而非「原始数据规范」——它存的是渲染好的瓦片图片或矢量数据这与 GeoJSON、Spatialite 等存原始要素的方式有本质区别。MBTiles 文件内部结构一张瓦片集的「三张底牌」MBTiles 文件本质上是一个 SQLite 数据库规范要求它必须包含若干特定表。想快速理解记住这三张表就够metadata元数据、tiles瓦片数据、以及可选的grids/grid_data交互数据。metadata 元数据表地图的「身份证」metadata表只有name和value两列是一个键值对key/value存储用于描述整张地图的基本信息。MBTiles 1.3 中以下字段是必须存在的字段含义示例name瓦片集的人类可读名称TIGER 2016format瓦片数据格式pbf、jpg、png、webp另外四个建议字段也很有用字段含义示例bounds地图覆盖范围WGS84左/下/右/上-180.0,-85,180,85center默认视图中心经度,纬度,缩放级别-122.1906,37.7599,11minzoom最小缩放级别0maxzoom最大缩放级别5此外还可以有attribution版权声明、description描述、typeoverlay覆盖层或baselayer底图、version瓦片集版本等可选字段。tiles 瓦片表真正存放图片的地方tiles表是 MBTiles 的绝对核心它有四列zoom_level缩放级别、tile_column瓦片列号、tile_row瓦片行号和tile_data瓦片二进制数据。每一行就是一张瓦片tile_data以 BLOB 形式保存 PNG、JPEG 或矢量瓦片数据。grids / grid_data 交互表让地图「可点击」这两张可选表用于存放UTFGrid交互数据grids表保存 gzip 压缩的网格数据grid_data表保存网格键到 JSON 值的映射。有了它们鼠标悬停在地图上就能弹出「这里是法国」「这条是高速公路」之类的提示信息。详细存储规则见 1.1/utfgrid.md 与 1.1/interaction.md。瓦片坐标定位原理zoom_level / tile_column / tile_rowMBTiles 采用经典的金字塔瓦片模型缩放级别 zoom 越大地图被切分得越细。在缩放级别 z地图被分成 2^z × 2^z 张瓦片列号从西到东、行号从北到南编号这样就得到了每一张瓦片的唯一坐标(z, x, y)。这里有一个新手最容易踩的坑 ⚠️MBTiles 遵循TMSTile Map Service规范其 Y 轴方向与常见的「XYZ」网络瓦片坐标相反。例如 URL 中常见的11/327/791这张瓦片在 MBTiles 中要写成zoom_level11, tile_column327, tile_row1256——因为1256 2^11 - 1 - 791。同时规范强制要求使用global-mercator球形墨卡托投影这一点在 1.3/spec.md 中有明确说明。MBTiles 1.3 矢量瓦片json 元数据与 tilestats从 1.3 版本开始规范重点补充了矢量瓦片format 为pbf的支持。这类瓦片集必须在metadata表中额外提供一个json字段字符串化的 JSON 对象其中包含两个关键部分vector_layers列出瓦片中出现的所有图层以及每个图层的字段名与类型Number、Boolean、String帮助渲染端提前了解数据tilestats可选字段统计每个图层的属性取值范围和示例值方便客户端做样式预判。例如一个包含美国县级行政区与主干道路的矢量瓦片集其json字段就清晰描述了tl_2016_us_county图层及其GEOID、NAME等字段。完整的元数据与示例可见 1.3/spec.md 中的「Vector tileset metadata」小节。MBTiles 版本演进从 1.0 到 1.3 改了什么不同年代的工具生成的 MBTiles 文件可能对应不同版本了解演进史能帮你快速排查兼容性问题版本核心变化1.0最早的规范metadata表仅要求name、type、version、description四键瓦片仅支持 png/jpg1.1新增必须的format字段与建议的bounds字段引入可选 UTFGrid 交互规范1.2将 UTFGrid 拆分为独立规范版本号同步交互逻辑移交给 UTFGrid 1.21.3新增矢量瓦片pbf支持补充json元数据与tilestats元数据字段按实际使用修订完整变更记录参见 CHANGELOG.md各版本规范分别存放于 1.0/spec.md、1.1/spec.md、1.2/spec.md 和 1.3/spec.md。如何快速验证一个 MBTiles 文件想亲手验证某个.mbtiles文件是否合规由于它本质是 SQLite 数据库直接用命令行工具就能探查以下为示意命令# 查看元数据 sqlite3 world.mbtiles SELECT name, value FROM metadata; # 查看瓦片数量与格式 sqlite3 world.mbtiles SELECT format, COUNT(*) FROM tiles; # 查看瓦片坐标范围 sqlite3 world.mbtiles SELECT MIN(zoom_level), MAX(zoom_level) FROM tiles;如果metadata表含name与format两行、tiles表结构正确这个文件基本就符合规范了。想要进行更严格的 UTFGrid 兼容性测试仓库还提供了包含 65501 个不同键的测试网格 1.1/demo.json供实现者校验坐标与键的映射是否正确。新手常见问题FAQQ1MBTiles 与普通的图片瓦片文件夹有什么区别普通瓦片以「文件夹/层级/x/y.png」的目录结构散落存放管理混乱、传输慢MBTiles 用单个 SQLite 文件整合全部瓦片便于拷贝、压缩和快速检索。Q2MBTiles 支持哪些瓦片格式1.2 及以前仅支持png和jpg1.3 起支持pbf矢量瓦片、webp以及其他 IETF 媒体类型。Q3MBTiles 是矢量数据格式吗不是。它本质是已渲染瓦片的容器只有 format 为pbf时内部才存放 Mapbox Vector Tile 矢量数据。Q4一个 MBTiles 文件可以放多张地图吗规范约定一个文件只代表一个 tileset一张地图多张地图请使用多个.mbtiles文件。结语如何深入掌握 MBTiles 规范MBTiles 之所以长盛不衰正因为它「小而美」容器只用 SQLite定位只用一套坐标交互数据可选——简单到极致反而成就了极高的兼容性与生态广度。无论是做离线地图 App、GIS 数据分发还是自建瓦片服务理解这份规范都能让你事半功倍。想要通读原文克隆仓库到本地即可边看边实践git clone https://gitcode.com/gh_mirrors/mb/mbtiles-spec从 README.md 出发按 1.3/spec.md → 1.2/spec.md → 1.1/spec.md 的顺序阅读你就能完整掌握这份地图瓦片格式规范的精髓。祝你在瓦片地图的世界里玩得开心【免费下载链接】mbtiles-specspecification documents for the MBTiles tileset format项目地址: https://gitcode.com/gh_mirrors/mb/mbtiles-spec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
