Sadless74 / googletransitdatafeed

Automatically exported from code.google.com/p/googletransitdatafeed
0 stars 0 forks source link

Feed Merger Falsely Reports Overlapping Schedules #183

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The "overlap" is in the calendar.txt files but is not wrong.  We have some 
services that run summer (6/21/09 => 9/5/09) then change to fall schedule 
(9/6/09 => 12/26/09).  We also run college shuttles - colleges don't run 
in summer and begin in late August so there is no summer schedule but the 
fall begins on 8/30/09.  If your program is tripped up by an absolute 
earliest start date in the second file happening before the absolute 
latest end date in the first file, notwithstanding they are different 
service types, it is not sufficiently sophisticated.  The calendar by 
service types looks as follows.  The merger has to look at each service 
type separately.

Fixed route services -
wkd,1,1,1,1,1,0,0,20090621,20090905 becomes 
wkd,1,1,1,1,1,0,0,20090906,20091226 - they do not overlap
sat,0,0,0,0,0,1,0,20090621,20090905 becomes 
sat,0,0,0,0,0,1,0,20090906,20091226
sun,0,0,0,0,0,0,1,20090621,20090905 becomes 
sun,0,0,0,0,0,0,1,20090906,20091226

For the college services
<<no summer version>> becomes 6wk,1,1,1,1,1,0,0,20090830,20091216 - 
nothing to overlap with
<<no summer version>> becomes 7wk,1,1,1,1,1,0,0,20090830,20091216
<<no summer version>> becomes 9wk,1,1,1,1,1,0,0,20090908,20091217
<<no summer version>> becomes fri,0,0,0,0,1,0,0,20090906,20091216
<<no summer version>> becomes 6sa,0,0,0,0,0,1,0,20090830,20091216
<<no summer version>> becomes 7sa,0,0,0,0,0,1,0,20090830,20091216
<<no summer version>> becomes 6su,0,0,0,0,0,0,1,20090830,20091216
<<no summer version>> becomes 7su,0,0,0,0,0,0,1,20090830,20091216

What steps will reproduce the problem?
1. Merge two calendars with an ending date later in the first file than a 
beginning date in the second file, even if it's a different service type.

What is the expected output?
Each service type should sew together at the correct date:
6wk,1,1,1,1,1,0,0,20090531,20090829 => 6wk,1,1,1,1,1,0,0,20090830,20091216
wkd,1,1,1,1,1,0,0,20090621,20090905 => wkd,1,1,1,1,1,0,0,20090906,20091226

What do you see instead?  Error "calendars not disjoint" and merge fails.

What version of the product are you using? On what operating system?
transitfeed-windows-binary-1.2.1.zip XP Pro SP3

Calendars to merge attached

Original issue reported on code.google.com by aardkl...@gmail.com on 28 Aug 2009 at 6:57

Attachments:

GoogleCodeExporter commented 9 years ago
As a work-around use the source distribution and edit merge.py to set 
self.require_disjoint_calendars = False.

You are correct that the merge.py uses the absolute start date and absolute 
latest end date to decide if schedules overlap. The intention is to prevent 
someone 
accidentally creating a feed that has duplicated service during the overlap 
period. 
An algorithm that matches service types in source feeds and ignores unmatched 
service 
types sounds unreliable. Perhaps an overlap should be allowed as long as the 
maximum 
number of trips per day in the merged feed is no more than the maximum number 
of 
trips per day in the original feeds.

A flag that lets people unconditionally merge feeds when they know what they 
are 
doing could also be useful.

Original comment by tom.brow...@gmail.com on 2 Sep 2009 at 9:48

GoogleCodeExporter commented 9 years ago

Original comment by tom.brow...@gmail.com on 16 Nov 2009 at 4:54