Missing UUIDs for `TrafficSpace` elements containing crosswalk and similar `TrafficArea`s

[CodeMazeSolver]

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 TrafficAreas 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>

[beneschwab]

Thanks for reporting! Yes, all TrafficSpaces and TrafficAreas need a GML ID. I'm currently fixing that.

Generally, TrafficSpaces and TrafficAreas 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?

[CodeMazeSolver]

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.

[beneschwab]

Missing GML IDs should be fixed with b2c3e9f on the develop branch.