search

tum-gis / rtron

r:trån is a road space model transformer library for OpenDRIVE, CityGML and beyond
https://rtron.io
Apache License 2.0
46 stars 12 forks source link

Derive CityFurniture relations #29

Closed CodeMazeSolver closed 1 year ago

CodeMazeSolver commented 1 year ago

Issue

Currently, there is no connection between the street sign or other CityFurniture which are important for one specific section of the road. This includes but is not limited to speed limits and restrictions for certain lanes.

Task

Map information, such as traffic sign information (speed limits, etc.) with respect to the corresponding street segment.

Solution Idea

Use the linear referencing in OpenDRIVE and add a generic attribute to the corresponding CityGML street objects using generic attributes or a link to the corresponding CityFurniture object.

thomashkolbe commented 1 year ago

This is a good point. I am not sure about the proposed solution idea, but at least in CityGML 3.0 we should insert explicit relatedTo relationships. These relations must have a value for the relationType attribute. We should choose something that is describing the specific relationship between the CityFurniture (e.g. traffic sign) and the respective TrafficSpace (e.g. driving lane). It would also be useful to express the relations in both directions, i.e., from the TrafficSpace feature to the CityFurniture and vice-versa. The relation type from CityFurniture to the respective TrafficSpace could be belongsTo. The relation type from TrafficSpace to the related CityFurniture objects could be relatedFurniture. Maybe OpenDRIVE defines also some suitable relation types that could be adopted. If not, also a look into the data model of SUMO could help to see how signals and traffic signs are related to the individual sections of driving lanes.

benediktschwab commented 1 year ago

Thanks for raising this issue and the solution ideas. OpenDRIVE has concepts for the lane validity of objects (OpenDRIVE 1.7 section 11.4; e.g. parking lots) and for the lane validity of signals (OpenDRIVE 1.7 section 12.1; e.g. traffic signs and traffic lights). By default, objects and signs are valid for all lanes starting at a defined position along the reference line. The validity can be restricted to specific lanes (lateral to the road axis). As far as I know, there is no explicit restriction in longitudinal direction since the validity of a sign is often terminated by the following sign of its type and traffic lights can be interpreted as temporary stop lines.

The partitioning of the CityGML Sections and Intersections into TrafficSpaces currently follows the OpenDRIVE concepts of laneSections (longitudinal) and lanes (lateral). A modification of the partitioning would be possible but would mean a larger development effort and would also have disadvantages (e.g. more objects and geometries).

For these reasons, my suggestion would be that we insert the proposed relatedTo CityGMLv3 relationships for the particular TrafficSpaces in which the object is located longitudinally. If the exact validity start position of a sign is needed, the position of the sign could be projected onto the linear geometry representation of the TrafficSpace, for example. This could serve as a temporary solution for now because ASAM is currently working on an international traffic sign model.

@CodeMazeSolver Would such a conversion enhancement be sufficient for your application?

CodeMazeSolver commented 1 year ago

Thanks for raising this issue and the solution ideas. OpenDRIVE has concepts for the lane validity of objects (OpenDRIVE 1.7 section 11.4; e.g. parking lots) and for the lane validity of signals (OpenDRIVE 1.7 section 12.1; e.g. traffic signs and traffic lights). By default, objects and signs are valid for all lanes starting at a defined position along the reference line. The validity can be restricted to specific lanes (lateral to the road axis). As far as I know, there is no explicit restriction in longitudinal direction since the validity of a sign is often terminated by the following sign of its type and traffic lights can be interpreted as temporary stop lines.

The partitioning of the CityGML Sections and Intersections into TrafficSpaces currently follows the OpenDRIVE concepts of laneSections (longitudinal) and lanes (lateral). A modification of the partitioning would be possible but would mean a larger development effort and would also have disadvantages (e.g. more objects and geometries).

For these reasons, my suggestion would be that we insert the proposed relatedTo CityGMLv3 relationships for the particular TrafficSpaces in which the object is located longitudinally. If the exact validity start position of a sign is needed, the position of the sign could be projected onto the linear geometry representation of the TrafficSpace, for example. This could serve as a temporary solution for now because ASAM is currently working on an international traffic sign model.

@CodeMazeSolver Would such a conversion enhancement be sufficient for your application?

Thank you for the detailed answer. Your suggestion to project the object to the TrafficSpace would be enough for my current application, as I'm just interested in a connection of the CityFurniture objects related to the individual lane. So far I am also using the TrafficSpace elements for connecting multiple segments together. Therefore, it would be beneficial to have the information connected to these objects. On the other side, there are many useful information (roughness, material type, speed limit) stored as generic objects in the corresponding TrafficArea related to each TrafficSpace object. So it might be a good idea to store this information there as well till a formal concept is included in the CityGML standard.

benediktschwab commented 1 year ago

A relation from the CityFurniture to the TrafficSpace and vice versa was implemented following the relation types suggested by Thomas (see commit: https://github.com/tum-gis/rtron/commit/b2c3e9fb721b93b63fd589a9459d8c9ee96f24f1). Since the lane validity can be defined to any road object and signal in OpenDRIVE, this is now also implemented in the conversion process. That means that also building objects and vegetation objects are related to the respective TrafficSpaces. It is questionable whether this is really reasonable, but at least it provides the user with the possibility to use this information.

Concerning the generic attributes of TrafficArea: This has backward compatibility reasons to have this information also available in CityGML2 with the 3D City Database. But they are now also added to the TrafficSpaces for CityGML3 (see commit: 2a055a7).