This issue is the same for routes for other modes of transport, especially hiking.I know a hiking route using a bus transfer through a tunnel. I know one in Switzerland using a train through a tunnel but only in winter. I know one using a bus transfer for all cycling and hiking routes over a 30 Km long dyke. And lots of ferries over rivers and lakes. I know canoe routes with foot sections (portage).
I would keep the solution as generic and as simple as possible. As it happens, a basic functional role set has recently been approved for such routes.It assigns a rol to approaches, excursions, alternatives and connections between routes. I was thinking about adding a role "transfer", to be assigned to a member relation. The relation that gets the role "transfer" is a route relation of a different transport mode. It's all the information you need, so there is no need for transport mode specific roles. There is one complication to be considered: the different type of roles cannot be combined in one relation. Especially for cycling, a particular way of the route could have the forward|backward role, belong to an alternative|approach|excursion|connection, and belong to a transfer section, all at the same time. A relation member cannot have the forward|backward role, but it could be both transfer and one of the approved basic role set. This complication can always be solved within a relation hierarchy, though. Best, Peter Elderson Op do 18 jun. 2020 om 21:58 schreef Volker Schmidt <vosc...@gmail.com>: > I know several bicycle route segments on water: ferryboat, waterbus, > private on-demand boat. > On rail: One route contained a normal rail segment. > By Bus: scheduled buses on road segments with heavy traffic. > We should consider these other means as well in any proposal. > : > > On Thu, 18 Jun 2020, 20:32 Francesco Ansanelli, <franci...@gmail.com> > wrote: > >> Dear all, >> >> I discussed with local mappers about the need of a role "take_train" or >> "public_transport" to fix bicycle routes... >> Would anybody be so kind to make a proposal about this post? >> >> Many thanks >> Cheers >> Francesco >> >> Il giorno lun 16 dic 2019 alle ore 13:49 Francesco Ansanelli < >> franci...@gmail.com> ha scritto: >> >>> >>> >>> Il lun 16 dic 2019, 10:56 Warin <61sundow...@gmail.com> ha scritto: >>> >>>> On 16/12/19 20:21, Martin Koppenhoefer wrote: >>>> >>>> Am Mo., 16. Dez. 2019 um 10:02 Uhr schrieb Volker Schmidt < >>>> vosc...@gmail.com>: >>>> >>>>> Can we come back to talking about a solution. >>>>> Maybe an appropriate new role value could be a solution: >>>>> role=take_train on the corresponding train section in the bicycle route, >>>>> for example. >>>>> However, this would provide an easy way to add train ride details. >>>>> >>>> >>>> >>>> I would add the train route relation as member, rather than the >>>> individual railway ways. >>>> >>>> If the entire train route is used then ok. But if only a section is >>>> used then I think the relevant ways only should be included. >>>> >>>> If a simple dataconsumer is not aware, it would should a hole in the >>>> bicycle relation (what IMHO is a good way to show that there is something >>>> special, in particular that you cannot simply ride your bike there), while >>>> a data consumer who specifically understands the situation could give >>>> specific directions. I agree a specific role also seems reasonable (could >>>> be extended to ferries, trams, aerialways, etc.) >>>> >>>> >>>> role=take_train would not work for ferries, buses, canoes etc. >>>> >>>> >>>> I think role=transport could work .. provided the way identifies what >>>> form of transport is used ... that could be a problem for bus routes? >>>> >>>> role=transport_train/transport_bus??? >>>> >>> >>> >>> I agree with the 'transport' name, it's the same I was thinking too... >>> Also 'transport_relation' could be fine. >>> Since you are adding a relation as segment you will get the type of >>> relation from it. >>> At this point I'd remove all information from the rail, do a relation >>> ptv2 and add that to my route. >>> >>> >>>> >>>> _______________________________________________ >>>> 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
