边界框是任何地图技术栈中最简单、最实用的空间基元。它由四个数字描述一个经纬度空间中的矩形，出现在你将要使用的几乎每个API调用、GeoJSON文件和地图库中。
本文解析边界框的含义、你需要了解的格式规范、它在生产中发挥关键作用的使用模式，以及每位开发者至少会踩一次的坑。
定义
边界框（bbox）是包含某个要素或一组点的最小轴对齐矩形。「轴对齐」意味着其各边沿纬度和经度轴方向延伸，矩形不经过旋转。bbox由四个数字描述：最西侧经度、最南侧纬度、最东侧经度和最北侧纬度。
巴黎市的官方bbox约为 [2.224, 48.8156, 2.4699, 48.9022]，法国本土约为 [-5.142, 41.333, 9.560, 51.089]，整个地球则为 [-180, -90, 180, 90]。
bbox始终是两个对角。它无法描述非矩形形状，但可以描述包裹任意形状的矩形，这已足够用于快速空间过滤。
格式问题
bbox的格式规范在不同系统间并不一致，而这种不一致正是大多数bbox bug的根源。
GeoJSON、OGC标准及大多数现代API：[west, south, east, north]，即 [minLng, minLat, maxLng, maxLat]。经度在前，纬度在后，均为WGS84坐标。
部分网络地图库（Leaflet、Mapbox GL bounds对象）：使用带有 _southWest 和 _northEast 角落的 LatLngBounds 对象，纬度在前，经度在后。
许多旧版API和CSV导出：[south, west, north, east]（纬度在前）。务必阅读规范文档。
瓦片服务和WMS：当瓦片使用EPSG:3857时，bbox以投影单位（Web Mercator米）而非经纬度表示。
防御性建议：在自己的代码中避免使用裸4元素数组，将其包装为带有命名字段的类型化对象（{ west, south, east, north }），使顺序显而易见，并在API边界处进行转换。
边界框的核心应用
bbox是最快速的空间过滤器，有三类经典用途：
将地图适配到要素。 当用户落在某个搜索结果上时，调用 map.fitBounds(bbox)，地图就会缩放平移以在合适的留白内展示该要素。每个现代地图库都内置了这个基本操作。
按区域过滤API查询。 数据库引擎和搜索API对bbox建立索引非常高效。「显示当前视口内的所有地点」这类查询，会将可见bbox发送到服务器，服务器使用空间索引只返回匹配的记录，这是基于视口搜索的基础机制。
偏置自动补全和地理编码。 将用户当前地图bbox作为视口偏置参数传入，地理编码器会对bbox内的结果赋予更高权重，在纽约视口内输入「Liberty」就会优先返回自由女神像，而非世界上其他任何地方的Liberty。
还有一个不那么显眼的用途：bbox是矢量瓦片系统的记账单元。每张瓦片在已知缩放级别下覆盖已知的bbox，渲染器将它们合成为可见地图。
API返回的内容
大多数地理编码API会在每个匹配结果旁边返回bbox，因为它既告诉你匹配要素的大小（国家bbox很大，建筑bbox很小），也告诉你如何适配地图。「France」的地理编码响应返回国家级bbox，「10 Downing Street」的响应返回建筑级bbox。
可以用返回的bbox大小作为精度的合理性检验。一个声称在「country」精度级别匹配但返回建筑级bbox的查询是可疑的；一个声称在「rooftop」精度级别匹配但返回城市级bbox的查询则明显有问题。
跨越反子午线的边界框
一个微妙的陷阱：跨越180度反子午线的bbox（如俄罗斯、太平洋、斐济）无法用 west < east 来描述，因为它需要绕圈。各系统的处理方式不同：
- 部分系统将这类bbox拆分为两段，分别对应反子午线两侧。
- 部分系统允许
west > east并将其解释为「绕圈」。 - GeoJSON允许绕圈，但出于互操作性考虑建议拆分。
对于大多数欧洲或单国家用例，这种情况不会出现。如果你构建全球性产品（航线、航运、渔业），请明确测试反子午线这个边界情况。
边界框与多边形
bbox是矩形，真实要素很少是矩形。法国的bbox包含了大西洋的一部分和西班牙的一部分，曼哈顿的bbox包含了新泽西州和皇后区的部分区域。
当矩形近似已经足够（适配地图、快速预过滤）时，bbox是正确的工具。当你需要判断某个点是否真正位于要素内部时，需要对真实边界几何图形进行点在多边形内的数学计算。一种常见的生产模式是：先用bbox过滤（快速、可索引，可排除99%的记录），再对剩余结果进行点在多边形内计算（较慢但精确）。这种两阶段方法正是大多数空间数据库底层的工作原理。
计算机视觉中的边界框
在目标检测、机器人技术或3D渲染中，你可能会看到「定向边界框」的概念。这是一个不同的概念：OBB经过旋转，比轴对齐框更紧密地贴合要素。在地理空间工作中，轴对齐bbox是标准，因为它可以干净地建立索引、适配瓦片网格，且重叠检测极为简单。定向bbox在需要旋转矩形数学运算的场景中才会用到，在地图领域较为罕见，在计算机视觉中则很常见。
MapAtlas如何使用边界框
Geocoding API和Search API的每个结果都返回 bbox 字段，以WGS84经度/纬度顺序表示匹配要素的范围，这正是GeoJSON和现代地图库所期望的格式。你可以传递 boundary.rect.* 参数将地理编码限定到某个视口，Isochrone API也会为其出行时间多边形返回包裹bbox，让你无需自行计算即可适配地图。
如需动手了解GeoJSON以及bbox在更大空间数据图景中的位置，请参阅什么是GeoJSON和什么是地理编码。
常见问题
什么是边界框？
边界框（通常简写为bbox）是包含某个地理要素或一组点的最小轴对齐矩形。它由四个数字描述：最小和最大经度，以及最小和最大纬度。边界框在地图应用中无处不在：用于将地图适配到某个要素、按区域过滤数据库查询、定义瓦片的范围，以及将地理编码结果偏置到特定区域。它是生产代码中最简单、最快速的空间基元。
边界框的标准格式是什么？
GeoJSON和大多数现代API使用 [west, south, east, north] 的顺序，也写作 [minLng, minLat, maxLng, maxLat]。这是你应该默认采用的格式。部分旧版API和CSV导出使用 [south, west, north, east]（即纬度在前），少数使用四个独立字段。务必查阅具体API或格式的文档。最常见的错误是混淆经纬度顺序，导致边界框落在地球的错误位置。
边界框和定向边界框有什么区别？
普通边界框是轴对齐的：其各边沿纬度和经度轴方向延伸。定向边界框（OBB，常见于计算机视觉和游戏引擎）经过旋转以更紧密地贴合要素，占用面积更小但数学计算更复杂。在地理空间工作中，轴对齐bbox是标准选择，因为它可以干净地索引到空间数据库中，适配瓦片网格，且重叠检测极为简单。定向边界框出现在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，而这通常不是用户的意图。
