raf*_*ira 5 python csv gps r gtfs
我有一个自动车辆定位（AVL）数据集，采用.csv城市公共交通系统的格式。我想使用这个 AVL 数据集构建GTFS 数据集，以便运行可访问性分析。
我已经看到了如何根据SQL database（此处）中存储的 GPS 数据创建 GTFS 数据集的解决方案，但是当 GPS 数据以格式存储时，我还没有找到解决方案.csv，这里就是这种情况。我很高兴能对此提供任何帮助，但如果解决方案能够出现或出现，我会很R高兴Python。
我已经有了stops.txtGTFS 的文件，但我想我需要创建文件shapes.txt、tips.txt和routes.txt。stop_times.txt
这就是我的GPS.csv数据集的样子：
timestamp order line lat long speed route_name
1: 2016-02-24 00:04:56 B27084 905 -22.9 -43.3 32.00 12860326
2: 2016-02-24 00:05:07 B41878 2302 -22.9 -43.2 0.19 12860386
3: 2016-02-24 00:04:37 B75563 928 -22.9 -43.2 0.00 12867184
4: 2016-02-24 00:05:17 D86084 852 -23.0 -43.6 24.26 12860043
5: 2016-02-24 00:04:58 C41420 -22.9 -43.2 0.00 NA
6: 2016-02-24 00:04:47 C30084 -23.0 -43.3 0.00 NA
有五个必需文件：agency.txt、routes.txt、trips.txt、stop_times.txt和stops.txt。对于仅用于计算可访问性目的的伪 GTFS，可以省略必需文件中的许多可选字段以及所有可选文件。但是，您可能想要复制真实的或构建它们，因为它们对于此目的很有用（例如，人们在选择旅行方式时会考虑票价，因此您可以使用fares.txt）。
仔细阅读规格。
\n\n如果可以想象所有路线都由同一机构提供服务，那么您的路线可以简单地是：
\n\nagency_id,agency_name,agency_url,agency_timezone,agency_lang,agency_phone\nXXX,My Awesome Agency,http://example.com,,,\n即您只需要前三个字段。
\n\nagency.txt旨在代表：
\n\n\n提供此源中的数据的一个或多个交通机构。
\n
你需要：
\n\nroute_id（首要的关键）route_short_nameroute_long_nameroute_type（必须在 0\xe2\x80\x937 范围内；表示模式）例子：
\n\nroute_id,agency_id,route_short_name,route_long_name,route_desc,route_type,route_url,route_color\n12860326,XXX,12860326,12860326,,3,,\n12860386,XXX,12860386,12860386,,3,,\n12867184,XXX,12867184,12867184,,3,,\n我不知道如何处理示例数据中没有分配路线的路线。我也不知道order指的是什么。也许order是路线的名称？只要你能想出与“路线”标识符相同概念的东西，你就可以使用它。作为参考，“路线”定义为：
\n\n\n路线是作为单一服务向乘客显示的一组行程。\n
\n
\n\n\n行程是在特定时间发生的两次或多次停靠的序列。
\n
你需要：
\n\ntrip_id（首要的关键）route_id（外键）service_id（外键）例子：
\n\nroute_id,service_id,trip_id,trip_headsign,direction_id,block_id,shape_id\n12860326,1,1,,1,,12860326\n12860326,1,2,,1,,12860326\n12860386,1,1,,1,,12860386\n12860386,1,2,,2,,12860386\ndirection_id虽然是可选的，但往往非常有用，而且我有几个摄取 GTFS 的应用程序需要它，尽管它处于可选状态。
service_id很棘手，并且与日历日期结合使用。它允许 GTFS 轻松地表示“正常”工作日服务以及工作日假日期间的假日服务。出于您的目的，您可能可以用于1所有用途，但这取决于您的应用程序以及收集 AVL 数据的时间。当我开发类似的应用程序时，我在数据库中维护了一个查找表，该表告诉我特定日期是否是公共假期，和/或学校假期，和/或在大学学期期间，因为公交车路线发生了变化以适合学生。
shape_id是可选的，但如果您想在地图上绘制路线或使用 OpenTripPlanner 等工具，则至关重要。
\n\n\n每次行程车辆到达和离开各个站点的时间。
\n
你会需要：
\n\nstop_id（首要的关键）trip_id（外键）arrival_timedeparture_timestop_sequence这在编写脚本时需要最多的工作。它将比所有其他文件的总和大几个数量级。
\n\nstop_id并trip_id愉快地与已经确定的站点和行程联系起来。和将位于AVL 数据的两行departure_time中，在许多情况下，实际识别服务何时到达站点是此任务中最困难的方面。访问乘客智能卡数据会更容易，并且当服务实际停止时，您可能会发现 AVL 记录的空间集群，因为车辆在特定时间段内不会移动。然而，如果车站是空的并且没有人想要下车，则很难确定服务何时真正“到达”车站——特别是因为如果司机不打算下车，他们的行为有时可能会改变按计划停下来（例如，如果他们看到没有人在等待，则走得更快或走捷径）。对于您的情况，该值可能会有所帮助，但请注意不要将乘客停靠站与交叉路口混淆。arrival_timespeed
stop_sequence是可选的，但也是应用程序通常期望它存在的另一种情况。无论如何，如果您的脚本无法识别stop_sequence，那么您可能无法正确创建此文件。
例子：
\n\ntrip_id,arrival_time,departure_time,stop_id,stop_sequence,stop_headsign,pickup_type,drop_off_type,shape_dist_traveled\n1,00:05:07,00:05:54,22018,1,,1,1,0\n1,00:07:16,00:08:01,22557,2,,1,1,39\n1,00:10:56,00:10:56,22559,3,,1,1,76\n指示停留时间是可选的，因此如果这太难计算出来，arrival_time并且departure_time可以有效地是同一时刻。
在实践中，pickup_type和drop_off_type非常有影响力，但通常无法仅根据 AVL 数据来确定，除非您的 AVL 收集器确实考虑过在其档案中支持 GTFS……不幸的是，这不太可能。您可能只需要始终允许两者，除非您有可以插入的其他信息（例如“工作日晚上第 4 站之后路线 1 上的所有行程仅让乘客下车”）。
stop_id（首要的关键）stop_namestop_lonstop_lat你说你已经有了这个，这太好了。真正的挑战在于如何stop_times通过stop_id外键进行交互。幸运的是，我使用的 AVL 数据使用与时间表的 GTFS 表示中相同的代码来确定服务何时停止以及在哪一站停止。
为了使用 OpenTripPlanner 等工具获得良好的结果，您可能需要包含一个calendar.txt文件。如果您采用对定义的时间段进行建模的方法，这也有助于确定伪 GTFS 的有效期。例如：
service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date\n1,1,1,1,1,1,0,0,20160224,20160226\n2,0,0,0,0,0,1,1,20160224,20160226\n3,0,0,0,0,0,1,0,20160224,20160226\n这表明这些服务的建模期间为 2016 年 6 月 24 日至 2016 年 6 月 26 日。该范围之外请求的任何路线都有未定义的行程时间。我建议您选择不超过一周的时间段：超过一周，使用 GTFS 的应用程序将开始与数据量作斗争。真正的 GTFS 数据可以从冗余中受益，而“伪”数据却无法做到这一点。
\n\n不用担心shape_dist_traveled，我只是使用虚拟信息（单调递增）：它可以从形状推断出来，除非形状太笼统。
例子：
\n\nshape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled\n12860386,-22.9,-43.3,1,1\n12860386,-22.0,-42.9,2,2\n总体思路是使用现有的 AVL 数据来满足符合规范的传输源的最低要求。您可能需要编写自己的脚本来创建这些文件，因为 AVL 数据没有标准。您可以编造一些信息，并且您可能需要：当您尝试使用不完整的提要时，大多数应用程序都会引发异常。事实上，根据我的经验，相当多的应用程序实际上会遇到只满足最低要求的提要问题，因为程序很差，而且大多数现实世界的数据都有点超出最低标准。
\n\n您可能会发现 AVL 数据存在缺陷，导致难以使用。最值得注意的例子是路线确实运行，但 AVL 不起作用。在这种情况下，您的伪 GTFS 将无法准确地代表实践中的交通系统。这些几乎不可能被发现。
\n\n在这种情况下，我不明白您的order、line和route字段之间的区别。您需要确定这些最适合的位置；我忽略了它们，因为我不明白它们代表什么。您需要将 AVL 模式与 GTFS 的概念相匹配。
交通系统往往非常复杂，但也有很多小例外。您最终可能会排除一些特别异常的案例。
\n\n您的纬度和经度值看起来不太精确：如果这是真实数据，您可能无法使用shapes.txt. 尝试要求车辆位置更精确。
| 归档时间： |
|
| 查看次数： |
680 次 |
| 最近记录： |