-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include Turn Restrictions? (Or some representation of them) #5
Comments
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 |
@maning we talked through the implications of a Another thought we had was to create a new "type" of geometries (akin to geometrified versions of |
Some prior discussion on storing turn restrictions as GeometryCollection tyrasd/osmtogeojson#75 (comment)
@mojodna see this example geojson where the member order and other tags can be explicitly defined as properties of the GeometryCollection |
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. |
@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. |
When including geometries, osm-wayback is basically a history-enabled version of
minjur
orosmium-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 usinglibosmium
to parse the current planet file and spit out saidgeojson
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)
The text was updated successfully, but these errors were encountered: