Include Turn Restrictions? (Or some representation of them)

[jenningsanderson]

When including geometries, osm-wayback is basically a history-enabled version of minjur or osmium-export. (Trading +history for -intelligence and -speed)

That said, a simple representation of turn restrictions (only where via is a single node) could be written out as single points with specific turn_restriction tags could included (with the node_locations column family, this is not much more work). This would be helpful for understanding the change in coverage of turn-restrictions (just a proxy, not complete record) over-time, at decent geographic scales.

^The primary change is that this would require iterating over the relations Column Family and producing geometries on it's own, rather than enriching existing geometries. Once output, however, these could be tiled just like any other GeoJSON feature.

@maning, just putting this idea here to document it, a more practical approach to turn_restriction analysis (though not historically-enabled!) is likely defining a (useful) geometric representation and just using libosmium to parse the current planet file and spit out said geojson representation of turn restrictions. There are < 1M turn restrictions in the whole planet?

^A more scalable, future-looking approach to handle these (especially with history) is to define a useful "geometric representation" and incorporate into OSMesa (@mojodna is thinking about how to do this best... among many other things)

[maning]

Thanks for cutting this ticket @jenningsanderson! What you outlined here using single point representation is a good starting point.

But for context, I would love for us to have full geometry as a GeometryCollection. We use osm-qa-tiles for fixing data errors in with OSMLint, but we had to create a separate linter repo for TR using pbf and osmium (see OSMlint-osmium)

cc @Rub21 @danmactough

[mojodna]

@maning we talked through the implications of a GeometryCollection a bit; it seems like it'd end up being a collection of 3 geometries:from,via, andto`, logically in that order, though that leads to the problem. When parsing it, one would need to rely on convention rather than something more explicit...

Another thought we had was to create a new "type" of geometries (akin to geometrified versions of nodes, ways, relations), say derived that include synthetic tags on them. All of the geometries associated with a single turn restriction would include that type, the id of the relation that they belong to as well as individual tagging on each geometry to indicate its role. This seems like it would facilitate clean rendering (+ ability to highlight constituent geometries) while also including the context for each part w/o overwhelming the consumer with otherwise-unrelated geometries.

[planemad]

Some prior discussion on storing turn restrictions as GeometryCollection https://github.com/tyrasd/osmtogeojson/issues/75#issuecomment-313688951

it seems like it'd end up being a collection of 3 geometries:from,via, andto`, logically in that order , though that leads to the problem. When parsing it, one would need to rely on convention rather than something more explicit...

@mojodna see this example geojson where the member order and other tags can be explicitly defined as properties of the GeometryCollection

[planemad]

Additionally, i feel when converting relations to geometries, one does not need to preserve every coordinate of the members since the relation is an abstract concept. Geometry simplification that just preserves the terminal points of line members is sufficient to represent it visually.

[mojodna]

@planemad GeoJSON can include that information in GeometryCollection ids (👍), but outside of that world (i.e. MVTs, PostGIS, etc.) we can't tag individual components w/ ids.

I definitely agree that simplification to terminal points is sufficient, though that seems like an optional thing that could result in richer rendering if desired.