TIC 4.0
Reference Point
CONCEPT
Fields | Type | Description | Purpose |
|---|---|---|---|
ID (Concept identifier) | M | referencepoint | GRAMMAR |
Concept name | M | Reference Point | GRAMMAR |
Concept type | M | Activity | GRAMMAR |
Also known as | O | Position reference point; position reference, origin | TIC Description |
Definition | M | The reference point is a characteristic point on a subject (ground slot, bollard, CHE, container, etc) that will act as an overall reference for positioning and specification of the subject. It is mandatory for every subject and is defined according to the type of subject. | TIC Description |
Further Detail | O | The concept “Reference point” is complementary to the observed properties “coordinate” and “location”. Yard related reference points (non-moving objects)
Equipment related reference points (moving objects)
| TIC Description |
Required Information | M | SUBJECT and VALUE | TIC Description |
SUBJECT |
| https://tic40.atlassian.net/l/c/mfS1hwE9 ; #Terminal; #Berth; #Bollard; #Yard; #Gate; #Rail; #Lightpole; #TZ; |
|
POINT OF MEASUREMENT |
| metadata |
|
OBSERVED PROPERTY |
|
| |
Value |
| 2xinteger; 2x real number; m |
|
Related standards | O |
| TIC Description |
Related TIC 4.0 definition | O | https://tic40.atlassian.net/l/c/4Wu5BfzU Logical Coordinate https://tic40.atlassian.net/l/c/gVZ06Cs0 | TIC Description |
Example | M | The reference point of the container stack is located at position 40°12.22' N & 075°00.25' W, which is its most nothern point. | TIC Description |
Example in the context of the grammar | M | The reference point of the container stack is located at position 40°12.22' N & 075°00.25' W, which is its most nothern point. The reference point of an RTG (width= 5m; length=15m at outmost corner wheels) is located in the geometrical centre of the outmost corner wheels, which is half of the width and length of the RTG. {
"che": [
{
"id": "",
"name": "",
"referencepoint": {
"coordinate": [
{
"qualifier": "WGS84",
"value": [
4012.22,
-7500.25
]
}
],
"logical": [
{
"qualifier": "che",
"timestamp": "2021-08-16T08:50:47.475Z",
"units": "meters",
"lenght": "2.5",
"width": "7.5"
}
]
}
}
]
} | TIC Description |
Link to one or more operational processes | M |
| TIC Description |
Search tags | M | #reference #reference_point | Technical |
Version / Date | M | 2021.1 - 30/04/2021 | Technical |
Internal TIC Version | M | 20210422 consistency review 20210816 semantic reference_point = | Technical |
M = Mandatory
O = Optional
subject category | Example |
|---|---|
example large objects / areas / lanes / tracks buildings and parking area |  |
lanes & tracks | |
example for small objects |
|
example for equipment with three or more wheels RTG | Side view Top view Bird view
|
trailer and tractor |
|
mobile harbor crane | to be completed |
container | Top view Bird view |
Created by | Edited by | Review / Approve | Published |
@RBS EMEA 2020-12-01 |
|
|
|
| @Francisco Blanquer Jaraiz 2021-04-22 |
|
|
| @Francisco Blanquer Jaraiz 2021-08-16 |
|
|
Comments
Dear @TMEIC TIC4.0 Team
Let's try to resolve or dig into your comments.
Location is just a magnitude that answers the question “where?”. But there are many aspects in the “Where?”, that could be absolute to the planet Earth, could be in reference to the terminal, or could be relative to the subject itself (the CHE, or a component of the CHE). For this reason, we have location|technical/coordenates/logical. I think we never define location as an absolute coordinate, this is only in case you use location|coordenates. But also you can use location|logical to give a human name to “Where”, or location|technical to give a position in a machine (Where in the machine).
In the case you have a machine with spreader moving across the terminal: che|@|spreader|@|location|coordinates will change all the time, che|@|spreader|@|location|logical will change every time the reference point change from one logical zone (virtual) to another. But che|@|spreader|@|location|technical will never change as it refers to the position of the spreader in the machine. In conclusión not always you need to have an absolute position. Another typical case is the relative position in the alignment of to CHE (truck and RTGs), you need the location of both but relative and not absolute.
I think you are mixing reference points. All subjects have a reference point including the terminals. And another thing is the location|coordinate that is the position of the reference point of the subject versus something (a reference) defined by the “qualifier” of the location|logical (WGS84 or the Yard or xxxx).
The data model doesn't include all possible ways to use TIC (you can make many combinations) but the default ones. You can apply yaw definition to any subject if you need it. Now the data model is 20k lines, if we try to represent any possible combination that makes sense probably would be longer than 100k lines…
I agree, “location” definition is missing on how to use yaw for a subject type cargo, (box, container) and also could be very useful to define the front and rear considering the door position.
@RBS EMEA we should include this in a review of this definition.
I’ve been looking at this section for a long time and I still can’t get it to make sense to me. I see several things that appear to me as contradictions. In hopes that someone can help identify my misunderstandings, I am listing the things that don’t make sense to me:
The
"referencepoint"definition is “a characteristic point on a subject … that will act as an overall reference for positioning … the subject.” And in the example at the end, we are shown the expected location of reference points on various objects (e.g. center of RTG crane, at ground level).My assumption is that when a CHE’s ‘location’ property provides coordinates, those coordinates are for that referencepoint on the subject (i.e. the center of the crane).
It makes sense that you could use an absolute (WGS84) location as a reference point for a yard, stack, etc. (because there would not need to be a changing ‘location’ concept), but I don’t see how an absolute location can be used as the reference point for a moving object like an RTG – that’s what the ‘location’ concept is for – if you have both absolute referencepoint and absolute location concepts for a subject (as would seem to be the case for CHE), they would both have to change as the subject moves, right?
The example JSON for RTG referencepoint has two locations – an absolute (WGS84) coordinate (
[4012.22, -7500.25]), and a ‘logical’ one ("lenght": "2.5", "width": "7.5"). Ignoring that the definition for logical locations doesn’t mention x,y coordinates (relative or otherwise); specifying the RTG referencepoint as [2.5,7.5] implies to me a distance of 2.5m to the right and 7.5m above the presumed origin of (i.e. the center of) the RTG. So what is being indicated? Is it that the RTG.location.coordinate is specified for a point on the upper-right of the crane? Maybe that’s where a GPS receiver that provides absolute location is located?And since there are two referencepoints for the RTG, how would they be related to each other and to the RTG.location property?
I am assuming the reason we would want to locate sub-subjects (e.g. spreader on RTG) is so that we can accurately draw/plot the objects (i.e. show all the CHE moving around a map). If that's the case, we need bearing/azimuth/yaw of sub-subjects, which isn’t defined anywhere that I could find – at least not in TIC40 DATA Model 2023.0093 2023.009.json. I did find CHE.drive.yaw, but the definition seems to indicate that it only applies to a “machine” that is “Working” – not a container and not a crane that isn’t moving (or is parked).
And finally, I would think that it would be useful to be able to locate and draw containers on a map (I am working on a project that would attempt to do this using TIC40). As I mentioned, I think we would need a bearing/azimuth/yaw as part of the definition for a container. And it would be really useful to define a default orientation that would allow us to infer door location from container bearing. But there doesn’t seem to be a container object? (The definition seems to be empty)
The closest I found was the cargo subject, but that is only fully defined(?) in TOS, not in CHE. And it doesn’t seem to have a “yaw” concept.
Would there be a TIC4.0 compatible way to query and report container location (and orientation) outside of a TOS message?