Question: Is low_emission_zone handled in Valhalla?

[xlqian]

Hello,

In order to be compliant with French/European legislation, a motorist should be notified and be aware of the fact he is traversing an LEZ(https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dlow_emission_zone).

Could you let us know if this issue has already been tackled in Valhalla? A quick search has shown nothing interesting about the LEZ. If nothing has been done regarding it yet, Are you interested in this subject? we can contribute.

Regards

[nilsnolde]

Oh yes, I'd be. I was trying to push that years ago for openrouteservice in the German OSM community, but that discussion was so destructive that it upset me enough to just drop it.. It's still in the ether though (unfortunately only on German): https://forum.openstreetmap.org/viewtopic.php?id=65638. I think it's a quite wide topic to cover the range of low-emission-zones that exists (if that's the goal), but it surely also depends on how granular one wants to get (e.g. time-/fuel-/weight-dependencies).

On the processing side, I don't think we really do any relation processing like this, i.e. ways in polygons, but I might be wrong. It's not a show-stopper, but likely complicates things.

If you're up for an implementation, I personally would very much welcome it and would be happy to assist here and there. Could've been a nice GSoC project as well in fact. I think it's big enough that we should discuss the process/design a bit more in detail before tackling. Would you be willing to draft an abstract of the tags and steps needed? Doesn't have to be crazy detailed, we can drill down from the bigger ones.

[kevinkreiser]

it reminds me very much of administrative boundary processing except in this case we don't store admin info we store a bit that says the edge intersected the boundary. I would suggest we follow that as a model, loosely.

the question to me is do we need to parse the boundary info at the same time we build the tiles or can we preprocess it in a separate binary like admin boundaries and add it via sqlite intersections during tile building.

maybe we could generalize valhalla_build_admins into valhalla_build_boundaries and update the sqlite schema to hold any number of interesting area features. then during admin setting in the tile build we could also set other properties based on what other area features were in there

[nilsnolde]

Hahah right, the admin boundaries.. Yeah, very similar concept.

Then I guess we'd mostly need a more thorough review of how things are tagged in OSM and how we'd like to support those things in the graph/request. I think there's more needed than one bit, at least to get the full information, e.g. one bit to indicate there's a transition in/out of such an area, then in EdgeInfo or wherever a bit more info about what that zone is exactly? Again, depends on what's out there and how we want to expose it in the request parameters.

[xlqian]

Thank you guys for the quick response. We appreciate it.

https://forum.openstreetmap.org/viewtopic.php?id=65638

I wish I could read German. :smile:

we preprocess it in a separate binary like admin boundaries and add it via sqlite intersections during tile building

We have had a very similar idea which seems to be quite intuitive to us, but could be a quite time-consuming process, right? since we have to iterate every edge to figure out with which LEZ it intersects, but again, it seems quite intuitive and it's worth trying (I've no idea if what I'm saying makes any sense to you...)

maybe we could generalize valhalla_build_admins into valhalla_build_boundaries ...

Sound to me like a great starting point, we're going to have a closer look at this part...

we'd mostly need a more thorough review of how things are tagged in OSM... depends on what's out there and how we want to expose it in the request parameters.

totally agree with that, and here is what we have found regarding the tag LEZ: https://overpass-turbo.eu/s/1rkN

[nilsnolde]

since we have to iterate every edge to figure out with which LEZ it intersects

Right, it doesn't seem intuitive, but IIRC that's what the admin processing does as well. And I don't think you really feel it too much. Also, here it's "just" crossing, not a full intersecting, which should be much faster (i.e. I think what Kevin says makes sense, we only need to know when it's entering/leaving a LEZ probably? then only very few edges have that info and it'd be very feasible to store some more info in EdgeInfo or elsewhere to retrieve it during expansion). EDIT: think about this again.. We do want to know whether an edge is inside a LEZ. So 2 bits are more likely what we need. It's still not a performance issue as there's so little LEZ globally.

totally agree with that, and here is what we have found regarding the tag LEZ: https://overpass-turbo.eu/s/1rkN

That's an easy one:) I raise you this: https://openstreetmap.org/relation/271888. Look at the motor_vehicle:conditional tag, there's quite a few variations of that. I'm not saying we want to support all of that, but unfortunately LEZ != LEZ. Where do we draw the line and how do we communicate that to the user in terms of request parameter?

[nilsnolde]

Likely also needs processing for ways: https://www.openstreetmap.org/way/113941240.

[kevinkreiser]

to really tell the full story in my mind, im kind of thinking a bigger picture architecture. what id like to see is we have a binary that pulls out area (maybe even point) features from osm that we dont strictly use for routing on, stuff like:

• country/state borders for admins
• parks, beaches, geological features
• buildings, pois

and those go into spatialite with a spatial index, like we do with admin boundaries today but with different types of metadata (maybe we just save all the tag/value combos without further processing). once we have that db, we can then in graph enhancer enhance the graph, optionally, with these different things. we can add admin info to the nodes as we do today, or we can do a pass over the db to add landmark features to the edges for landmark routing (eg. turn left at lafayette park, keep left at the starbucks, etc), or we can do a pass to add open area features (ie invent some edges in the graph for routing over fields and parks and the like).

im thinking about a general architecture that lets us basically pull out stuff from osm that isnt routable but can be used to enhance the routing when we build the tiles. it would then be some config option in mjolnir as to which types of features to pull out of osm in this new version of valhalla_build_admins that would do the pulling (preprocessing) from osm.

the devil is in the details of course but i just think if we setup a general infrastructure around this we could enable a bunch of future-looking features. hell, because the format is just sqlite you could even load non-osm data in there (ignoring the licensing question at the moment) for other open datasets that arent in osm (green or scenic zones or who knows what)

[DiviyamPathak]

this would be also great in India. Unfortunately we don't have enough data and uniform legislation it would be great for MSMEs in Urban cities in India

[nilsnolde]

Anecdotally, Google Maps seems to have recently (?) implemented LEZ as a visual element only, of course they have no way of respecting them in the routing:)

[nilsnolde]

Recently I thought about LEZ again, leaving my thoughts here..

An alternative to the sqlite approach: We could make LEZ a separate structure of the tile data, instead of putting the info into directededge/edgeinfo/nodeinfo, where bits are rare.

Actually that can also be combined with an sqlite approach, though it depends on how we'd do it.. We could also just record the edge IDs in each tile which are cut by an LEZ ring (not the ones enclosed), then track LEZ along the expansion in the edge labels and turn LEZ costing on/off when encounter one of these edges, depending on whether the predecessor was in-/out-side an LEZ. If it's on the edge labels, it's also readily available to Odin and guidance without touching PBF. Additionally, such an approach would be very generic for other use cases, such as other area features which should influence costing, e.g. preferring/avoiding static areas or even green routing.

My opinion:

Pros

• much more flexibility with bits usage to try and cover all relevant LEZ types
• option to use LEZ for costing & flagging in guidance
• not much space needed, 64 bit per edge is plenty (percent_along, some enum/mask for LEZ types)

Cons

• hassle with tile compatibility
• bit of a space waste, globally there's very few LEZ relatively
• not a generic concept (unless we'd do the EdgeLabel solution)