JORE GTFS problems

Currently the GTFS produced from HSL JORE data

• does not combine services (twice as many) and trips (three times as many) causing data processing to consume more resources (in some cases preventing using ready made tools) and hiding information about relations. For example this makes inferring the standard timetable for a route and detecting common (i.e. affecting multiple or even most routes) exceptions in services (which are noteworthy for customers) difficult. Optimally the standard timetable should be fully described in calendar.txt and exceptions in calendar_dates.txt so that, for example, weekday timetable would have a footnote "not valid on 24.12., which operates according to Saturday service"; the weekday services would have an exceptional break and the Saturday services an exceptional addition for that day in calendar_dates (note that this is the current case, but using simplifiers to reduce the amount of duplicate trips and services loses this information).
• does not have timepoint information, which makes route timetables very unwieldy (it would show every stop) or of limited use (showing only the first stop on the route), and impacts routing quality.
• does not have Swedish translations.
• does not have distance travelled in shape.txt (in some cases causing problems in rendering the route onto a map).
• does not have block_id for known combinations (trams 2/3, 7A/7B, ring rail) which prevents routing over the headsign switch stops when transfer margin is used.
• mixes data in the stop description field (address, platform number or crossing street).

In addition to the standard GTFS data, JORE has useful extra information that could be given in extra fields:

• addresses and descriptions to stops in addition to the stop name
• platform numbers for stops in stations (current description field does not give this in machine readable form and in most cases at all)
• detailed information about stop services (most importantly cover for user preferences in rainy weather)
• names/descriptions for exceptions in calendar_dates (which would allow showing messages such as "ei ajeta 1.5. (Vapunpäivä)" in timetables)
• stop radius, which would be useful in rendering for human interpretation (e.g. when to combine stops at lower zoom levels)