Support for oncoming traffic information

francocipollone commented 1 year ago

Summary

Related to

Information of oncoming traffic is wanted to be obtained from the map.

oncoming traffic" means the lane crosses other lanes containing traffic going in the opposite direction. For example, an unprotected right-turn lane has "oncoming traffic" because it crosses some lanes that go in the opposite direction. In some complex maps, determining whether a lane has oncoming traffic is non-trivial and requires geometric analysis heuristics, which is why we want to add a "hint" as to whether a particular lane has oncoming lanes.

Proposal

Going from top (maliput api) to bottom (xodr).

maliput offers a rule api that we could use in our advantage in order to offer this kind of information from the api. We could create a DiscreteValueRule of type_id: OncommingTraffic where values would be False or True.
The rules are expected to be loaded in the RoadRulebook when loading the RoadNetwork. For doing so there are naturally two ways:
- A: We could provide a side yaml file with rule information: Example: LoopPedestrianCrosswalk.yaml This is achievable immediately.
- B: If this information is somehow obtainable from the XODR file, then we could parse it in runtime and load it automatically to the RoadRulebook. --> e.g: Nowadays we do the same with SpeedLimits and DirecitonUsage rule types.
The OpenDRIVE format doesn't have a particular field for describing Oncomming Traffic, however, it supports adding user data. In this way, we could extend the xodr parser to look for an OncomminTraffic field in the userData tag under the Lane tag.
```
                <lane id="0" type="none" level= "0">
                    <userData>
                        <vectorLane travelDir="backward" oncommingTraffic="true"/>
                    </userData>
                </lane>
```

Steps

[ ] Extend XODR parser to support oncommingTraffic tag.
[ ] Create Rules out of the oncommingTraffic information
[ ] Add rules to the RoadRulebook during RoadNetwork build time.

francocipollone commented 1 year ago

I'd like to hear your thoughts here @agalbachicar

CC: @liangfok

liangfok commented 1 year ago

Overall looks good. Thank you for filing this. Is option A (side yaml file) still desirable assuming we are able to extend the XODR parser to support oncomingTraffic? I assume it is just a temporary place holder until option B is achieved (obtain oncoming traffic information directly from XODR file).

francocipollone commented 1 year ago

We had a F2F chat with @agalbachicar in order to brainstorm a bit about this idea.

The information of oncoming traffic is something that could be computed in maliput_malidrive out of the graph information that we have in the junctions, so this will prevent us from continuing to add information to the description that will end up being redundant if it is something that can be indirectly obtained.
Regarding how to provide this information. Technically, this is not a traffic rule and this simply provides some extra useful information. So it isn't a perfect match at a concept level, however, the rule API here is useful because it is where you get also rules like the DirectionUsage, so having the OncomingTraffic as well may be handy. Alternatively, we could offer a query at maliput::api::Junction level (to be implemented by backends) or simply a method to be used downstream for evaluating the oncoming traffic for a particular lane in a particular junction.

wdyt @liangfok

liangfok commented 1 year ago

Thanks for discussing this.

Regarding whether has-oncoming-traffic could be automatically derived based on analyzing a junction, I actually had the same thought and previously asked our downstream users why it could not be automatically derived. They indicated that (1) there are certain "complex" intersections in which determining this requires heuristics and possibly unreliable geometric analysis, and (2) not all lanes need to be annotated as such even they actually do have oncoming traffic, so automatically adding it to all lanes that have oncoming traffic would actually provide too much information. I think we can consider this "has-oncoming-traffic" flag analogous to training wheels on a bike, bumpers in a bowling alley, or scaffolding at a construction site -- use it judiciously, on a limited basis, and remove it as soon as it is no longer needed.

Good point about how oncoming-traffic isn't technically a "rule" so doesn't exactly match the "road rulebook" concept. It also doesn't change state so it would not make use of the fact that Maliput rules have states (plural). I'm beginning to think that this has-oncoming-traffic is a meta-property of the lane itself, and thus should be stored in the maliput::api::Lane class and accessible via a method like std::map<std::string, std::string> maliput::api::Lane::meta_info() where one of the key/values in the returned map is {"has_oncoming_traffic", "true"}.

francocipollone commented 1 year ago

(2) not all lanes need to be annotated as such even they actually do have oncoming traffic,

This is a bit controversial and clearly goes against to any automatic mechanism for identifying this.

I think we can consider this "has-oncoming-traffic" flag analogous to training wheels on a bike, bumpers in a bowling alley, or scaffolding at a construction site -- use it judiciously, on a limited basis, and remove it as soon as it is no longer needed.

So if the use case is so particular and can't be generalized, and it won't be used in the near future, I am kind of reluctant of the path I proposed above. Sounds like it is a particular case to be solved downstream. I am seeing with good eyes now to provide that extra information via the geojson file as you did in https://github.com/maliput/maliput_xodr/pull/39 .

I'm beginning to think that this has-oncoming-traffic is a meta-property of the lane itself, and thus should be stored in the maliput::api::Lane class and accessible via a method like std::map<std::string, std::string> maliput::api::Lane::meta_info() where one of the key/values in the returned map is {"has_oncoming_traffic", "true"}.

I think that this meta info could be a nice addition, it gives flexibility to the backends to dump there stuff that goes off api.

maliput::api::Lane class and accessible via a method like std::map<std::string, std::string> maliput::api::Lane::meta_info() where one of the key/values in the returned map is {"has_oncoming_traffic", "true"}.

This is actually interesting,

liangfok commented 1 year ago

Alright, how about let's for now adopt the GeoJSON approach (https://github.com/maliput/maliput_xodr/pull/39) as the simplest possible solution? I can add a comment in the GeoJSON entry indicating that those has-oncoming-traffic properties are intended to be ephemeral and incomplete hints that are not actually loaded into the RoadNetwork object (at least as of writing). If sufficient use cases arise, we can reconsider adding a meta-info feature to a Maliput Lane like std::map<std::string, std::string> maliput::api::Lane::meta_info().

francocipollone commented 1 year ago

Alright, how about let's for now adopt the GeoJSON approach (maliput/maliput_xodr#39) as the simplest possible solution? I can add a comment in the GeoJSON entry indicating that those has-oncoming-traffic properties are intended to be ephemeral and incomplete hints that are not actually loaded into the RoadNetwork object (at least as of writing). If sufficient use cases arise, we can reconsider adding a meta-info feature to a Maliput Lane like std::map<std::string, std::string> maliput::api::Lane::meta_info().

I think it makes sense taking that path :rocket:

liangfok commented 1 year ago

@francocipollone shall we close this as done given the following? https://github.com/maliput/maliput_xodr/commit/00330218267661fb3fdcf2b5b2d631822ca348ce

francocipollone commented 1 year ago

@francocipollone shall we close this as done given the following? maliput/maliput_xodr@0033021

Indeed! Closing...

maliput / maliput_malidrive