RouteMatcher routespec format

[abyrd]

As noted in a comment in RouteMatcher:

@param routeSpecList A comma-separated list of route spec, each of the format
[agencyId][routeName][routeId] Please note that this format is not really intuitive
as it does not follow the OBA-gtfslib AgencyAndId standard ('agencyID_routeId'). This
was kept for backward-compatibility purposes. If the original routeName contains some
"" each must be replaced by a space. If the agency or route ID contains a "" they
must be escaped using a backslash.

We should not accept possibly non-unique route name strings when we have IDs. We should break backward compatibility. This is also the only place we are still using underscores as scope separators. We should just use feed:routeId.

[abyrd]

This really needs to be fixed for the v2 API. We should use a standard feed-scoped identifier scheme across the whole OTP API. The most widely used format is feedId:entityId, but we still need a a standard way of specifying multiple entities in a list, and some people are of the opinion that feed scopes should only be necessary when more than one feed is loaded (which is quite reasonable as a way to make the API friendlier, but may allow ambiguity and multiple code paths to creep in).

[t2gran]

At Entur we use multiple feeds, but all entities have global unique ids. Also OTP is not the only component in the ecosystem, so to make it work we actually have to translate OTP request/responses (adding/removing feed-id prefix). Getting ridd of the feed-id would be very nice.

[t2gran]

I think there is several ways we can do this (optional feed-id) one way is:

1. All entities should have an id with type Id (A serializable interface ).
2. All import modules and realtime updaters should use a pluggable IdFactory.
3. The default should be backward compatible and use the DefaultFeedIdFactory.
4. The APIs should not know what strategy is used.

[sdjacobs]

Having feed-scoped IDs makes sense to me because GTFS has no guarantee against ID collision across feeds, ie you could have multiple feeds loaded that all have a "route A". If we allow optional feedIds, how should the API handle collisions? 404?

[t2gran]

I am sorry, I did not mean to remove the feed id, just to be able to configure different strategies - so those who need it can use the default (feed scoped ids) and those who do not can implement another strategy.

Collisions will not happen at the API level, but rater at import - realtime update level. So if you choose to not use the default behavior (feed id scoped IDs), then you are responsible for making sure that data passed into OTP have unique IDs.

[abyrd]

@sdjacobs I don't think we would allow collisions - every entity would still need to have a unique ID, and would be looked up by that ID. But generation of IDs and comparison / equality of IDs would be abstracted. It would be possible to swap in code that did or did not expect feed scopes and use them when determining the equality of two ID objects.

From a type safety point of view it also makes sense to have an entity ID class instead of just using String, and would not necessarily be perceptibly less efficient.

However I am not sure we need full pluggable generalization of the entity ID concept, since there are only two known strategies to implement and one of them is essentially a subset of the other. It might be sufficient to just have optional, conditional code paths that supply different behavior (API does not look for feed scope in supplied ID; entity ID's equals method does not look at the scope field).

But having two different implementations of entity ID and entity ID generator (one with feed scope, one without) is probably no less efficient and makes code easier to read if done right.

[t2gran]

When we get to this I can provide a PR for the general ID stuff - I have done this before to test performance (NeTEx have absurd long ids, so it needs to be optimized for speed and memory consumption).