Closed nvkelso closed 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.
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):
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).
track
example in Marin Headlands is way/12188550, is member of Bay Area Ridge Trail, a regional network, and should be present in 12/654/1582
:cycleway
example south of SF, way/109993139, is member of regional cycling network, should be present in 12/655/1586
:stairs
example, in SF, way/25292070, should be visible in 14/2620/6334
:footway=sidewalk
example, in SF at SF State, way/346093021, visible at 15/5235/12671
.footway=crossing
example, in SF, way/344205837, visible in 15/5234/12667
.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?
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.
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.
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.
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?
@nvkelso do we want to pull the network from the relation with this as well?
It would be useful to know the network type and export that in tiles, if it's not too much trouble.
(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.)
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?)
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!
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 :)
Looking good!
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.
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}
Final work in this PR: https://github.com/mapzen/vector-datasource/pull/786.
Looking great!
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:
network=iwn
at zoom 9network=nwn
at zoom 10network=rwn
at zoom 11network=lwn
at zoom 12Tags:
name
route
=kind
network
operator
ref
John Muir Trail: zoom 10
where the Pacific Crest Trail would be shown at zoom 9, then JMT at zoom 10.
Appalachian Trail: outside of DC at zoom 10
Near Geneva: zoom 10