Update to latest GTFS reference

[hypervtechnics]

Reference here: https://developers.google.com/transit/gtfs/reference#field_definitions

I started working on this. Will open PR when ready/pushable.

Changes to be made

• Everywhere
  • Update xml documentation from reference
  • Check filename attributes
  • Enums fixed numeric values
• stops.txt
  • Location type
  • Wheelchair boarding
  • Parent station
• routes.txt
  • Route sort order
• trips.txt
  • Bikes allowed
• routes.txt
  • Time point type nullable (?)
• fare_attributes.txt
  • Transfers as enum (?)
  • Duration a uintn (?)
  • Agency id
  • Price as double (?)
• frequencies.txt
  • Headway secs as uint
  • Start and end time as DateTime
  • Exact times as enum
• transfers.txt
  • Minimum transfer type as uint?
• feed_info.txt
  • Contact email and url
  • Implement parsing (feed_info.txt does not get parsed #56)
• levels.txt and pathways.txt
  • Add to model?

REMEMBER: update read/write logic, hash codes, equal operators

Entities/Files to be checked

• agency.txt
• stops.txt
• routes.txt
• trips.txt
• stop_times.txt
• calendar.txt
• calendar_dates.txt
• fare_attributes.txt
• fare_rules.txt
• shapes.txt
• frequencies.txt
• transfers.txt
• pathways.txt
• levels.txt
• feed_info.txt
• Are the file requirements respected (if possible depending on strict mode)?

[hypervtechnics]

@xivk I looked through the current reference. Any things to add/discuss from the changes to be made? I found some values to be strings which are ints as per GTFS reference. Is there a specific reason for this?

Otherwise I will start applying the changes during the next weeks.

[xivk]

There was a huge pull request that I think fixes most of this. I will be grooming this code a bit before releasing a package but I have high hopes for it.

[hypervtechnics]

Can you update the above states of what got implemented fully/partially/not when looking over the code?

[xivk]

Ok will do that later when I get a chance to look at it more closely. Maybe @peetjvv can chip in here.

[peetjvv]

@hypervtechnics

Seems I can't edit your list directly, so I will list the items to check off here.
TODO items on your list which should be implemented/resolved in #62 are:

Everywhere:

• Enums fixed numeric values

stops.txt:

• Location type (including all new locations that are part of the pathways expansion)
• Parent station

fare_attributes.txt:

• agency_id (I have no idea why a fare_attribute has an agency_id in GTFS since it is already linked to an agency through the fare_attribute->fare_rule->route->agency connection)

levels.txt and pathways.txt:

• the current implementation should be fully implemented in the entities and the SQLite db
• in case you're interested, I know there are more changes to these files (and new supporting files) are being planned: https://docs.google.com/document/d/1qJOTe4m_a4dcJnvXYt4smYj4QQ1ejZ8CvLBYzDM5IyM/edit#heading=h.dpooq7li7zcq

Items I'm unsure about:

Everywhere:

• Check filename attributes

stops.txt:

• Wheelchair boarding

routes.txt:

• route sort order (all outputted GTFS feeds will have all the entities sorted by id. not sure if that is what you were referring to)

[hypervtechnics]

Check filename attributes

I mean e.g. those:

GTFS/src/GTFS/Entities/Agency.cs

Line 30 in 033877c

[FileName("agency")]

They seem to be unused but some of the filenames are not the filenames mentioned in the reference. Maybe the whole library can be adapted to an attribute-based approach which would be more flexible regarding spec updates. Only as an idea tho.

Wheelchair boarding

In the spec the enums are slightly different depending on the stop type. Just noted to inspect it :)

route sort order

I mean this. It is an additional field of route.

[peetjvv]

I'm not sure what the filename attributes are used for really. Never touched them. Agreed, it would be ideal to use the field and file attributes in the output.

I've never really used wheelchair boarding myself, so I didn't pick up on the inconsistencies with the enums.

I didn't know about the new route_sort_order field either. Never really needed to support that field.