Geospatial tiling of all of hafas

[pietercolpaert]

Nice to have idea:

Now you can configure the server on a specific bbox. What if we’d extend the URI template to this:

https://example.org/{z}/{x}/{y}/{connections|stops}/{?t}

With z the zoom level, x the longitude of the tile and y the latitude? You can of course disable zoom levels that would be too difficult to handle on the server-side.

You can describe this interface with hypermedia in the same way as the Routable Tiles spec: https://openplanner.team/specs/2018-11-routable-tiles.html

Open questions: how to handle this in planner.js.org? What extra metadata do we need to know what viewport to download for getting a complete answer to a route planning question? (These questions are currently being tackled by my team)

[derhuerst]

Now you can configure the server on a specific bbox. What if we’d extend the URI template to this: https://example.org/{z}/{x}/{y}/{connections|stops}/{?t}

how to handle this in planner.js.org?

This would add a whole new layer of complexity to planner.js. Up to you, I guess it comes down to "smart client, dumb servers" vs "less smart client, less dumb servers".

[pietercolpaert]

Now you can configure the server on a specific bbox. What if we’d extend the URI template to this: https://example.org/{z}/{x}/{y}/{connections|stops}/{?t}
how to handle this in planner.js.org?

This would add a whole new layer of complexity to planner.js. Up to you, I guess it comes down to "smart client, dumb servers" vs "less smart client, less dumb servers".

The idea of Planner.js was also to do source selection across the borders of a single public transit system. We are currently prototyping different approaches, and the tiling approach is one possibility.

[derhuerst]

So usually tile borders would usually also be transit system borders, but they don't have to be? That could work. 👍

[pietercolpaert]

Indeed!

[derhuerst]

#3 implemented fetching stops by bounding box.