You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/main/java/com/conveyal/datatools/manager/jobs/MergeFeedsJob.java
+5-76Lines changed: 5 additions & 76 deletions
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,8 @@
55
55
* found in any other feed version. Note: There is absolutely no attempt to merge
56
56
* entities based on either expected shared IDs or entity location (e.g., stop
57
57
* coordinates).
58
-
* - {@link MergeFeedsType#SERVICE_PERIOD}: this strategy is defined in detail at https://github.com/conveyal/datatools-server/issues/185,
58
+
* - {@link MergeFeedsType#SERVICE_PERIOD}:
59
+
* this strategy is defined in detail at https://github.com/conveyal/datatools-server/issues/185,
59
60
* but in essence, this strategy attempts to merge an active and future feed into
60
61
* a combined file. For certain entities (specifically stops and routes) it uses
61
62
* alternate fields as primary keys (stop_code and route_short_name) if they are
@@ -66,55 +67,6 @@
66
67
* prefer entities from the active version, so that entities edited in Data Tools would override the values found
67
68
* in the "future" file, which may have limited data attributes due to being exported from scheduling software with
68
69
* limited GTFS support.
69
-
*
70
-
* Reproduced from https://github.com/conveyal/datatools-server/issues/185 on 2019/04/23:
71
-
*
72
-
* 1. When a new GTFS+ feed is loaded in TDM, check as part of the loading and validation process if
73
-
* the dataset is for a future date. (If all services start in the future, consider the dataset
74
-
* to be for the future).
75
-
* 2. If it is a future dataset, automatically notify the user that the feed needs to be merged with
76
-
* most recent active version or a selected one in order to further process the feed.
77
-
* 3. Use the chosen version to merge the future feed. The merging process needs to be efficient so
78
-
* that the user doesn’t need to wait more than a tolerable time.
79
-
* 4. The merge process shall compare the active and future datasets, validate the following rules
80
-
* and generate the Merge Validation Report:
81
-
* i. Merging will be based on route_short_name in the active and future datasets. All matching
82
-
* route_short_names between the datasets shall be considered same route. Any route_short_name
83
-
* in active data not present in the future will be appended to the future routes file.
84
-
* ii. Future feed_info.txt file should get priority over active feed file when difference is
85
-
* identified.
86
-
* iii. When difference is found in agency.txt file between active and future feeds, the future
87
-
* agency.txt file data should be used. Possible issue with missing agency_id referenced by routes
88
-
* iv. When stop_code is included, stop merging will be based on that. If stop_code is not
89
-
* included, it will be based on stop_id. All stops in future data will be carried forward and
90
-
* any stops found in active data that are not in the future data shall be appended. If one
91
-
* of the feed is missing stop_code, merge fails with a notification to the user with
92
-
* suggestion that the feed with missing stop_code must be fixed with stop_code.
93
-
* v. If any service_id in the active feed matches with the future feed, it should be modified
94
-
* and all associated trip records must also be changed with the modified service_id.
95
-
* If a service_id from the active calendar has both the start_date and end_date in the
96
-
* future, the service shall not be appended to the merged file. Records in trips,
97
-
* calendar_dates, and calendar_attributes referencing this service_id shall also be
98
-
* removed/ignored. Stop_time records for the ignored trips shall also be removed.
99
-
* If a service_id from the active calendar has only the end_date in the future, the end_date
100
-
* shall be set to one day prior to the earliest start_date in future dataset before appending
101
-
* the calendar record to the merged file.
102
-
* trip_ids between active and future datasets must not match. If any trip_id is found to be
103
-
* matching, the merge should fail with appropriate notification to user with the cause of the
104
-
* failure. Notification should include all matched trip_ids.
105
-
* vi. New shape_ids in the future datasets should be appended in the merged feed.
106
-
* vii. Merging fare_attributes will be based on fare_id in the active and future datasets. All
107
-
* matching fare_ids between the datasets shall be considered same fare. Any fare_id in active
108
-
* data not present in the future will be appended to the future fare_attributes file.
109
-
* viii. All fare rules from the future dataset will be included. Any identical fare rules from
110
-
* the active dataset will be discarded. Any fare rules unique to the active dataset will be
111
-
* appended to the future file.
112
-
* ix. All transfers.txt entries with unique stop pairs (from - to) from both the future and
113
-
* active datasets will be included in the merged file. Entries with duplicate stop pairs from
114
-
* the active dataset will be discarded.
115
-
* x. All GTFS+ files should be merged based on how the associated base GTFS file is merged. For
116
-
* example, directions for routes that are not in the future routes.txt file should be appended
117
-
* to the future directions.txt file in the merged feed.
118
70
*/
119
71
publicclassMergeFeedsJobextendsFeedSourceJob {
120
72
@@ -143,31 +95,13 @@ public class MergeFeedsJob extends FeedSourceJob {
0 commit comments