北京
把时钟从早上5点拨到次日凌晨4点，新泽西州默瑟县（Mercer County）的蓝色步行可达区域会一点点缩水。缩到凌晨3点，全县14,095户无车家庭被甩出步行可达范围，占全县无车家庭总数的87.5%。
这个数字来自一个名为 Desert Hours 的开源项目。它用 Amazon Location Service 把"公交荒漠"按小时算了一遍——不是给每个区域打一个静态分数，而是给工作日每一个小时各打一次分。研究区覆盖特伦顿（Trenton）、普林斯顿（Princeton）和一圈郊区，全县144,114户家庭中有16,114户没有汽车。
怎么算出来的
数据管线先挑出公交时刻表里的某一个周三，按小时统计每个站点的发车班次。站点范围不只看县内，还向外扩了1.5公里——人会跨县界去赶车。筛完剩下1,012个站点。
每个站点再向 Amazon Location 要一张10分钟步行等时圈（Pedestrian isoline），沿街道网络生成。形状取决于站点周边的路网：同样最远伸到约560米，城市网格和郊区路网画出来的面积并不一样。1,012个站点的中位数是0.26平方公里，而一个半径400米的圆是0.50平方公里。
无车家庭不按面积平摊。普查区里混着公园、铁路货场和农田，均匀撒点会把"人"算到没人住的地方。做法是：普查区内的无车家庭数，按各普查街区（Census block）的住房单元数分摊；某个街区在某一小时被算作"有服务"，条件是它的内部点落在该小时的服务区内。
每小时把"该小时至少有一班发车"的站点步行区拼起来，再拿所有街区去测，就得到这一小时的可达总量。计数由代码完成，页面直接引用结果。
步行圈讲不出的故事，交给公交路径规划
等时圈只覆盖步行和驾车两种模式。要算真实行程，得用 CalculateRoutes 的 Transit 模式，带上时刻表发车信息。从特伦顿到普林斯顿，请求凌晨2点出发，返回的是一段带时间的旅程：3小时9分钟，大部分时间花在等第一班车上。管线把这整段等待都存了下来。
结果以 GeoJSON 和 HTML 静态文件的形式放在私有 S3 桶里，前面挂 CloudFront。全部预计算之后，页面只留一个 Amazon Location 密钥，权限限定在地图操作和站点域名。结论写在页面 HTML 里，不开 JavaScript 也能读；MapLibre 负责在 Amazon Location 底图上画普查区和服务区。
一个普查区的一天
特伦顿第1普查区是特拉华河沿岸的一条狭长地带，1,332户里约445户无车，误差范围±227。它的可达比例从早上8点的73%掉到晚上11点的0%。
全县层面，早上8点有6,388户无车家庭走不到服务，占39.6%；到凌晨3点变成14,095户、87.5%。
两种工具，各管一段
什么时候用等时圈？当"可达"取决于街道网络时——任何郊区都是这种情况。什么时候用 Transit 路径规划？当你要讲一个地图形状讲不出的故事，比如凌晨2点的一趟行程到底要多久。两者都放进批处理管线，线上页面就永远不用为路径规划花钱。
费用按 AWS 价目表费率算术累加；结果有缓存，重建不会产生新的调用。
范围需要说清楚：只统计一个工作日的计划班次，可能不完整、不准确或已过时。TigerTransit、普林斯顿市政穿梭巴士、Z-Line 和按需服务都不在统计内，这些线路覆盖的地方可达性被低估。Route 130 Connection 的站点用的是2023年9月的时刻表，只要该小时有发车就计入。无车家庭被假定在普查区内按住房分布摊开，普查区估计本身误差范围很宽。行程时间每个普查区取一个点。时刻表数据来自 NJ TRANSIT 通过 Mobility Database 存档发布的 GTFS，项目与 NJ TRANSIT 无关。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
