Osi landmarks

[ecazaubon]

What represents exactly Direction Scope, and what is its usage ? Also for the view_normal is it supposed to represent the normal of the traffic sign ? If so, what its purpose provided than orientation of the traffic sign is specified ?
For the RoadMarking, to represent a yield line, you would use the stop line dashed or stop line triangles so is there any case where one of those represent something else than a yield ?
Also a stop line with an associated STOP marking on the ground would be represented as to separated road markings or one "Stop line" marking ?
(I do not know if this one is already fixed but there is a typo here TPYE instead of TYPE)

[pmai]

The typo is fixed in PR #124 to be merged shortly.

[carsten-kuebler]

@ecazaubon the direction scope is used for traffic signs like "no parking" with an additional scope information (additional arrow). This type of signs indicates not "_begin" or "_end". "_begin" or "_end" depends on your driving direction, the position of the sign (left road side or right). For a one-way road both sides of a lane are important.
The view_normal of a traffic sign represents the normal of the traffic sign's image. If we use the orientation to define view normal, the view normal has to be defined (e.g. -x-axis of the orientation is the view normal of the traffic sign's image). If a traffic sign's orientation defines the view normal of a traffic sign than the road marking's orientation should define the scope of the road marking (e.g. y-axis of the road marking's orientation defines the relevant driving direction).
@ecazaubon and @CarloVanDriestenBMW would you prefer to use BaseStationary.orientation and define "implicit" the scope of the traffic sign/road marking to its orientation?

@carsten-kuebler I am in favor of implizit - which is btw IMO pretty explizit :)

Update:
The sign looks into X direction by default. If you turn the Yaw then the sign turns -> 180° yaw is a sign looking in -x direction
A roadmarking is painted on the road and looks upwards in the sky -> therefore if the road has a pitch becuase it is going up the hill the roadmarking has also a pitch.

can you remove the "normale" and update the comments -> I will directly merge afterwards!

[carsten-kuebler]

@ppannusch is it ok to add this illustration to the doxygen?
@carsten-kuebler I guess it is fine!

I made an illustration to visualize the coord. systems of traffic signs and road markings (orientation base stationary of the object).

Note: Rear side of stop traffic sign views STOP image. This is only for illustration. In real you would see no image.

Yes. If the road has a pitch, the road marking has the same pitch. If the traffic sign is "out of order", x-Axis of traffic sign is orthogonal to the lane so that the traffic sign is not visible, only the rear side of the sign is visible.)

[ppannusch-bmw]

Looks good; in my personal view adding the yaw/pitch values would make it a little bit clearer. Then you would have an actual example, e.g. by making the HOST vehicle being aligned at yaw=0

[carsten-kuebler]

@ppannusch I changed the definition of the axis. So I think it is easier to understand (now view normal is z-axis and top is x-axis).
A vehicle has to regard a "directed" road marking (e.g. speed limit compared to "undirected" road marking e.g. zebra), if the host/ego vehicle coord. system is aligned "equal" to the BaseStationary coord. system of the road marking.

For that reason (using the same coord. system definition for traffic signs), z-axis of traffic sign's BaseStationary is the view normal of the traffic sign image and x-axis points to the sky. Therefore, y-axis of traffic sign's BaseStationary points to left direction and -(y-axis) points to right direction (if the traffic sign has a constraint in which direction to apply). If anyone uses a traffic sign upside down (x-axis of traffic sign's BaseStationary points to the ground), "left and right direction is swapped" (e.g. no parking to one direction traffic sign which is used upside down)! The DirectionScope is the traffic sign constraint's logical information ("normal" viewers perspective).

@carsten-kuebler we just reviewed the picture in detail:
The normal case would be a traffic sign standing at the side of the road, less ofter painted on the street.

Hence, the viewing normal should be in X-Direction and the Z-Axis should point to the sky, because z axis means up.

Maybe I do not understand your argumenation?

UPDATE:
Remove the fictive coordinate system and use the one above for directional scaope:

// The definition for left and right:
// Build a fictive coord. system.
// z-axis of the fictive coord. system is equal to the GT z-axis.
// x-axis of the fictive coord. system is like the view normal of the traffic sign (\c TrafficSign::base.orientation z-axis).

This will in the end be correct:

// Right: direction of the fictive coord. system's y-axis.
// Left: opposite direction of the fictive coord. system's y-axis i.e. -(y-axis),

@carsten-kuebler
Stvo293
is missing for the road marking

@carsten-kuebler :
optional double value = 4;

This field should not specify a unit. We need an additional UNIT field as an enum. (km/h, mph, miles, ton imperial/metric,...)

Update:
It is also needed for the suplementary_sign

[ppannusch-bmw]

Update:
Also 720, the green filter arrow, needs to be added (after concluding that it should not be part of traffic lights.