On Fri, May 15, 2020 at 7:31 AM Paul Allen <pla16...@gmail.com> wrote: > I've encountered footpaths and bridleways that include farm service roads as > part of their route. So far, I've mapped the footpaths as the bits that > aren't > service roads. That renders the functionality of the ways but doesn't > encode in any way that the service road is a public footpath. I did find > one example of somebody doing it differently: he mapped a bridleway in > its entirety, including the bit along a service road, and also mapped > the service road (which coincided with part of the bridleway). It > still rendered the service road as a service road on standard carto but > using the query tool on the bridleway showed the full extent of the > bridleway. > > Using a relation seems like another way of handling the situation. > Or maybe I'm misunderstanding...
Using a relation is the PREFERRED way of handling that situation. I have a strong preference NOT to create two ways for the same physical object, so where a public footpath is on a road - which happens a lot around here - I map that segment of the road, map the off-road segments as footways or paths as appropriate, and use the route relation. Thus, Old Piseco Road https://www.openstreetmap.org/way/20092775 is itself tagged '`highway=tertiary` (and has some other rubbish from TIGER). It's a member of the road route 'Hamilton County Road #24', and a member of the foot route 'Northville-Placid Trail.' I don't want to have to dredge up the route information (what does the waymark look like, etc.) from an enigmatic and tightly encoded `ref=*` on a way. The relation can have ref, network (this is important), name, symbol, whatever is needed. (It should NOT have physical properties of the route such as `surface` or `smoothness`: those go on the ways.) Otherwise, I have a problem with concurrences like Old Piseco Road. As a trail, it's part of a 'rwn' network. As a road route, it's part of the network named 'US:NY:Hamilton'. What do I put in `network=*` if I map it just on a way? Island View Road (https://www.openstreetmap.org/way/5595536) is part of multiple relations: Mohawk-Hudson Bike-Hike trail as a foot route, Mohawk-Hudson Bike-Hike Trail as a cycle route (Note that the two are different because the cycle route doesn't use the sidewalk in urban neighbourhoods), Erie Canalway Trail (an unfinished relation, and the mappers that maintain it have yet to make the split between road and sidewalk), and the (unmapped as yet) Empire State Trail). (Memo to self: Downgrade it: It's clearly `residential` and not `tertiary`.) The Bear Mountain Bridge https://www.openstreetmap.org/way/84620188 hosts two road routes (US 6 and US 202), a cycle route (NY Bicycle Route 9), and a major foot route (the Appalachian Trail). Obviously, there's no sensible way to represent all that without the relations. Moreover, a route relation remains a single object even if the way is split. When I split https://www.openstreetmap.org/way/507687342 to add the bridge, I didn't need to worry about the relations except to make sure that all three parts stayed in them. And a route relation can easily be overlaid on existing ways. When they posted orange markers on https://www.openstreetmap.org/way/509364137, I simply took the formerly-unmarked trail (which wasn't part of any relation, not being marked!) and added it to the route relation that I created for it. As a data consumer, I have a strong preference to have only one way of looking for something. Looking for route information on ways, and assembling ways that belong to the same route, is tricky. (More important, it's brittle, and there are a lot of things to go wrong if the data aren't perfect.) Obviously, it wouldn't be tricky at all if the route were a single segment, like https://www.openstreetmap.org/relation/3122185 - but why add a corner case rather than treating all routes uniformly? So I'm of the opinion, "if it would need a route relation if something else were concurrent, or if it were split, then it needs a route relation." -- 73 de ke9tv/2, Kevin _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
