Improvements on extended traffic signs

[carsten-kuebler]

@pmai Removed typos and change order of enum Type for traffic sign.

[carsten-kuebler]

@CarloVanDriestenBMW and @pmai please review additional extensions to traffic signs and road markings. Please consider:

1. "generic road marking symbols" like bicycle are currently missing in enum RoadMarkings.Type. We could reuse painted_traffic_sign not only for the image (237 StVO) but also for the generic symbol (Sinnbilder §39 Abs. 7 StVO).
2. We add a string attribute for textual road markings (e.g. BUS). If OSI will not use strings as attributes, we could proceed similar as 1) --> type generic text symbol. (Drawback: We are limited to textual road markings that are represented as a traffic sign. -> no destinations like M for Munich, but destinations are also missing in OSI traffic signs).

[carsten-kuebler]

@CarloVanDriestenBMW and @pmai
3. (re)using painted traffic sign's enum also for generic symbols give the possibility to reduce road marking's enum type. (If we do this, all variations of traffic sign 531 StVO should be added?!)

[ghost]

// Additional value associated with the traffic sign, e.g. value of the speed limit.
// Field need not be set if traffic sign type does not require it. Speed (limits) should be given in km/h.
optional double value = 4;

are there countries which have traffic signs in two different units? IF SO: We have to add a unit field?

[ghost]

@carsten-kuebler some thoughts:

to 1) I would say YES - we are defining the logical information of traffic signs here, therefore the logical information is stored in the trafficSign.Type for (237 StVO) but also for the generic symbol (Sinnbilder §39 Abs. 7 StVO). The information can then be referenced in optional TrafficSign.Type painted_sign_type = 4;
IMO:
It would be easier if the roadmarkings.types could be merged with the trafficSign.types resulting in a single enum describing the logical information.

to 2) I would leave the string for the texts painted as roadMarkings as proposed in your PR.

to 3) as written before: The goal would be a single enum for logical types and additional flags and infos describing that logical information when painted on the street.
Taxi as "string" "just the image of a taxi" or the official "taxi allowed traffic sign"

could you do that?

[pmai]

I've fixed the merge conflict and rebased the changes to make them mergeable, should build correctly now (also with the auto-merging PR build). @CarloVanDriestenBMW if that fits your ideas, we can directly merge this.

[carsten-kuebler]

@pmai thankyou

[ghost]

@carsten-kuebler Is the list completely checked against the different STVOs? Some have references and some not?

[carsten-kuebler]

@CarloVanDriestenBMW The list is checked against StVO. We add all traffic signs, which were missing in respect to begin/end signs, similar groups of signs, etc. There are a lot of more traffic signs in StVO. All this traffic signs have their StVO reference.

We add also "traffic signs" which exist only in one way in StVO, e.g. "no u-turn right" (StVO has only "no u-turn left").

We also add "traffic signs" which do not exist in StVO, e.g. "u-turn left" which exists only as road marking. (There is a "u-turn" traffic sign in South Korea.

These additional traffic signs have no reference to StVO (because they are not used in germany).

[ghost]

@pmai and @carsten-kuebler isn't that something for the "DetectedTrafficSign" ?

optional Vector3d view_normal = 6;

There is no viewing angle in a global view or?

[carsten-kuebler]

@CarloVanDriestenBMW it is necessary to define what is left or right from the signs point of view ("no parking" sign with an "arrow to the left" and the traffic sign on the left/right side of the lane) and to define if you can see the traffic sign (in a construction area if the sign is turned way "out of order" or if you can see the sign if the road turns).

[ghost]

@carsten-kuebler : look at #138

[carsten-kuebler]

@CarloVanDriestenBMW I made a new PR for issue #138. It adresses an exact definition of the BaseStationary::orientation and how to apply the road markings and traffic signs.
This PR adresses still the TYPE definition of the road marking.

[ghost]

@carsten-kuebler I got the feeling that we will have some conflicts here ^^

[carsten-kuebler]

@CarloVanDriestenBMW resolved :-)

[carsten-kuebler]

@CarloVanDriestenBMW merge conflict resolved....

[pmai]

I'll again rebase this branch onto master to cleanup the history prior to merging.

[carsten-kuebler]

@pmai it should already been cleaned up, isn't it?

[pmai]

@carsten-kuebler a lot of the old commits that were replaced by the rebase I did earlier have resurfaced (after a rebase a git reset --hard origin/branchname on the branch is needed to get rid of the old commits in ones own repository), plus lots of intermediate merges with master by carlo somewhat mess up the history and we probably don't want to pull that into master... So content-wise it should be ok, but the history is really messed up.

[pmai]

Ok, I've re-rebased against master, and lost the CI-problem-induced Type Renaming for Road Markings again. This should be the correct content now (without superceded changes and other unrelated changes due to master merges). Please do a git fetch, git checkout Extended-Traffic-Signs followed by git reset --hard origin/Extended-Traffic-Signs if you need to work further on this branch.

@CarloVanDriestenBMW please add positive review if this should be merged now...

[ghost]

positive