Derivation of areal geometries for road signals

[benediktschwab]

OpenDRIVE allows defining an optional width and height attribute for road signals (used for traffic signs & traffic lights). Currently, the CityGML objects derived from this are only represented by point geometries, although an areal geometry representation would be beneficial.

[thomashkolbe]

This is not correct. CityGML uses so-called "ImplicitGeometries", which utilize a 3D anchor point in the world coordinate system and an arbitrary 3D shape using a local cartesian coordinate system plus a 4x4 transformation matrix that is used to rotate and scale the 3D shape. In case the 3D anchor point uses a metric, cartesian world CRS, then after applying the transformation matrix to the local coordinates of the 3D shape, the coordinates of the anchor point can simply be added. I recommend to create an ImplicitGeometry and/or to include the attributes width and height as generic attributes to the respective CityFurniture object.

[benediktschwab]

This is a misunderstanding since the issue refers to the OpenDRIVE road signals (see OpenDRIVE specification v1.7.0: 12. Signals). So far, rtron only takes the road signal position (s, t, and hOffset attributes in the reference line coordinate system) into account, because the width and height of road signals have been seldomly used in OpenDRIVE datasets. Hence, this issue's original goal was to remind me that this information should be taken into account in the future and implemented in rtron.

Actually, when rtron converts OpenDRIVE signals to CityGML CityFurniture objects, implicit geometries are already used. The reference point and the 4x4 transformation matrix (rotation only) are already determined. This functionality was implemented some time ago to allow FME workbenches to correctly place traffic signs and traffic light assets without having to rely on generic attributes.

[benediktschwab]

The conversion of OpenDRIVE signals (traffic lights and traffic signs) to CityGML CityFurniture was just improved. In addition to the lod1ImplicitRepresentation, a lod2MultiSurface is derived from the OpenDRIVE road signal width and height: In this way, model asset replacements can still be performed using the implicit geometries, and the LOD2 geometries are well suited for sensor data analytics on the database, for example.