Repository navigation
Add calculated CO2 to consignment #49
Description
Activity
Full support for the addition, wouldn't it be possible to have this value in some sort of lifcycle instead of 2 separate fields?
I am currently working on a more detailed proposal. The direction will likely be to create new action types (which have lifecycles) for this. E.g.
EmitPollutantthat can be part of trips, moves, consignments, etc.)Within Simacan we have thought about this use case a bit in the past week and come to the following proposal:
Add a new action
EmitPollutantthat contains a value-with-unit for the amount of CO2 (or any other pollutant) that has been emitted in the scope of that entity, together with optional references to trips, moves and consignments. We initially consideredEmitbut think that is not clear enough.The advantages of this approach:
- By making it an action instead of a field you get lifecycles 'for free'.
- It gives freedom to be precise (track the CO2 emissions on each move) and to be general (track the C02 of an entire trip).
- It allows you to have multiple calculations for a single consignment, for example because it is part of multiple trips.
- It can be used on different entities without any modifications to those entities.
We feel that emissions, and consumption are pretty similar, so also propose another action
ConsumeFuelthat can be used to track how much fuel has been consumed in a trip or move.Curious to know what you think about this proposal.
Actionjust doesn't feel right as far as definition of the word.Eventwould fit better already in my opinion but I believe there should maybe be a new value.My argument for
Eventis that it's pretty much already possible through theSensorandUpdateSensorEventcombination to have this data logged.My argument for Event is that it's pretty much already possible through the Sensor and UpdateSensorEvent combination to have this data logged.
Yes that is true, but we cannot attach events to entities, so it is not possible to send a trip with emission data if they are events (currently). I agree with the sentiment that event events feel more appropriate, but they would make sending messages actually more awkward.
edit we could of course make it possible to attach events to entities, but I am not sure whether that will actually simplify things.
Discussed with @woutvandenheuvel and @mennolambooij and we agree that events make more sense than actions. Though it would also mean we would need to add an
eventsfield to every entity. Any thoughts @thomaskolmans?Did you have a chance to think about this some more @thomaskolmans? I am wondering how you see the solution work with events if you want to provide it in one message.
Yes I have given this a bit of thought. However I don't like the
eventson every Entity. That will make things really odd. Maybe we have to introduce a new entity? Or a sub-entity that has some sort of lifecycle integrated?A ValueWithUnit - and lifecycle?
It can be self-contained as it won't have a lot of lifeCycle changes or statusses (an assumption at this point in time)
So, if I understand your proposal correct, that would something like this in pseudo JSON:
consignment: { id: <uuid>, goods: [ .. ] emission: [ { lifecycle: projected value: 10 unit: co2e }, { lifecycle: realized value: 12 unit: co2e } ] }One the side I think it fits better than actions and is easier to integrate than events. On the other hand it would mean more changes (this fields needs to be on consignment, trip, move + we also would need a consumption field on consignment, trip and move) and it is also a little different with how we have been working with lifecycles up until now. I am not sure what's better.
Maybe we need something next to events and actions that can be added to entities. Maybe that is also what you meant with?
Action just doesn't feel right as far as definition of the word. Event would fit better already in my opinion but I believe there should maybe be a new value.
So I was playing with both scenario's in my head. I'm actually for either solution. A new Entity would take more time to implement and understand (it makes the model more "complex") but can be argued for as this will give the ability for a lot of future additions.
However, the above implementation is easy and would do it's job too. Would make an overview of what happened very clear and concise.
So in conclusion, both ideas came to my mind as "better then Events or Actions" but I'm not sure which one is the best. I'll think about it and I would like to hear some other opinions and arguments if there are any.
Thanks for thinking along Thomas. We are in contact with BigMile about this subject, so I am sure they have an opinion as well. I will also take your suggestions and discuss them internally and post back our views here.
but can be argued for as this will give the ability for a lot of future additions.
I think the actions/events or something new are better in this regard and I am personally leaning more towards this type of solution. It might be a bit more involved now, but I think adding fields with lifecycles are less future proof for similar additions (like the consumption already discussed in this topic).
I had a discussion with BigMile yesterday about this feature. They already have a non-OTM5 api and want to provide this same functionality in OTM5 soon. I showed the discussion we have had until now and will discuss it internally and provide feedback here as well. From what I understood they are leaning towards the emission and consumption value-with-unit-lifecycle fields. IMO it is a little less generic, but also simpler.
Unless we agree on a good way to include 'event' like data to entities themselves I think this is the current best proposal.
Note, within Simacan we have included a
contextfield on all entities that can contain events that are relevant to why an entity is the way it is. This is used for example in the ETA calculations that we provide (the events show LocationEvents to indicate on what data we based the eta calculations. I am not sure whether context (that are events) is the best possible solution, but I find that it works rather well. Any thoughts @thomaskolmans? Would you be open for an addition like this (with modifications if needed)?Thanks @bmeesters and @thomaskolmans for the elaborate discussion on this topic, reading it made me change my opinion multiple times. It would be great if it is possible to track emissions in OTM for various entities. The proposed solution with the
emissionfield could be a good fit for the BigMile Emission API for mapping the planned CO2 emissions. However, I see some challenges:The
emissionfield lacks the possibility to store detailed information about the emissions. E.g. it can be important to know with which framework the emissions were calculated. We can extend the field with other attributes, but this can get very big. At which point is it no longer desirable to store this directly in the entity instead of an event? Providingcontextto an Event can be helpful to provide information about which framework was used or how the planned emissions were calculated. This is also relevant for allocating emissions for different consignments or goods.From an ease-of-use perspective, the
emissionfield is great to easily exchange emission information, but I wonder if we still need a way to do it with events, which feels more in line with the spec.Let me know your thoughts on this.
Martijn
Thanks @MGemmink for chiming in. The more I think about it the more I would something more generic than a new field (with potential extra attributes). So I would be in favor of making it an
Eventwith the proper information (which could include the used framework). Then the problem of how to add events to entities still remain. Adding events to entities initially feels a bit weird. However I think this is mostly due to framing.For example, we could add a field
historyto each entity that could contain all the relevant events that lead to the current state of the entity in question. Something like this would already be beneficial for Simacan, since we calculate ETAs and if we could add the location updates that have influenced that ETA that would be a welcome addition. Now, I thinkhistorymight not be great, because that would imply that everything has finished, which would not be the case for projected CO2 emissions. Which is why I thinnk adding a fieldcontextthat could contain the events would be better and clearer than naming the fieldevents. Any thoughts?Thanks @bmeesters for your reply. I think a
contextfield could indeed be helpful to know how a certain value came to be, just as for ETAs, you want to know how emissions are calculated and what was taken into consideration. I have a question though, how do we know whicheventsto show in thecontextfield? Maybecontextneeds to be bigger than merely a list ofeventsin which we can capture the additional information. An example:{ ... # the entity details emissions: [{ value: 100.23, unit: "co2e", lifecycle: "planned" }, { value: 106.80, unit: "co2e", lifecycle: "realized" }], context : { emissions: { # the context for the `emissions` field in the entity (or in the external attributes) framework: "GLEC", # attributes for the context. ... events: [{ ... # the events that were used to calculate the emissions }] } } }What do you think?
In my opinion, we should either go with the fields or with the context, not both. So my proposal is one of:
- Using fields:
{ entityType: consignment goods: [..] // omitted for brevity emissions: [{ value: 100.23, unit: "co2e", lifecycle: "planned" }, { value: 106.80, unit: "co2e", lifecycle: "realized" }], }advantage: simple to use/understand
downside: non-extensible solution, we would to add a sea of parameters for similar use cases- Using events (in context)
{ entityType: consignment goods: [..] // omitted for brevity contextEvents: { { eventType: emissionEvent framework: GLEC, lifecycle: projected emission: { value: 106.80, unit: "co2e" } }, { eventType: emissionEvent framework: GLEC, lifecycle: realized emission: { value: 106.80, unit: "co2e" } }, // potentially other events, such as consumed fuel, etas calculated, etc. } }advantage: extensible, in line with OTM
downside: harder to use/understandMy current preference goes to the second. Since it is more extensible for other type of 'context' without any changes to the base format. I think it is also more in line with the philosophy of OTM. That said, it might be a bit harder to use, since you would need to extract the emission events out of the list of events before you can use them.
@thomaskolmans, @MGemmink, @ptv-jcl any preferences for either?
Events seem more logical flow for adding realization data then fields to me.
How else would you share events in combination with the target entities they are about? We can add fields to entities, but I doubt that will make the standard simpler in the long run. But I suppose given your answer you would be in favor of option 1? Including one for
emissionsand one forfuel consumption?IMO if we can somehow link events and entities that would make a lot of use cases possible without any further changes, which is why I am pushing for it.
No, I'm in favor of option 2.
Reacted by bmeestersAh I guess I misunderstood
In favor for option 2
Reacted by bmeestersI'm also in favor of option 2.
Alright, thanks everyone for all the input. We'll go with option 2 then.
This is now part of OTM5.4
Type of request
Is your feature request related to a problem?
CO2 calculation on trips or/and consigments are more often made by external systems and platforms. Calculated value per consigment will be returned.
Describe the solution you'd like
Add to consignment:
Describe alternatives you've considered
Did you try to solve it with the current specification? If so, how? Please be as clear and concise as possible.
Additional context
Add any other context or screenshots about the feature request here.