This is already technically there....the
This is already technically there....the resource provider just needs to send a delta message with the path
resources.<res_type>.
The client should see this and update the display accordingly.6 Replies
@AdrianP I'm not convinced this is practical for Freeboard, which is obviously where such a feature would be most useful.
Due to the implementation of custom resources in Freeboard where we have a ResourceSet containing an array of anonymous features, the delta would have to include a potentially very large set of features when only 1 of these has actually had an update.
I am certain much thought was put into the decision to use ResourceSets in Freeboard, but it does come with limitations which would not be the case if custom resources were treated the same way as the built-in resources, each with an ID of its own.
Resource Sets were implemented to address a collection of static features to display on a map.
To support dynamic feature updates then the delta message would need to reflect the path to the feature that changed.
It's doable but I wouldn't want to work towards a solution that only addresses only the Freeboard-SK use case.
Delta path would have to be something like
resources.<restype>.<id>.<feature-index>Yes, I did think of something like this, but I don't think it would work. The reason being that the features in a ResourceSet are dynamic and may be different from one request to the next based on request parameters or for example, vessel position at the time of the request.
I think that as long as we are dealing with anonymous features, this would be difficult to resolve.
I don't know where the ResourceSet concept comes from, I am assuming arcgis?... Would it be fundamentally wrong to add an
id parameter to a feature?
It could then be targetted by something like resources.<restype>.<resourceset-id>.<feature-id>Resource Set is fundamentally just a way to represent a geojson feature collection.
Resources in the spec currently are individual features of a particular geometry e.g. each waypoint is a point feature, routes are all linestring, etc
Feature collections allow the different types to coexist in one file.
Yes. Maybe at some stage it would be worth considering altering Freeboard to support custom resources in the same non-resourceset manner as the built-in types.
I think supporting "Feature Collections" needs to be considered from a Signal K perspective not just what might work for Freeboard.