And of course, I have got this response before. But now that I think about it, the limiting factors seem to be:
1. Editors (I use iD primarily) do not allow you to easily see the *exact* past history of an element. Nor does osm.org really (why does it give a list of changed elements and map area and not even allow you to see what tags and elements' geography are changed!?). OSMcha only does it on a per-changeset basis. https://osmhv.openstreetmap.de/ does this perfectly. 2. What if the source is in a changeset 2+ changesets ago? I shouldn't have to look back in the history to find a source. On Mon, Nov 16, 2020 at 9:09 PM Seth Deegan <jayands...@gmail.com> wrote: > 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.ke...@gmail.com> > wrote: > >> On Mon, Nov 16, 2020 at 9:20 PM Dave F via Tagging < >> tagging@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@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> >> >> -- >> 73 de ke9tv/2, Kevin >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Thanks, > Seth > -- Thanks, Seth
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging