为什么我可以请求步行或骑行等时线，时长最多为 2 小时，但驾车等时线的时长上限为 1 小时？
此限制基于计算的复杂性。在相同的时间内，车辆的行驶距离远大于行人或骑行者，这意味着必须分析的基础道路网络呈指数级扩展。驾车等时线的时长上限为 1 小时（3,600 秒），以确保 API 可以在快速的实时同步窗口中返回响应，而步行和骑行等时线的时长上限为 2 小时（7,200 秒）。
如何计算入站“通勤上班”等时线（前往目的地）与出站等时线（从出发地出发）？
v1 API 使用 travel_direction 参数支持入站和出站计算：
FROM（出站）：计算在指定时间限制内从出发点 可以到达的区域。from这适用于配送区域或服务覆盖范围等用例。TO（入站）：计算在指定时间限制内可以从哪些区域到达to出发点。这适用于通勤上班功能或确定中心办公室或交通枢纽周围的集水区等应用。
有时，返回的多边形看起来呈块状，或者边缘呈锯齿状或阶梯状，尤其是在时长较长的情况下。为什么详细程度会发生变化？
等时线 API 会根据请求的 travel_duration 和 travel_mode 动态调整其空间计算网格的分辨率：
- 时长较短：使用高度精细的高分辨率网格，因为总面积较小，因此边界详细。
- 时长较长：过渡到更粗糙、分辨率更低的网格，以便高效覆盖广阔的地理区域，而不会导致严重的延迟。
如果您需要特定且一致的详细程度，无论时长如何，都可以将可选的 polygon_fidelity 设置为 HIGH、MEDIUM 或
LOW。
为什么有时请求公园、湖泊或大型工业园区内的坐标的等时线会返回“未找到”错误？
等时线 API 使用道路和路径计算行程时间。如果请求的出发地坐标不在已识别的道路上，API 必须先将该点“吸附”到最近的兼容路段，然后才能开始计算。
每种出行方式都有特定的最大吸附距离阈值：
DRIVE：200 米（忽略仅限行人的路径）。BICYCLE：180 米。WALK：150 米。
如果您的出发地坐标与有效且与出行方式兼容的路段的距离超过这些阈值，则吸附失败，并且 API 会返回 NOT_FOUND
错误。如需解决此问题，请确保您的坐标位于公共街道或路径附近。
在地图上呈现 GeoJSON 响应时，形状显示在错误的位置、失真或无法呈现。这是什么原因造成的？
这几乎总是由坐标顺序不匹配引起的。
根据 GeoJSON 标准 (RFC 7946)，等时线 API 会按 [longitude, latitude]
的顺序返回坐标。但是，许多地图 SDK（包括 Google Maps JavaScript API 和各种移动地图组件）都希望坐标或
LatLng 对象按 [latitude, longitude] 的顺序排列。
如果地图呈现不正确，您必须遍历 GeoJSON 载荷中的坐标，并在将这些坐标传递给地图 SDK 之前转置这些值。
为什么我的等时线多边形内有空心的“孔洞”，我可以改为获取实心形状吗？
孔洞表示在时间限制内没有可到达的道路的区域。这在有大片森林、水体、机场或车辆或行人无法通行的私人财产的区域很常见。
外部 v1 API 不会公开用于自动移除孔洞的参数。 如果您的应用需要实心边界（例如，执行多边形内点包含检查），您可以：
- 将
polygon_fidelity参数设置为MEDIUM或LOW，以鼓励算法对这些内部间隙进行泛化和合并。 - 使用客户端 GIS 库（例如 Turf.js）解析 GeoJSON，并仅提取第一个坐标环（外部外壳），舍弃任何后续内部环（孔洞）。
我是否应为后端空间分析启用 enable_smoothing 选项？
否。enable_smoothing 参数纯粹是为了视觉美观而设计的。
它会使底层计算网格的尖角变圆，使形状在地图上看起来更自然。
对于精确的空间分析，不建议使用平滑处理，因为它会改变顶点并稍微移动边界。对于后端计算、数据库查询或多边形内点测试，请将
enable_smoothing 设置为 false，以确保您使用的是数学上精确的计算边界。