[Tagging] Tagging Cycle Route Relations vs. Ways

Seth Deegan jayandseth at gmail.com
Tue Nov 17 03:09:40 UTC 2020


May I ask why not source=*? I know it's basically depreciated, but many
times I find myself wondering where past mappers got the info for a route
(this happened just today). I would find it very helpful. It also doesn't
require the tagging of all of the ways.

On Mon, Nov 16, 2020 at 8:45 PM Kevin Kenny <kevin.b.kenny at gmail.com> wrote:

> On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging <
> tagging at openstreetmap.org> wrote:
>
>> Be careful. This is where many contributors get confused. The name of the
>> *path* is often not the name of the *route*. A route relation can, & often
>> does, go along paths with different names. Multiple routes can go along a
>> path.
>>
>
> To give a more concrete example, there's a rail-trail in my neighborhood
> called the Mohawk-Hudson Bike-Hike Trail.
> It has a relation, for several reasons that I'll discuss below.  Most of
> its member ways are also named 'Mohawk-Hudson Bike-Hike Trail'. There are a
> few ways, however, that have the names of highways because freeways and
> active rail lines interrupt the rail grade, and the trail follows some
> lightly-trafficked streets for a short distance before rejoining the
> grade.  Those ways have name='Dunsbach Ferry Road', name='Island View
> Road', name='Scrafford Lane', name='Iroquois Street', etc, but remain
> members of the route named 'Mohawk-Hudson Bike-Hike Trail'. (Actually,
> there are two route relations: one for cycling and one for walking.)
>
> Large portions of the rail-trail are, in turn, used by two long-distance
> routes: the Erie Canalway Trail and the Empire State Trail.  There are
> separate relations for these two, and most of the members of the
> Mohawk-Hudson Bike-Hike Trail are also members of these other relations.
> (That does not affect the names of the member ways. The Mohawk-Hudson
> signage is consistent, while the signage for the other two trails is still
> something of a work in progress, although there's a lot more of it than
> there used to be. The naming of the member ways follows the commonest
> signage.)
>
> There are a great many member ways because of changes of the
> characteristics of the way (bridge=yes, embankment=yes, bicycle=dismount,
> surface changing from asphalt to wood on a bridge, and so on.)
>
>>
> The Mohawk-Hudson relation exists (a) because not all the member ways have
> its name (since it borrows roads for short segments) and (b) because
> Waymarked Trails and other data consumers do better with a route relation
> grouping all the ways, rather than trying to assemble a route from ways
> with nothing in common other than being named alike.
>
>>
>> I assume this is not prefered because a number of applications use the
>> names in the Ways themselves and not the Route Relation, most notably
>> osm-carto.
>>
>>
>> It renders the names of the paths, not the routes.
>>
>>
>> However, some benefits of doing this might be:
>>
>>    - Takes up less space in the DB
>>    - More tags that apply to the whole coute could be added to the
>>    Relation like surface
>>    <https://wiki.openstreetmap.org/wiki/Key:surface>=* and source
>>    <https://wiki.openstreetmap.org/wiki/Key:source>=* (like the official
>>    map of the route).
>>
>>
>> Surface has no place in a route relation as it refers diectly to the
>> path, not the multiple relations passing along it. Similar for the source
>> tag.
>>
>> DaveF
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> 73 de ke9tv/2, Kevin
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Thanks,
Seth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201116/b8b97993/attachment.htm>


More information about the Tagging mailing list