tilezen / vector-datasource

Tilezen vector tile service - OpenStreetMap data in several formats
https://www.nextzen.org/
Other
505 stars 119 forks source link

Add hiking routes (paths) #596

Closed nvkelso closed 8 years ago

nvkelso commented 8 years ago

Thinking more about an outdoor style, we should show selection "national" and regional trails like the John Muir Trail, Pacific Crest Trail, and Appalachian Trail earlier than zoom 13. This should probably be a new, optional layer, or the existing roads layer.

See also:

Route types, zooms:

Tags:

John Muir Trail: zoom 10

where the Pacific Crest Trail would be shown at zoom 9, then JMT at zoom 10.

screen shot 2016-03-11 at 16 48 45

Appalachian Trail: outside of DC at zoom 10

screen shot 2016-03-11 at 17 01 17

Near Geneva: zoom 10

screen shot 2016-03-11 at 17 04 08
rmarianski commented 8 years ago

Connects to https://github.com/mapzen/vector-datasource/pull/681

nvkelso commented 8 years ago

The early zoom part of this issue was completed (though in modified form).

No attributes from the relation were projected onto the way, though. EG, name was not backfilled, and network & operator are only present when already attached to the way directly.

nvkelso commented 8 years ago

The earlier fix in https://github.com/mapzen/vector-datasource/pull/681/files only applied basic walking paths, but it turns out many "forest" highway=track features are also part of walking relations.

Example (network=rwn, so min_zoom expected to be 12):

nvkelso commented 8 years ago

Overall looking good. But needs refinement to promote up cycleway and tracks when part of a hiking relation (Marin Headlands), and to suppress uninteresting footway from zoom 14 (Golden Gate Park).

nvkelso commented 8 years ago
zerebubuth commented 8 years ago

Here's a list of all the highway values which are members of iwn, nwn, rwn or lwn network relations:

    highway     | num  
----------------+------
 path           | 6881
 footway        | 6550
 residential    | 2267
 cycleway       | 1786
 track          | 1321
 tertiary       | 1186
 secondary      |  847
 unclassified   |  672
 service        |  600
 primary        |  526
 steps          |  386
 trunk          |  148
 bridleway      |  142
 pedestrian     |   64
                |   27
 corridor       |   19
 proposed       |   16
 primary_link   |    8
 secondary_link |    7
 construction   |    5
 motorway_link  |    2
 trunk_link     |    2
 road           |    2
 abandoned      |    1
 tertiary_link  |    1
 living_street  |    1

I have to say I'm pretty surprised to see motorway_link in there...

This raises the question of whether the "included in important relation" calculation should be more widespread, as there are 477 residential and 189 unclassified members of iwn or rwn that would (?) want to be included earlier than zoom 12, and 600 service roads too.

If we're doing this more widely, and to more roads, then it's possible we'll run into performance issues.

Also: What's the final decision on zoom levels? Are we just sticking to 13 for everything, or should iwn, rwn be promoted to 12 or 11?

zerebubuth commented 8 years ago

Also: What's the final decision on zoom levels? Are we just sticking to 13 for everything, or should iwn, rwn be promoted to 12 or 11?

Forget I asked that, I see that the mz_calculate_path_major_route function is already promoting them. I'll assume those are the levels we want to keep.

nvkelso commented 8 years ago

Forget I asked that, I see that the mz_calculate_path_major_route function is already promoting them. I'll assume those are the levels we want to keep.

Yes, that's working as-is with the tests passing at earlier zooms.

In North America zooms 11 and 12 only have a few trails. I'm cautiously optimistic about Europe, but this will be more intensive there as the relations are more prevalent, in greater detail, and include more international and national routes.

nvkelso commented 8 years ago

Here's a list of all the highway values which are members of iwn, nwn, rwn or lwn network relations:

This sounds like a combination of the is_bus_route work in last release, and the planned is_bicycle_route work in this release.

Both of those are/propose tagging ways with a boolean that it's related to a walking (or bicycling) route. Is there a signed bicycle route present on the road, versus is there bike lane infrastructure on the road. Same for sidewalks (errr, the roads with sidewalk tags, not separate sidewalk ways).

Question: Should we add one for paths like is_walking_route? This feels like a rabbit hole / different chunk of work than is needed for the core WIP outdoor style.

