[BikeHelp] Cache POIs in advance

[oliverlockwood]

... so that if you're cycling in an area without data reception, you can still find nearby bike shops if you've done a little bit of planning ahead!

Related to, but not strictly dependent on, #97 and #98.

[mvl22]

Yes, this would be a useful improvement.

I would treat this as three tasks:

1) A class which implements the concept of segmenting a line into areas for data retrieval (which for this example would be POIs, but also we need the same for offline tile pre-downloading), by taking the route line, expanding this into an area around it, and then turning that area into a set of box-based areas that would, if each were downloaded, cover the full area surrounding the line. This should ideally not just be a massive box around the area, as this will be very wasteful - for instance a 100 mile route diagonally from North-East to South-West would lead to far more data than is necessary.

2) Taking the set of box areas and making a request to the POIs API (or tileserver URL - again, if this can be generalised that would be useful) for each, loading each item in the result into a cache (indexed by ID) and implementing a mechanism for updating that every X days.

3) Implementing the above with the POIs API as the parameter.

We can then do step 4 later,

4) Implementing the above (steps 1 and 2) for the tileserver requests.

[oliverlockwood]

@mvl22 I have been giving some thought to how an algorithm would work for task (1).

Assumptions

• any journey can be considered in terms of Waypoints.
• This is an ordered list of lat/long co-ordinates.
• For the purposes of tile / POI prefetching, we can consider the route to be straight lines in between each waypoint.
• We are interested in the area within a certain distance of the route. Let us call this distance _r_. The area of interest for an example simple route is within the dotted lines in the diagram below.

Proposed solution

• Consider the journey as a series of waypoint pairs.
• For each waypoint pair, interpolate sub-waypoints along the straight line as necessary, such that the maximum separation of any two waypoints is _2r_.

• Fetch tiles / POIs within bounding boxes of size 2r centred on each waypoint or sub-waypoint.

Of course, our interpolation separation and box size (both _2r_ in the example above) could be tuned independently to achieve a satisfactory user experience.

I'd welcome input from yourself, @jezhiggins or anyone else before I spend time coding this up. I have a nagging feeling that someone must have solved this problem already... :smiley:

[mvl22]

Yes, that would work fine.

Though have a look at the collisions viewer: https://www.cyclestreets.net/collisions/ which enables you to draw out an area, with an exact boundary sent.

See the second example in the API call for that, which shows the boundary definition: https://www.cyclestreets.net/api/v2/collisions.locations/

That goes through the same point extraction routine, so it would be fairly easy for us to extend the POIs retrieval to include a boundary-based lookup option in the API, which avoid the need for the convert-to-squares routine at the end.

[oliverlockwood]

Interesting, so we already have a way to dynamically draw a boundary. That's cool.

A couple of questions before we proceed on this trajectory, however:

• It doesn't look like dynamic boundaries are currently supported by the POIs API. Where https://api.cyclestreets.net/v2/pois.locations?type=bikeshops&bbox=0.119,52.209,0.120,52.210&limit=20&fields=name,osmTags&key=redacted works fine, https://api.cyclestreets.net/v2/pois.locations?type=bikeshops&boundary=[[0.12665927410126,52.199417341107],[0.12746393680573,52.199759284798],[0.12786090373993,52.199174033417],[0.12721180915833,52.198710429943],[0.12665927410126,52.199417341107]]&limit=20&fields=name,osmTags&key=redacted does not - it returns the following error:

{
    "error": "No location strategy specified."
}

• Your original suggestion was to make this sufficiently generic that it could be used for tiles as well; could dynamic boundaries be used for tile retrieval as well as POI retrieval, or not?

If we are able to use dynamic boundaries instead of bounding boxes, the algorithm could be improved to something like:

• Take waypoint pairs A/B (without a need for interpolation)
• Determine 4 vertices, each a distance _r_ from each waypoint orthogonally to the joining line direction, and a distance _r_ outside each waypoint parallel to the joining line direction.
• Use these 4 vertices to retrieve POIs within the boundary drawn by them (the red box in the picture above).

@mvl22 Looking forward to your thoughts, especially about support in the POI and tileserver APIs for the dynamic boundary definition model.

[mvl22]

It doesn't look like dynamic boundaries are currently supported by the POIs API

As I said, it's not currently supported but it would be fairly easy for us to extend the POIs retrieval to include a boundary-based lookup as it goes through the same extraction library.

Use these 4 vertices to retrieve POIs within the boundary drawn by them (the red box in the picture above).

Bear in mind that will fail if you have an estuary-style route: https://cyclestreets.net/journey/52757057/ or even something only slightly windey.

[oliverlockwood]

It doesn't look like dynamic boundaries are currently supported by the POIs API

As I said, it's not currently supported but it would be fairly easy for us to extend the POIs retrieval to include a boundary-based lookup as it goes through the same extraction library.

Ah, I misread your original message. I'm happy to start coding a solution on the assumption this will get implemented reasonably soon.

Use these 4 vertices to retrieve POIs within the boundary drawn by them (the red box in the picture above).

Bear in mind that will fail if you have an estuary-style route: https://cyclestreets.net/journey/52757057/ or even something only slightly windey.

Doesn't that depend somewhat on the size of _r_? My thinking was that we could tune this for best performance, but I imagine that a value of 10km would be a reasonable starting point and cover most eventualities (including the West Wittering example you gave). Of course, if there is a practical way to infer points along the route other than the simplistic straight line between, we could do better - do you have any suggestions?

[smsm1]

A standard GIS tool is to buffer around a geoobject, so given a line string of the route, you could buffer by a set distance, which gives you the polygon to find all POIs within. This would also cater for the estuary problem.

[oliverlockwood]

@smsm1 belatedly, thanks for the pointer. I'm intending to look into how our usage of OSMdroid might support this, once I've got the relevant upgrades sorted.