Ways at the bottom of OSM's road classification hierarchy (highway=service) present a particular challenge for Curvature.
The adams_default.sh processing-chain already filters out ways with service= values of driveway, parking_aisle, drive-through, parking, bus, emergency_access, and alley. This eliminates a huge number of ways that definitely shouldn't be included, but there are still millions of ways that don't have a service=* value that are twisty enough to clear the "300" curvature threshold to get included in the output database:
Total output road segments: 10,173,773
Total service road segments: 1,539,183 (15%)
Total ways: 14,377,515
Total service ways: 1,617,900 (11%)
Option 1: Eliminate all highway=service
While this would successfully eliminate the spurious small ways, it may also eliminate a number of roads that are correctly tagged as highway=service but are fun-to-ride publicly accessible roads. Some of these are paved service roads in parks and forests that provide access to lakes or overlooks. Others are service roads that connect different portions of corporate campuses or other large facilities. These should be tagged with access=* if they are not publicly accessible and filtered out in that way. If they are publicly accessible they should stay in the database.
Option 2: Provide additional filtering of highway=service ways
Going this direction would keep some highway=service ways in the database, but use additional techniques to distinguish between fun ones and not-fun ones and keep the non-fun ones out.
2.a. Squash curvature near junctions
Many service roads around industrial buildings and parking lots have lots of junctions with other service roads (such as those tagged with service=parking_aisle). While I don't want to squash curvature values at every driveway along rural highways, squashing curvature near junctions on service ways is probably much more appropriate.
A less drastic squashing could entail only junctions with higher-classification roads, a more drastic squashing could entail every junction.
2.b. Filter service roads to a minimum length
Currently Curvature isn't doing any filtering on minimum length for roadways in order to not accidentally remove a short segment of great switchbacks. Given the challenges of service roads, minimum length filtering of service roads may be useful to eliminate short service ways that loop around buildings.
2.c. Filter service roads to a travel distance
Currently Curvature isn't doing any filtering on minimum travel distance. Loop-roads are just as valid as point-to-point roads. Service roads are often loops, sometimes short loops. There may be a travel distance/loop-length that could be reasonably filtered out to eliminate small loops around buildings while keeping larger loops through parks.
2.d. add extra nodes prior to calculating curvature
A common pattern seen with service ways around buildings is to have a rectangular-ish box around the building. Since each of these is a 90° corner, the curvature values can add up significantly compared with most models of other streets.
Service ways could be split straight-aways at a given distance from each node so that the entire length of the side doesn't go toward the curvature value. this would deflate the overall curvature value somewhat, making them more likely to be filtered out.
2.e. Apply differing rules for named vs unnamed service ways
2.f. Determine proximity to other features and squash curvature near them
It would greatly change Curvature's processing sequence, but if each node knew the proximity to buildings or other map features, then curvature values could be squashed when ways are a certain distance from those features. This would be very difficult to implement, but would attack the underlying challenge -- not wanting to whiz around building entrances and loading docks.
Ways at the bottom of OSM's road classification hierarchy (
highway=service) present a particular challenge for Curvature.The
adams_default.shprocessing-chain already filters out ways withservice=values ofdriveway,parking_aisle,drive-through,parking,bus,emergency_access, andalley. This eliminates a huge number of ways that definitely shouldn't be included, but there are still millions of ways that don't have aservice=*value that are twisty enough to clear the "300" curvature threshold to get included in the output database:Option 1: Eliminate all
highway=serviceWhile this would successfully eliminate the spurious small ways, it may also eliminate a number of roads that are correctly tagged as
highway=servicebut are fun-to-ride publicly accessible roads. Some of these are paved service roads in parks and forests that provide access to lakes or overlooks. Others are service roads that connect different portions of corporate campuses or other large facilities. These should be tagged withaccess=*if they are not publicly accessible and filtered out in that way. If they are publicly accessible they should stay in the database.Option 2: Provide additional filtering of
highway=servicewaysGoing this direction would keep some
highway=serviceways in the database, but use additional techniques to distinguish between fun ones and not-fun ones and keep the non-fun ones out.2.a. Squash curvature near junctions
Many service roads around industrial buildings and parking lots have lots of junctions with other service roads (such as those tagged with
service=parking_aisle). While I don't want to squash curvature values at every driveway along rural highways, squashing curvature near junctions on service ways is probably much more appropriate.A less drastic squashing could entail only junctions with higher-classification roads, a more drastic squashing could entail every junction.
2.b. Filter service roads to a minimum length
Currently Curvature isn't doing any filtering on minimum length for roadways in order to not accidentally remove a short segment of great switchbacks. Given the challenges of service roads, minimum length filtering of service roads may be useful to eliminate short service ways that loop around buildings.
2.c. Filter service roads to a travel distance
Currently Curvature isn't doing any filtering on minimum travel distance. Loop-roads are just as valid as point-to-point roads. Service roads are often loops, sometimes short loops. There may be a travel distance/loop-length that could be reasonably filtered out to eliminate small loops around buildings while keeping larger loops through parks.
2.d. add extra nodes prior to calculating curvature
A common pattern seen with service ways around buildings is to have a rectangular-ish box around the building. Since each of these is a 90° corner, the curvature values can add up significantly compared with most models of other streets. Service ways could be split straight-aways at a given distance from each node so that the entire length of the side doesn't go toward the curvature value. this would deflate the overall curvature value somewhat, making them more likely to be filtered out.
2.e. Apply differing rules for named vs unnamed service ways
2.f. Determine proximity to other features and squash curvature near them
It would greatly change Curvature's processing sequence, but if each node knew the proximity to buildings or other map features, then curvature values could be squashed when ways are a certain distance from those features. This would be very difficult to implement, but would attack the underlying challenge -- not wanting to whiz around building entrances and loading docks.