在任何地图技术栈里，边界框都是最简单、最有用的空间基础单元。它用四个数字描述经纬度空间中的一个矩形，你会用到的几乎每个 API 调用、GeoJSON 文件和地图库里都有它。
本文介绍边界框是什么、你需要知道的格式约定、它在生产环境中最有用的几种用法，以及每个开发者至少会踩一次的坑。
定义
边界框（bbox）是包含某个要素或一组点的最小轴对齐矩形。「轴对齐」指矩形的各边沿纬度和经度方向，矩形没有旋转。边界框由四个数字描述：西边界经度、南边界纬度、东边界经度和北边界纬度。
巴黎市的官方bbox约为 [2.224, 48.8156, 2.4699, 48.9022]，包括科西嘉岛在内的法国本土约为 [-5.142, 41.333, 9.560, 51.089]，整个地球则为 [-180, -90, 180, 90]。
边界框始终由两个对角确定。它描述不了非矩形的形状，但能描述包住任意形状的那个矩形，这对快速空间过滤已经足够。
格式问题
不同系统对边界框格式的约定并不一致，大多数 bbox bug 都源于此。
GeoJSON、OGC标准及大多数现代API：[west, south, east, north]，即 [minLng, minLat, maxLng, maxLat]。经度在前，纬度在后，均为WGS84坐标。
Leaflet：使用 LatLngBounds 对象，包含 _southWest 和 _northEast 两个角点，纬度在前，经度在后。Mapbox GL 和 MapLibre 使用 LngLatBounds，经度在前。
许多旧版API和CSV导出：[south, west, north, east]（纬度在前）。请阅读规范。
瓦片服务和WMS：当瓦片使用EPSG:3857时，bbox以投影单位（Web Mercator米）而非经纬度表示。
一条稳妥的规则：在自己的代码里，不要直接用 4 个元素的数组。把它包装成带命名字段的类型化对象（{ west, south, east, north }），让顺序一目了然，只在调用 API 的边界处做转换。
边界框最有用的地方
边界框是最快的空间过滤方式。三种经典用法：
让地图缩放到要素。 用户打开某个搜索结果时，调用 map.fitBounds(bbox)，地图就会缩放和平移，带适当留白显示这个要素。每个现代地图库都内置了这个基础功能。
按区域过滤API查询。 数据库引擎和搜索 API 能非常高效地为边界框建索引。「显示当前视口内的所有地点」这类查询，会把可见区域的 bbox 发送到服务器，服务器用空间索引只返回匹配的记录。基于视口的搜索就建立在这个基础上。
让自动补全和地理编码偏向当前区域。 把用户当前地图的 bbox 作为视口偏向参数传入，地理编码器会提高 bbox 内结果的权重。所以在纽约视口内输入「Liberty」，最先返回的是自由女神像，而不是世界上其他叫 Liberty 的地方。
还有一个不太显眼的用途：在矢量瓦片系统中，边界框是管理瓦片的基本单位。每张瓦片在某个缩放级别下覆盖一个已知的边界框，渲染器再把它们拼成你看到的地图。
API 返回什么
大多数地理编码 API 会为每个匹配结果附带一个 bbox。它既告诉你匹配要素有多大（国家的 bbox 很大，建筑的 bbox 很小），也告诉你地图该怎样缩放。查询「France」会返回国家级的 bbox，查询「10 Downing Street」会返回建筑级的 bbox。
你可以用返回的 bbox 大小来检验精度是否合理。匹配精度是「country」却返回建筑大小的 bbox，这很可疑；匹配精度是「rooftop」却返回城市大小的 bbox，那就肯定出错了。
跨越反子午线的边界框
一个容易忽略的坑：跨越 180 度反子午线的边界框（如俄罗斯、太平洋、斐济）无法满足 west < east，因为它绕过了经度的首尾。各系统的处理方式不同：
- 有的系统把这类边界框拆成两块，反子午线两侧各一块。
- 有的系统允许
west > east，并把它理解为「绕过反子午线」。 - GeoJSON（RFC 7946）允许 west 大于 east 的边界框，但跨越反子午线的几何图形应切成两部分。
大多数欧洲或单一国家的场景遇不到这个问题。如果你做的是全球性产品（航线、航运、渔业），请专门测试跨反子午线的情况。
边界框与多边形
边界框是矩形，真实要素却很少是矩形。法国的边界框包含了部分大西洋和部分西班牙，曼哈顿的边界框包含了新泽西州和皇后区的一部分。
如果矩形近似已经够用（缩放地图、快速预过滤），边界框就是合适的工具。如果你要判断某个点是否真的在要素内部，就需要用真实的边界几何做点在多边形内的判断。生产环境中的常见做法是：先用边界框过滤（快、可建索引，能排除大部分记录），再对剩下的结果做点在多边形内判断（慢，但准确）。大多数空间数据库的底层就是这样分两步工作的。
计算机视觉中的边界框
在目标检测、机器人或 3D 渲染中，你可能会看到「定向边界框」。这是另一个概念：OBB 会旋转，比轴对齐的框更紧密地贴合要素。在地理空间开发中，轴对齐边界框是标准，因为它便于建索引，能对齐瓦片网格，判断重叠也很简单。只有需要旋转矩形计算时才会用到定向边界框，这在地图领域很少见，在计算机视觉中却很常见。
MapAtlas 如何使用边界框
Geocoding API和Search API的每个结果都带有 bbox 字段，按 WGS84 经度、纬度的顺序给出匹配要素的范围，正是 GeoJSON 和现代地图库要求的格式。你可以传入 boundary.rect.* 参数，让地理编码结果偏向某个视口。Isochrone API 返回出行时间多边形时也会附带外包 bbox，你不用自己计算就能缩放地图。
想动手了解 GeoJSON，以及边界框在整个空间数据体系中的位置，请看什么是GeoJSON和什么是地理编码。
常见问题
什么是边界框？
边界框（通常简写为bbox）是包含某个地理要素或一组点的最小轴对齐矩形。它由四个数字描述：最小和最大经度，以及最小和最大纬度。边界框在地图开发中无处不在：让地图缩放到某个要素、按区域过滤数据库查询、定义瓦片的范围，以及让地理编码结果偏向某个区域。在生产代码里，它是最简单、最快的空间基础单元。
边界框的标准格式是什么？
GeoJSON和大多数现代API使用 [west, south, east, north] 的顺序，也写作 [minLng, minLat, maxLng, maxLat]。这是你应该默认采用的格式。部分旧版API和CSV导出使用 [south, west, north, east]（即纬度在前），少数使用四个独立字段。用之前务必查阅对应 API 或格式的文档。最常见的错误是把经纬度顺序弄反，边界框就跑到了地球另一边。
边界框和定向边界框有什么区别？
普通边界框是轴对齐的：各边沿纬度和经度方向。定向边界框（OBB，常见于计算机视觉和游戏引擎）会旋转，以便更紧密地贴合要素，面积更小，但计算更复杂。在地理空间开发中，轴对齐边界框是标准做法，因为它便于在空间数据库中建索引，能对齐瓦片网格，判断重叠也非常简单。定向边界框出现在3D渲染、目标检测和物理引擎中。
如何用边界框过滤地理编码API？
把 bbox 作为视口偏向参数传入。在MapAtlas Geocoding API中，发送 boundary.rect.min_lon、boundary.rect.min_lat、boundary.rect.max_lon、boundary.rect.max_lat，地理编码器会把该区域内的结果排在区域外的结果前面。地图内的自动补全离不开这一点：用户平移地图时，你随之更新 bbox，让建议与用户正在看的区域一致。没有 bbox 偏向，输入「Springfield」会返回全球知名度最高的那个 Springfield，而这很少是用户想要的。
