Expose underlying OSM data for a street leg

[tuukka]

When I receive a street leg from the planner, I would like to analyse the respective OSM data along the path: barriers, entrances, steps etc. Could the Path somehow expose the OSM ids and the tile contents for this?

[hdelva]

It would require some tinkering to do it in a clean way, but we should definitely be able to expose the underlying ways!

Unfortunately, it wouldn't be exactly in the OSM data model. We split up tags such as access=yes into a key and a value, which makes the data more idiomatic because we create a definition for each one separately, but we also had to rename some ambiguous values such as yes. In the case of access=yes, the value becomes osm:FreeAccess. I think there's a full list in the README of https://github.com/openplannerteam/routable-tiles-ontology.

We know that this will be confusing to people who already know the OSM data model though. I've been wanting to add some reasoning on top of our Routable Tiles data to fix issue. The semantics of

_:example_node osm:access osm:FreeAccess .

are actually the same as

_:example_node osm:hasTag "access=yes" .

We just need to actually add this equivalence, but we didn't have a usecase for it yet. Now that we do, I think we can actually make this happen. I'm not sure how soon this could be done though, it's all a bit experimental.

[tuukka]

Thank you for the good news! 😊 The ontology doesn't look too different to me.

Can my project team help with the implementation? To start, would we add the OSM node and way ids to IPath? Then there could be a separate API to find the tile based on the node coordinates and to return the OSM data.

Perhaps an interesting use case to consider is how to detect intersections: you have a way id and a node id, but how do you query whether the same node belongs to another way as well? The raw OSM data model is not convenient for that.