Description
Hi all,
We are working on creating an adapter between our internal model and the OSI model. In our internal model we support traffic signs from different countries. Every country has its own standardized set of traffic signs. I can understand that the OSI model wants to have ground-truth information about the traffic signs, but why use an enumeration for this? The current enumeration only lists a subset of the German traffic signs, but more importantly the enumeration basically hard-codes the traffic signs. This makes it hard to extend or change the set of supported traffic signs.
In our internal model we try to be very generic with traffic signs, which means we have the following ground-truth data in the model:
-
type, a string to identify the country set, for example TrafficSignPoleD
-
name, a string to identify the traffic sign itself, for example z101 (Zeichen 101
-
category
- Warning // CatA
- WarningSlope // CatA2
- Regulation // CatB
- Guide // CatC
- Auxiliary // CatD
- Directions // CatE
- Transitions // CatF
- School // CatS
- Miscellaneous // CatX
- Custom // CatY
-
shape
- shapeRound
- shapeOctagon
- shapeTriangle
- shapeTriangleInverted
- shapeDiamond
- shapeRectangle
- shapeSquare
- shapeTrapezoid
- shapePentagon
- shapePennantRight
- shapePennantLeft
- shapeCrossbuck
- shapeArrowLeft
- shapeArrowRight
Are there any plans to allow for different sets (country) of traffic signs? I see already a more conceptual mapping to the German signs is in osi_trafficsign.proto, especially with message to address TrafficSignValue with different values and units. But also I encounter Types like: TYPE_TRAFFIC_LIGHT_GREEN_ARROW which is more special than generic.
Regards, Lo