Allow Extended GTFS Route Type values

[naxxfish]

Feature request

GTFS feeds which contain route_type values referenced from Extended GTFS Route Types , e.g. 700 for a generic bus service, generate a UnexpectedEnumValueNotice.

Is your feature request related to a problem? Please describe. Sometimes GTFS feeds contain extended route_types, which are entirely valid, but are being flagged as an unexpected enum value by the validator. The extended route types should be considered valid, and the hierarchy/granularity of definition is useful to clients.

Proposed solution Add values listed in Extended GTFS Route Types to the list of expected enum values for route_type. This could possibly be enabled optionally via a flag.

Describe alternatives you've considered The client could ignore these issues conditionally, if the fieldValue is one of the extended set.

Additional context Many agencies use the fields and flagging them as a warning is rather inconvenient as it masks other much more important warnings!

[isabelle-dr]

Hi @naxxfish, thanks for opening this issue.

That's a great point! In order to keep the validator up to date with the canonical set of rules defined in the official specification, could you open an issue or a PR there to propose allowing the extended route types in the specification?

Then when it's passed, we'll make the changes here in the validator.

[naxxfish]

Unfortunately, this doesn't seem as easy as it might appear https://github.com/google/transit/pull/279 . Adding these extended route types to GTFS has been discussed as far back as in 2008. Whilst Google made a web page about it, and producers and consumers started using the codes, it never made it into the specification officially.

There are some issues around what the valid codes should be, and what are useful in GTFS.

[isabelle-dr]

Hello,

Indeed, not easy as it might appear! Thanks for opening this discussion at google/transit. It seems like the implementation of the GTFS-ModesAndNetworks proposal could help. We'll keep this warning as is in the validator to avoid discrepancies with the spec. The next release of the validator will allow users to have a custom set of rules for specific needs, you'll be able to have a custom rule for the routes types. Hope this will help!

If the conversation on google/transit doesn't move further, I'll assign the wontfix label for this one, thanks for your contribution to this repo!

Cheers -

[aababilov]

Although HVT (hierarchical vehicle type) won't be a part of the standard GTFS, we may still have support for it because HVT is really widely used. Custom validation rules may decide to convert HVT to the standard route types this way:

https://github.com/MobilityData/gtfs-validator/pull/1039

[skinkie]

Any update?

[isabelle-dr]

No update on allowing customization as a feature of this validator.