Missing UUIDs for `TrafficSpace` elements containing crosswalk and similar `TrafficArea`s
CodeMazeSolver opened this issue · 3 comments
Issue description
I noticed that within the generated CityGML file some TrafficSpace
objects do not have an individual UUID. All of those occurrences seem to be related to the usage as a container for TrafficArea
objects such as crosswalks.
For generating complete pedestrian networks it could be beneficial to connect the two sides of the road via the crossWalk
element by adding a usable TrafficSpace
object and connecting it with predecessor and successor links to the SIDEWALK
TrafficSpace
objects next to the crosswalk.
The image shows a scene in which such a crosswalk is present in the output CityGML file. It has limited semantic information, compared to the other TrafficArea
s of the road. Thus, it is just connected to the road via the generic attributes.
Code example
The following code shows the output CityGML data with the TrafficSpace
elements missing a unique identifier (UUID).
<tran:trafficSpace>
<tran:TrafficSpace>
<boundary>
<tran:TrafficArea gml:id="UUID_4b3f2da5-6f01-3393-aa26-58afc3faa71c">
<gml:name>crossWalk</gml:name>
<genericAttribute>
<gen:StringAttribute>
<gen:name>identifier_roadObjectId</gen:name>
<gen:value>4030022</gen:value>
</gen:StringAttribute>
</genericAttribute>
...
</tran:TrafficArea>
</boundary>
<tran:granularity>lane</tran:granularity>
</tran:TrafficSpace>
</tran:trafficSpace>
Thanks for reporting! Yes, all TrafficSpace
s and TrafficArea
s need a GML ID. I'm currently fixing that.
Generally, TrafficSpace
s and TrafficArea
s originate either from the OpenDRIVE lanes (containing lane predecessor/successor information) or from the OpenDRIVE roadside objects. The latter does not contain any predecessor/successor information in the OpenDRIVE dataset and can be recognized by the existence of the generic attribute identifier_roadObjectId
in the CityGML dataset. If you need them represented in the routing graph, you would probably have to perform geometric analyses to identify the (closest) adjacent sidewalks.
But this issue only addresses the missing GML IDs, right?
Yes, this is referring to the missing GML IDs.
For my application an available successor/predecessor connection would have been great. However, as they do not even exist in the OpenDRIVE dataset I would proceed and generate them by using the geometry to find adjacent sidewalks.
Missing GML IDs should be fixed with b2c3e9f on the develop branch.