Trip Intepretation and Parsing

[pankalog]

No description provided.

[pankalog]

Using AssetStateDuration (#1134), I wrote a function that when given an AttributePredicate and AttributeRef, is able to understand any state change described by the Predicate and return an attribute of type AssetStateDuration, that contains the start and end times of the asset state that just ended.

Since the Attribute is updated once, specifically at the end of any trip, we can then use getDatapoints() to retrieve each trip, and we be sure that there is only one Datapoint that we receive for each trip done by the vehicle.

Since the function can be used for any attribute and the AttributePredicate is easily editable, we can easily create a new Attribute for any asset state the user would like to keep for their vehicle. For example, Teltonika devices send a parameter called "over speed" that changes states when the user goes over the speed limit set on the device.

This opens up a lot of possibilities, even a new MetaItem that can take in an AssetPredicate as input and can thus create that attribute completely dynamically and through the UI. The UI elements are already there from the rules UI, maybe it would be an interesting addition.

The current functionality I'm describing can be found in the linked branch.

@pierrekil and @richturner, It would be great if we could talk about this, and so that I can show you the new functionality!

[pankalog]

To Do:

• Implement (or at least demo) frontend functionality surrounding usage of AssetStateDuration with STORE_DATA_POINTS
• Grab asset Data Points based on the timestamps of AssetStateDuration
• Use DataPoints of the TripSession attribute to show the trips that occurred
• Find a way to get the addresses of the start and end location datapoints, get average speed, and generate some data for every trip with the available data. Look at URS/Project Plan for more ideas.

[pankalog]

For the above points, I am creating a new LitElement within or-map-card-asset with a list of trip dates and their durations. Due to limited genuine GPS data, it's difficult to check the feature described in point 3, but I am going to use the speeds to figure out the maximum speed that was detected.

For point 4, to limit development time and not introduce openrouteservice as outlined in #1, I implemented reverse geocoding to be able to retrieve the approximate location of a coordinate, to then display to the user.