Transit layer is loaded but timezone is unknown (r5r)

[mvpsaraiva]

When a network.dat is build without GTFS data (for bike routing analysis, for example), R5 throws an error:

ERROR c.c.r5.transit.TransportNetwork - TransportNetwork transit layer is loaded but timezone is unknown; API request times will be interpreted as GMT.

This error is thrown in this line. Perhaps LOG.warn is more appropriate than LOG.error in this case, like in line 331. This would clean r5r's users' console of error messages that don't actually interrupt processing (r5r issue 170).

[ansoncfit]

At first glance, the timezone is used in PointToPoint routing but not FastRaptorWorker.

We tend to focus more on the latter. While we no longer spend much time on support for the PoinToPoint routing, we are open to changes that make it more useful to the community. For future coordination generally, it would be helpful to identify proposed changes that have no effect on FastRaptorWorker routing.

All that said, we would eventually like to support use without baseline GTFS (see #607), and changes in that direction would be welcome.

[abyrd]

TransitLayer#timeZone is protected, and I believe it's only accessed through TransportNetwork.getTimeZone(). In turn that is only used by PointToPointRouterServer and PointToPointQuery. ProfileRequest.zoneId also defaults to UTC, but it too is only used by PointToPointRouterServer and PointToPointQuery, as well as a few other methods on ProfileRequest such as setTime and getFromTimeDate which are only used in point-to-point queries.

In our one-to-many analysis work (FastRaptorWorker) we simply don't work with time zones. All feeds and time parameters are assumed to be in the same zone.

But it looks like point to point searches will indeed interpret times as UTC when no time zone is supplied in the GTFS. This was probably done simply to mimic behavior in the OpenTripPlanner API. I'm not sure how bad the effects are - it's possible both requests and times in the GTFS are being interpreted as UTC so there is no noticeable effect. In any case I have no problem demoting this to a warning instead of an error.

It is likely that we'll want to remove much of this code in the future because we do not use the point to point code and it's unsupported, and behaves rather differently than our usual code paths. Our intent is to be able to read off detailed paths similar to those produced by point-to-point code from arbitrary destinations in a one-to-many tree.