Fetch resources using bounding area upon chart load/pan/zoom

[KvotheBloodless]

Currently, it seems that Freeboard only calls /signalk/v2/api/resources/<customType> upon initial load of the chart, and does not specify a bounding box. Custom resources suppliers have no other option than to fetch resources based on the navigation.position path and an arbitrary value for the distance from that location. Since the request is only triggered upon load, custom resource suppliers must also return a fairly large set to hopefully cover any zooming/panning that will occur after load.

Freeboard should instead supply the bounding box parameters (as shown in the spec example) allowing custom resource suppliers to only supply resources relevant to the visible chart area. This request would obvisouly need to occur each time the chart is panned/zoomed also.

[KvotheBloodless]

Note: Further testing shows that note type resources are fetched using a position parameter and a seemingly static distance parameter of 50000. Custom resource calls do not appear to receive either parameters.

[panaaj]

You are correct that notes are the only resource type that are fetched and displayed based on the map position.
Resource sets are currently treated like routes / waypoints where they are loaded an cached to ensure they display after all map zoom and pan operations.

It makes sense that they should be treated in a similar manner to notes, as like notes there may be a large number over a large area.

[panaaj]

This will require both a Freeboard-SK update and a resource provider update (SignalK/signalk-server#1838)

[panaaj]

Freeboard side addressed in upcoming release 2.12.3

[tkurki]

@KvotheBloodless refers to custom resource providers, so in principle the Freeboard fix should fix the issue, now that FB is using the geobounds parameter?

Not saying we should not fix the resources-provider-plugin, just trying to understand everything here.

[panaaj]

The Freeboard-SK fix ensures the query parameters are included in the request.
As it stands though, sending that request to the resources-provider-plugin will return an empty result as the current filtering code is expecting one feature per resource entry and a ResourceSet contains an array of features per entry.

I accept that a ResourceSet is a "custom" resource type and that there may be an argument not to update the resources-provider-plugin code until the format for a resource entry containing a GeoJSON "Feature Collection" is agreed.