It's like bus since the query is predicated on the feature already being included in the feature selection at the evaluated zoom. We've already adjusted the feature zooms in first and pending 2nd PRs. But that seems to be calculating the logic twice.

Proposal: recalculate the mz_calculate_path_major_route() result and store onto each way as part of the migration. Then use that feature property in the query logic, and export the value in the properties. But that sounds expensive, especially if we do this for all (or a wider set of) road types. Thoughts?

Regarding the visibility of roads available for this:

where a road already needs to be included to be marked part of a path

highway=residential currently shows up at zoom 12. highway=tertiary currently shows up at zoom 11. highway=secondary currently shows up at zoom 10. highway=unclassified currently shows up at zoom 12. highway=service currently shows up at zoom 14 (with some variation).

The only problematic one I see is highway=service where gaps will be more obvious at zooms 12 and 13. Otherwise the existing min_zoom values line up pretty well with things.

zerebubuth commented 8 years ago

The only problematic one I see is highway=service where gaps will be more obvious at zooms 12 and 13. Otherwise the existing min_zoom values line up pretty well with things.

We show iwn, nwn routes starting at zoom 11, so that would affect residential, unclassified, road, trunk_link, primary_link, secondary_link, tertiary_link, portage_way and living_street in addition to the variety of service roads.

Calculating the is_walking_route probably won't be too expensive - they're no more prevalent than bus routes in downtown areas, which we're handling pretty well already.

Basically, what I'm asking is whether all road types with a min zoom > 11 should have their min zoom replaced with LEAST(min_zoom, route_min_zoom) where the latter is calculated from the ?wn route level?

zerebubuth commented 8 years ago

@nvkelso do we want to pull the network from the relation with this as well?

nvkelso commented 8 years ago

It would be useful to know the network type and export that in tiles, if it's not too much trouble.

nvkelso commented 8 years ago

(There are issues with the outdoor style today where the map is hard to follow in areas with many trails on zoom in. Knowing the original network class could help resolve that visual hierarchy problem.)

zerebubuth commented 8 years ago

I'm pretty confused about what we actually want in this task. The original description seems to be about bringing the route relation geometry into the tiles, along with attributes on the relation.

I think we then decided it was better to do something more like the bus routes, just having a flag on the way which indicates that it is part of a walking route relation. Is that what we want?

(Optionally a walking_route=(iwn|nwn|rwn|lwn) property instead of / in addition to the flag if that's feasible?)

zerebubuth commented 8 years ago

739 hopefully captures everything we want. @nvkelso - could you check it, please?

nvkelso commented 8 years ago

I think we're 95% the way there. There are some gems left over in my other branch https://github.com/mapzen/vector-datasource/commits/nvkelso/early-path-revisions where I was revising the earlier in #739, I'll take over from here to merge that logic in to the PR. Thanks!

nvkelso commented 8 years ago

I'm pretty confused about what we actually want in this task. The original description seems to be about bringing the route relation geometry into the tiles, along with attributes on the relation.

The downpayment for this more complicated issue was completed under: https://github.com/mapzen/vector-datasource/issues/593 and this huge PR: https://github.com/mapzen/vector-datasource/pull/681.

It's gotten a little confusing to follow since then, but I think it's mostly sorted out now :)

nvkelso commented 8 years ago

Looking good!

nvkelso commented 8 years ago

Oops, filtering paths at zoom 14/15 – we're removing too much stuff at 14, please adjust the max zoom to 14 from 15 for footway & steps.

nvkelso commented 8 years ago

remove:

  - filter:
      highway: steps
      name: true
    min_zoom: 'LEAST(mz_calculate_path_major_route(osm_id), 14)'
    table: osm
    output:
      <<: *osm_highway_properties
      <<: *osm_network_from_tags
      <<: *osm_footway_properties
      kind: path
      highway: steps
      footway: {col: tags->footway}

keep but make 14:

  - filter:
      highway: [footway, steps]
    min_zoom: 'LEAST(mz_calculate_path_major_route(osm_id), 15)'
    table: osm
    output:
      <<: *osm_highway_properties
      <<: *osm_network_from_tags
      <<: *osm_footway_properties
      kind: path
      highway: {col: highway}
      footway: {col: tags->footway}
nvkelso commented 8 years ago

Final work in this PR: https://github.com/mapzen/vector-datasource/pull/786.

nvkelso commented 8 years ago

Looking great!