Extending the Track and Trace OpenAPI to include "in transit" events

[RowlandShaw]

I'm not sure if this completely sits in the scope of the Track and Trace Open API standard, but I have been considering a use case where a consignee is running a "just in time" approach to fulfilling parts for a production line.

For transit legs, where the container is on a vessel the exact location is fairly irrelevant (although it could be collected via AIS, or otherwise); however once the container is on the final road leg of its journey then congestion and other very transient issues can come into play. Some consignees I've worked with have the desire to understand exactly where their container is on the road - the idea being that as they understand how the traffic network local to their facility generally works, they can factor that in to understand when the truck is going to roll up at the gate.

So far, I've seen that liners, their agencies, or intermodal operators will implement this, the transport event only seems to allow for Arrive/Depart transport events, and then qualified with whether it is Planned/Estimated/Actual via the eventClassifierCode.

It would feel wrong to report a bunch of ARRI events for a non-waypoint, especially if they are on a road in a non-urban area. For example, if the truck was at 53.4875N, 1.50138W at timestamp {x}, we wouldn't want to report arrival in any of the nearby towns, but the consignee would love to be able to say "Ah, that's on the A616, and we can plug that into our heuristics to calculate our estimated time of arrival and get the loading dock ready in plenty of time".

I'd suggest a operationsEventTypeCode to indicate "progress", given the eventLocation covers off the latitude/longitude aspect, but would welcome other approaches

[rlilov]

Hi,
This request is somehow related to the issue I posted #169, inquiring about the options of inland transport providers to post waypoint data using POST.

I also see in the specs (but on equipment level only?) https://github.com/dcsaorg/DCSA-Information-Model/blob/master/datamodel/referencedata.d/equipmenteventtypecodes.csv, ability to report
WAYP | Way Point Crossed event. This seems to satisfy your use case and avoids fake ARRI event.
I am not sure why it is on Equipment level only, unless I am misunderstanding something.
HTH

[RowlandShaw]

For the scenario I have, I have a consignee that wants to be able to see where their assets are on the road.

Now, whilst we could build a web portal for the shipments we're related to, that doesn't help them for their other logistics providers, and they're asking that we provide an API interface so that they can query our systems, and cross reference to their own.

For example, we could have a view that shows something like (please excuse the fictional, but representative, data)

There's no real definition of waypoints here in the traditional sense - both vehicles are between junctions 38 and 37 of the A14 - so whilst they may have passed J37 or J38 (depending on direction), we can't give a true time for that - but we could give the latitude/longitude, as reported from telematics in the cab.

This feels like the thing that should be standardised, and to me, it feels like a natural extension to track and trace with some kind of "in transit" event - Especially with the rise of smart containers with vendors such as Traxens.

I see what you're saying about using waypoint crossed events as a possible interpretation - although the wording implies more of a geofencing scenario.

Maybe the solution is to change the phrasing to cover off the use case to allow for "in transit"; and implementors can work out whether to return all events in response to the poll request, or just the most recent - obviously, in the scenario of an event subscription, the sender would send all.

[KPS010289]

Hello,

We have considered in the past the addition of so called IN TRANSIT events and rightfully these are best addressed when you have a smart container providing data every few seconds / minutes. This per DCSA and larger SME group with the members sits in the IoT visibility domain, which is the IoT commercial events beta 1.0 stage but potentially can include a transit event specially useful if you wanna know exact location on land. The same can’t be said for T&T standard, as the enhancements planned in the IoT space will be addressed only in IOT commercial standard and thus covering use cases relevant to providers like traxens or nexxiot or hoopo for that matter. As for the current roadmap this discussion is not part of 2024 items. But we do have this in the backlog to work on IoT Comm events 1.0 Final to potentially include depending upon feedback from members. Hope this helps