Sarah: > There is relatively few software that can handle hierarchic relations. One could argue that putting alternatives in separate relations makes it actually harder to access those.
I think it's fair to say there is almost no software that does anything with route relations except rendering and exporting as a gpx. Dislaying elevation prophile is also one you can find, and it shows nicely what inconsistency does: break up the prophile. Rendering looks OK because in the end you display the ways and it doesn't matter if they are out of order, double, running in loops or whatever. For A to B navigation you need single ordered chains without all the variations and reduplications. If that can be done at mapping level, datausing software could actually be made to work with that. Now you can only export a track (losing the map info), strip it in an editor to create your own route, and then move it to the routing or planning software which then recombines it with a map. That's why I say: 1. Routes with only ways OR only part relations 2. No double ways 3. Always have one single strand main route; alternatives as separate single strand routes. 4 If need be, put them together in a master relation which does NOT have to be single strand, it's mainly there for the common tags. (This could support network planners/routers). 5. Roles of alternative routes in the master relation could be used to adapt display. Maybe it's easier to apply a role tag within the relation itself to alter display of that relation, don't know. If you have a subrelation which is part of multiple parent relations, roles could conflict. Could be main route in one, excursion in another and link in a third.... Fr gr Peter Elderson Op do 15 aug. 2019 om 13:57 schreef Sarah Hoffmann <lon...@denofr.de>: > Hi, > > (making this a new topic) > > On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote: > > I strongly prefer to have one relation for the main route, and separate > relations for alternatives. Put those together in a relation with roles for > the member relations, not for individual ways. So the lowest level always > contains only ways, the higher level contains only relations. > > Using subrelations is not consistent with the current use of > forward/backward roles. > I'd consider alternatives, excursions and access routes to be equivalent > to those. > > > The ways in the main relation should form one continuous sorted > (sortable) route, which data users can extract or link to for navigation or > planner software. > > There is relatively few software that can handle hierarchic relations. > One could argue that putting alternatives in separate relations makes > it actually harder to access those. > > In the end, it doesn't really matter if you put the role on way or > relation members. I'd just allow both. (Although I agree that ways and > relation member shouldn't be mixed in a single relation.) > > The more important part is to agree on a couple of roles so that > mappers and software know what to use. > > I did a quick count and that's what is in use most currently for roles > on hiking routes: > > alternatives: alternative(117), alternate(105) > side paths: excursion(166) > access paths: link(85) > > and for cycling: > > alternatives: alternative(74), alternate(64) > side paths: detour(25) > access paths: link(78), connection(52) > > NB: They are used almost exclusively on way members. > > Sarah > > > > > Note that rendering routes is not that critical, but data use is > increasingly important. > > > > Fr gr Peter Elderson > > > > > Op 15 aug. 2019 om 09:35 heeft Warin <61sundow...@gmail.com> het > volgende geschreven: > > > > > >> On 15/08/19 17:00, Peter Elderson wrote: > > >> Where/to what exactly do you apply the role? > > > > > > In the relation. > > > > > > See https://www.openstreetmap.org/relation/1388126 > > > > > > Here the 'normal' members are simple ways with no role, these form the > route itself. > > > > > > Those that have a relationship role of 'alternate' in this instance > are relations themselves but the could be more simple ways. > > > These form alternate routes to the main route. > > > They could be for any number of reasons - hight tides or flooded > rivers. > > > In this case the Hornsby original goes through a firing range, Little > Wobbly is a cheaper alternative to a private water taxi, > > > the other I am not certain of, possibly an 'access tack' from a train > station - I would have to look. > > > > > > Note I am not the author here of 'alternate', but I have done some > work on the OSM route. > > > > > >> > > >> Mvg Peter Elderson > > >> > > >>> Op 15 aug. 2019 om 01:20 heeft Warin <61sundow...@gmail.com> het > volgende geschreven: > > >>> > > >>> It would be usefull to document the method of including alternate, > side trips and access tracks to these routes. > > >>> > > >>> At the moment I and others are using the role 'alternate' for track > alternative paths. > > >>> > > >>> For 'side trips' (short paths to features of interest) possibly the > role 'side_trip'? > > >>> > > >>> For 'access tracks' (paths from common and signed places that leas > to teh main track) possibly the role 'access_track'? > > >>> > > >>> > > >>>> On 13/08/19 18:50, s8evq wrote: > > >>>> Hello everyone, > > >>>> > > >>>> On the discussion page of the wiki entry Hiking ( > https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme.) > I have started a topic, but with little response so far. That's why I come > here, before proceeding. > > >>>> > > >>>> > > >>>> Currently, there are four tagging scheme tables describing how > walking (or hiking) routes should be tagged. > > >>>> https://wiki.openstreetmap.org/wiki/Hiking > > >>>> https://wiki.openstreetmap.org/wiki/Walking_Routes > > >>>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking > > >>>> https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot > > >>>> > > >>>> Would it not be easier and more clear if we just keep one, and add > a link to it in the others? > > >>>> > > >>>> Last month, I already started harmonizing these four tagging scheme > tables. I changed the order, added some missing tags, adjusted the > explanation etc... In my view, I only had to do minor edits. For those > interested, here are my edits: > > >>>> > > >>>> > https://wiki.openstreetmap.org/w/index.php?title=Hiking&type=revision&diff=1878387&oldid=1873054 > > >>>> > https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes&type=revision&diff=1881156&oldid=1879580 > > >>>> > https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking&type=revision&diff=1878383&oldid=1853636 > > >>>> > https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot&type=revision&diff=1878384&oldid=1853797 > > >>>> > > >>>> So these four tagging scheme tables are now almost 100% the same. > > >>>> > > >>>> > > >>>> My idea was to keep the tagging scheme table on one of the wiki > pages, and put a link to it on the three other pages. I would like to have > broader support before going further. > > >>>> > > >>>> > > >>>> Of course, we can discuss about the content of the tagging scheme. > But that's irrelevant to my question about the organization of the wiki > page. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> > > > > > > > > > _______________________________________________ > > > Tagging mailing list > > > Tagging@openstreetmap.org > > > https://lists.openstreetmap.org/listinfo/tagging > > > > _______________________________________________ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
