Re: [Tagging] Amenity=fountain
On 7/3/20 6:34 pm, Joseph Eisenberg wrote: There's a star on the menu bar on top of the wiki page, just after "View history", where you can "Add this page to your watchlist" That's right. It will also be automatically added to your watchlist if you edit the page, if you have the default settings for the wiki. This may send you an email notification, or you can check: https://wiki.openstreetmap.org/wiki/Special:Watchlist - and turn off email notifications. I've reverted the revert. :-) Not wise to get into an edit war. The only real difference to me is the inclusion of historical. I don't see why a fountain that is 'historical' does not also fit into one, or more, of the other classes in particular cultural? So I would not have added that in there. The rest of the words are simply clarification. I think that can be justified even with the past approval as there is no real change to the basic meaning? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Amenity=fountain
>There's a star on the menu bar on top of the wiki page, just after "View >history", where you can "Add this page to your watchlist" That's right. It will also be automatically added to your watchlist if you edit the page, if you have the default settings for the wiki. This may send you an email notification, or you can check: https://wiki.openstreetmap.org/wiki/Special:Watchlist - and turn off email notifications. I've reverted the revert. :-) - Joseph Eisenberg On 3/7/20, Alessandro Sarretta wrote: > Hi Stuart, > > On 07/03/20 08:04, European Water Project wrote: >> Dear All, >> >> On Feb 4th, we significantly clarified the definition of >> amenity=fountain after numerous discussions. >> https://lists.openstreetmap.org/pipermail/tagging/2020-February/050876.html >> >> >> >> It seems the core of our changes were undoneon Feb 26th >> https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dfountain&diff=1962588&oldid=1954415 >> >> >> causing more confusion on the subject of what constitutes a >> fountain. >> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dfountain#Use_for_drinking_water.3F > Maybe you can ask to the user > https://wiki.openstreetmap.org/wiki/User:MalgiK the reason for this (it > seems he refers to the original proposal wording). >> How does one sign up to received notifications about changes on >> specific pages ? > > There's a star on the menu bar on top of the wiki page, just after "View > history", where you can "Add this page to your watchlist" > > Ale > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Amenity=fountain
Hi Stuart, On 07/03/20 08:04, European Water Project wrote: Dear All, On Feb 4th, we significantly clarified the definition of amenity=fountain after numerous discussions. https://lists.openstreetmap.org/pipermail/tagging/2020-February/050876.html It seems the core of our changes were undoneon Feb 26th https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dfountain&diff=1962588&oldid=1954415 causing more confusion on the subject of what constitutes a fountain. https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dfountain#Use_for_drinking_water.3F Maybe you can ask to the user https://wiki.openstreetmap.org/wiki/User:MalgiK the reason for this (it seems he refers to the original proposal wording). How does one sign up to received notifications about changes on specific pages ? There's a star on the menu bar on top of the wiki page, just after "View history", where you can "Add this page to your watchlist" Ale ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Amenity=fountain
Dear All, On Feb 4th, we significantly clarified the definition of amenity=fountain after numerous discussions. https://lists.openstreetmap.org/pipermail/tagging/2020-February/050876.html It seems the core of our changes were undone on Feb 26th https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dfountain&diff=1962588&oldid=1954415 causing more confusion on the subject of what constitutes a fountain. https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dfountain#Use_for_drinking_water.3F How does one sign up to received notifications about changes on specific pages ? Best regards, Stuart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
I appreciate the proposal authors for helping to simplify mapping bus routes. I agree that in many cases it would be correct to only include the bus stops or train platforms in the relation, especial for longer-distance routes, where the bus or train might take several different routes depending on traffic or other reasons However, there are also public transit services where the bus can stop anywhere along the route. This is the most common type of bus here in Indonesia. In this case there are no fixed stops except for the 2 end points, but the minibus follows the same streets and passengers can wave their hand or request a stop anywhere along the route. These routes, common in Asia, Africa and Latin America, should be mapped just as a set of ways. So, I support the idea of allowing mappers to just add the bus stops to the relation when this is the most verifiable and easiest to maintain, but there are some cases where this will not work, so it should still be permitted to map the ways for non-fixed-stop services. I believe the “Refined Public Transport” proposal has already suggested this (mapping route relations as either just stops or just ways) and in general that proposal has good ideas which might be considered: https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport - Joseph Eisenberg On Sat, Mar 7, 2020 at 8:23 AM Peter Elderson wrote: > So, what about the idea to store the route in a separate route relation, > then add it as a optional member with role "route" to the PT relation? > You will have simplicity at the routing level and completeness at the route > level, without interference. > Without all the platforms, stops and waypoints the route itself will be > much easier to maintain. If no route member is present, the renderer can > approximate using what's in the routing relation. > Same goes for routers. They could use the route as present in the route > member, or choose to ignore that and recreate a fresh route along the stops > and other waypoints. > > Best, Peter Elderson > > > Op 6 mrt. 2020 om 23:52 heeft Andrew Harvey > het volgende geschreven: > > > > > > I think if people want to save the full route with way members, that > should be allowed. > > > > If someone wants to do a first pass with just using waypoint nodes or > just the stop_positions, I think that's fine too. > > > > So I'm against the proposal in the current form for this reason. > > ___ > > 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
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
So, what about the idea to store the route in a separate route relation, then add it as a optional member with role "route" to the PT relation? You will have simplicity at the routing level and completeness at the route level, without interference. Without all the platforms, stops and waypoints the route itself will be much easier to maintain. If no route member is present, the renderer can approximate using what's in the routing relation. Same goes for routers. They could use the route as present in the route member, or choose to ignore that and recreate a fresh route along the stops and other waypoints. Best, Peter Elderson > Op 6 mrt. 2020 om 23:52 heeft Andrew Harvey het > volgende geschreven: > > > I think if people want to save the full route with way members, that should > be allowed. > > If someone wants to do a first pass with just using waypoint nodes or just > the stop_positions, I think that's fine too. > > So I'm against the proposal in the current form for this reason. > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
I think if people want to save the full route with way members, that should be allowed. If someone wants to do a first pass with just using waypoint nodes or just the stop_positions, I think that's fine too. So I'm against the proposal in the current form for this reason. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
On 7/3/20 8:18 am, Paul Norman via Tagging wrote: On 2020-03-06 9:22 a.m., Peter Elderson wrote: That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? No. There is no one true route between two points, so there can't be an authoritative router. Why routing is a good idea. Let us say a route uses 4 ways in sequence. If those ways are sequentially inside the route then things are fine. It breaks when a mapper enters a turn restriction, breaking one of the ways a mapper enters some road works that close a section of one of the ways a mapper enters some speed limits that change alone one of the ways All of these break the route. If the route is entered as nodes on the intersection of each of the 4 ways then any of the above mapper changes will not brake the route. The routing engine may not pick the actual replacement route .. but it should be a reasonable approximation. The above could be the best way forward - it relies on the nodes used connecting continuous ways together thus leaving the routing engine little work to do. When (not if) that rule is broken then it indicates that the route needs to be checked, but in the mean time the routing engine will maintain the route in a usable fashion. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
As my personal biggest use of the public transportation relationship is to visualize the ways that public transit route would take, I must say I am personally against the idea. >From my personal experience of using a non-OSM website "wikiroutes", which is a website that let public enter public transit information from around the world into the platform for navigation and suggestion purpose by letting users first pick stop.m locations on a map, then try to automatically display the routing and finally let users correct the routing to complete the public transit route record in thdir database, I would say it's easier said than done to expect a software being able to auto-generate the ways based on station location, even with additional waypoints. First of all, I don't think there are any existing routing engines for trains on rail or bus or minibuses on street, so they will need to be developed first for renderer to be able to visualize these routes, especially for roads that regular vehicles cannot use. And then, for such renderer to work, access restriction for public transit vehicle need to be complete, which is rather difficult not just because of the work it take or the current incompleteness of the amount of keys in OSM that can be used to represent multiple localized types of transportation, but also because of things like mechanical restrictions of bus models that would not be available in any public document and cannot be verified outside of the public transit company. Second, when a user map a public transit relation using waypoints to handle a special case, how can they know when a waypoints would be needed? Even if such renderer is built into editor to show which route it would take and let users add waypoints when that's incorrect, different routers used by different renderers might route a route differently, what doesn't need a waypoint on one router maybe different on another router, how can editors know when it is necessary to add a waypoint to show a route correctly? If a new road is being built next to existing road which doesn't affect existing public transit routes, how to preemptively make sure routing engines won't automatically redirected a route to the new road? Third, way points are more transient than ways. It's more easy for a node to be deleted or replaced when editing geometry than ways. How to maintain integrity of a route geometry when others edit road geometry? At 2020-03-06 Fri 18:08, John Doe wrote: > > Stereo and I have been working on a schema that makes it easier to create > and maintain public transport route relations. We would like to invite > feedback, questions, and suggestions, so it can mature and hopefully gain > widespread use. > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
On 2020-03-06 9:22 a.m., Peter Elderson wrote: That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? No. There is no one true route between two points, so there can't be an authoritative router. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
It looks like it would save a lot of mapping work. While it avoids some problems, such as the relation becoming invalid due to mapper error, it may create new problems. Routers use different algorithms and routing profiles, and the data that may affect route generation (turn restrictions, speed limits, surface values) may change independently, affecting the computed route without changing the PTv3 relation with via points only. Sometimes this would be desirable, I can imagine that often it would not be. Perhaps it would make sense to write an editor or a plugin that can compute route members from a set of via points, which the mapper can check and sometimes correct before submitting a changeset. Also, if the PTv3 relation allows including both the route and some via points, then we'd have a new situation to validate: the existence of via points outside the route. On Fri, Mar 6, 2020 at 7:08 AM John Doe wrote: > > > Stereo and I have been working on a schema that makes it easier to create and > maintain public transport route relations. We would like to invite feedback, > questions, and suggestions, so it can mature and hopefully gain widespread > use. > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging -- Fernando Trebien ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
Mar 6, 2020, 15:22 by music.kash...@gmail.com: > > Thank you for sharing your thoughts 🙂 > > 06-Mar-2020 17:40:23 Andrew Harvey : > >> I think including the actual route is useful and makes life easier for >> downstream users (they don't need a routing engine to show the route), could >> this be optional so you can create a public transport route relation via >> waypoints only if you prefer as a starting point, but then still allow it to >> be completed via the way members. >> A bit like how most things can be initially mapped as a node but then are >> usually expanded out into an area. >> > > I'm afraid I'm against that idea, personally. I've mapped nearly 70 bus > routes in my city (and counting); I'm still their lone maintainer; I have > also dabbled with mapping railway routes. So many relations with so many ways > - especially highways, which are the first things newbies edit and thus are > the most likely to break a relation - are an enormous maintenance bomb > waiting to go off. (And sometimes it does go off, and the fallout goes on for > months.) > And it affects not only people mapping public transport routes. I would gladly put burden on data users (assuming that burden for data users is not significantly greater than burden removed from mappers). I was really happy when some bus routes become invalid and I was able to delete them. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
John Doe : > 06-Mar-2020 20:39:30 Peter Elderson : > > > > [...] Is it a significant burden to include a router with a renderer? > > I wouldn't know. It seems strange to me that established routes have to > be re-routed to display or use them. How can you be sure the re-created > route is the one that is defined by the operator? Keeping as an example the > city PT map. > > That is something that mappers/maintainers would have to test, as they > already do. The difference is that the time and effort required to create > and maintain the relation is greatly reduced. > > Tangentially, something that might help would be a validator for editors > that checks if a route (whether defined by ways or as deduced by a router > as we propose) matches user-specified GPS traces. > That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? I may be out of my depth, but I think a route for the map is observed and registered, not computed between A, B, C etcetera. A route on the fly is a different thing. Would it be an idea to make the route itself (the observed chain of ways) an optional member relation of the PT routing relation? With member role=route? Of course I would like to have a routing routine built into the relation editor, which can convert a survey gpx-trace to a route relation containing the closest chain of already mapped ways, that would make route maintenance much easier. (All kinds of routes, not just PT). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
06-Mar-2020 20:39:30 Peter Elderson : > > [...] Is it a significant burden to include a router with a renderer? > I wouldn't know. It seems strange to me that established routes have to be > re-routed to display or use them. How can you be sure the re-created route is > the one that is defined by the operator? Keeping as an example the city PT > map. That is something that mappers/maintainers would have to test, as they already do. The difference is that the time and effort required to create and maintain the relation is greatly reduced. Tangentially, something that might help would be a validator for editors that checks if a route (whether defined by ways or as deduced by a router as we propose) matches user-specified GPS traces. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
> Wouldn't that imply that a chart of PT lines in, say, a city, region or country would need to route everything first, then render instead of just render the route from OSM? > > Seems so. Is it a significant burden to include a router with a renderer? > I wouldn't know. It seems strange to me that established routes have to be re-routed to display or use them. How can you be sure the re-created route is the one that is defined by the operator? Keeping as an example the city PT map. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
06-Mar-2020 18:08:22 Peter Elderson : > If I understand this correctly, your proposal turns route relations into > routing relations. That's a clever way to put it 😄 > Wouldn't that imply that a chart of PT lines in, say, a city, region or > country would need to route everything first, then render instead of just > render the route from OSM? Seems so. Is it a significant burden to include a router with a renderer? > Vr gr Peter Elderson > > Op vr 6 mrt. 2020 om 11:08 schreef John Doe < music.kash...@gmail.com > [mailto:music.kash...@gmail.com] >: > > > > > Stereo and I have been working on a schema that makes it easier to create > > and maintain public transport route relations. We would like to invite > > feedback, questions, and suggestions, so it can mature and hopefully gain > > widespread use. > > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations > > > > [https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations] > > > > > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org [mailto:Tagging@openstreetmap.org] > > https://lists.openstreetmap.org/listinfo/tagging > > [https://lists.openstreetmap.org/listinfo/tagging] > > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
Thank you for sharing your thoughts 🙂 06-Mar-2020 17:40:23 Andrew Harvey : > I think including the actual route is useful and makes life easier for > downstream users (they don't need a routing engine to show the route), could > this be optional so you can create a public transport route relation via > waypoints only if you prefer as a starting point, but then still allow it to > be completed via the way members. > A bit like how most things can be initially mapped as a node but then are > usually expanded out into an area. I'm afraid I'm against that idea, personally. I've mapped nearly 70 bus routes in my city (and counting); I'm still their lone maintainer; I have also dabbled with mapping railway routes. So many relations with so many ways - especially highways, which are the first things newbies edit and thus are the most likely to break a relation - are an enormous maintenance bomb waiting to go off. (And sometimes it does go off, and the fallout goes on for months.) Besides - while I have never written a router or a renderer - I imagine that having to support both types of relations (PTv3 as well as v2) would create additional technical debt for routers and renderers. > Secondly I don't quite understand the no way member rule of your proposal, > since railways platforms should be a way > https://wiki.openstreetmap.org/wiki/Tag:railway=platform > [https://wiki.openstreetmap.org/wiki/Tag:railway=platform] then including the > platform in the relation means you need to include ways as relation members. Thank you for pointing that out. The ways it referred to were highways and railways - it has, of course, no objection to platforms as ways or areas. I have reworded the section, hopefully it is clearer. > On Fri, 6 Mar 2020 at 21:08, John Doe < music.kash...@gmail.com > [mailto:music.kash...@gmail.com] > wrote: > > > > > Stereo and I have been working on a schema that makes it easier to create > > and maintain public transport route relations. We would like to invite > > feedback, questions, and suggestions, so it can mature and hopefully gain > > widespread use. > > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations > > > > [https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations] > > > > > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org [mailto:Tagging@openstreetmap.org] > > https://lists.openstreetmap.org/listinfo/tagging > > [https://lists.openstreetmap.org/listinfo/tagging] > > > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
If I understand this correctly, your proposal turns route relations into routing relations. Wouldn't that imply that a chart of PT lines in, say, a city, region or country would need to route everything first, then render instead of just render the route from OSM? Vr gr Peter Elderson Op vr 6 mrt. 2020 om 11:08 schreef John Doe : > > Stereo and I have been working on a schema that makes it easier to create > and maintain public transport route relations. We would like to invite > feedback, questions, and suggestions, so it can mature and hopefully gain > widespread use. > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Public Transport v3
I think including the actual route is useful and makes life easier for downstream users (they don't need a routing engine to show the route), could this be optional so you can create a public transport route relation via waypoints only if you prefer as a starting point, but then still allow it to be completed via the way members. A bit like how most things can be initially mapped as a node but then are usually expanded out into an area. Secondly I don't quite understand the no way member rule of your proposal, since railways platforms should be a way https://wiki.openstreetmap.org/wiki/Tag:railway=platform then including the platform in the relation means you need to include ways as relation members. On Fri, 6 Mar 2020 at 21:08, John Doe wrote: > > Stereo and I have been working on a schema that makes it easier to create > and maintain public transport route relations. We would like to invite > feedback, questions, and suggestions, so it can mature and hopefully gain > widespread use. > > > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations > > > > ___ > 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] Feature Proposal - RFC - Public Transport v3
Stereo and I have been working on a schema that makes it easier to create and maintain public transport route relations. We would like to invite feedback, questions, and suggestions, so it can mature and hopefully gain widespread use. https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles
On 6/3/20 7:28 pm, Peter Elderson wrote:
To circle back to my question, I would not use something like
"detached" for a trail like The North Trail, because it still is one
trail and you would probably want to have the option to export it as a
whole, and to see the height profile (with gaps but still useful) and
total length calculation.
Umm "detached" is not quite right? Umm
Noncontinuous, discontinuous, fragmented, disconnected ???
In any event the present system will show it as that, even without any
special roles. The problem is that mappers seeing it may think that it
lacks members to make it continuous.
For my collection of island loops that does not make much sense I
think. The same goes for the "bonus" loops of some of the other
longish trails, hikers do not see those as part of the main route.
Still, they carry the same name (verifiable by survey, symbol and
operator, are described in the same paper guide and web site, and are
maintained by the operator (" path group") as part of that
trail, so on a map of this trail users will want to see it.
So, I create a separate relation for the detached loop, and I want to
include that as a member in the parent route relation next to the main
route and all the variants. Then I would like a role to indicate
"render this like the main route, but exclude it from length
calculation, elevation graph and gpx/kml-export".
Otherwise I would probably assign the role "excursion" even though it
is not attached to the main trail. A renderer could well decide to
render excursion same as main, while excluding the excursions from the
exports and calculations.
To me both 'excursion' and 'bonus' loops would be "alternatives".
Best, Peter Elderson
Op vr 6 mrt. 2020 om 06:23 schreef Jmapb >:
On 3/5/2020 9:27 AM, Peter Elderson wrote:
Do you know trails with detached sections? We have some in
Nederland, on the islands. Doesn't fit in the proposed role
scheme, I think.
Vr gr Peter Elderson
See this section of the E10 in Czechia (
https://www.openstreetmap.org/relation/5465693 ) -- there's no
connection between these three sections of trail, and I don't know
if there ever will be. I think the E* European long-distance
trails have a lot of these discontiguous sections.
In the USA I know of the North Country Trail, which is very
incompletely mapped in OSM (
https://www.openstreetmap.org/relation/8808051 ). Much of it is
made up of other trails. Unlike other long-distance trails, the
North Country Trail doesn't claim to be contiguous on a micro
level, and has hundreds of disjoined sections. It shares a lot of
physical trail with the Finger Lakes Trail in New York State, but
(by my understanding) in a conceptually different way: The Finger
Lakes Trail aims to be contiguous and will consider a half mile
(or much more in some cases) walk along a residential road between
two sections of wilderness to be part of the route. The North
Country Trail will include the sections of hiking trail through
both of the wilderness portions, but will not include the road
walk. When you step onto the road, you've left the North Country
Trail but you're still on the Finger Lakes Trail. Once you go back
into the woods, you're on both trails again.
Jason
___
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
Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles
To circle back to my question, I would not use something like "detached"
for a trail like The North Trail, because it still is one trail and
you would probably want to have the option to export it as a whole, and to
see the height profile (with gaps but still useful) and total length
calculation. For my collection of island loops that does not make much
sense I think. The same goes for the "bonus" loops of some of the other
longish trails, hikers do not see those as part of the main route. Still,
they carry the same name (verifiable by survey, symbol and operator, are
described in the same paper guide and web site, and are maintained by the
operator (" path group") as part of that trail, so on a map of
this trail users will want to see it.
So, I create a separate relation for the detached loop, and I want to
include that as a member in the parent route relation next to the main
route and all the variants. Then I would like a role to indicate "render
this like the main route, but exclude it from length calculation, elevation
graph and gpx/kml-export".
Otherwise I would probably assign the role "excursion" even though it is
not attached to the main trail. A renderer could well decide to render
excursion same as main, while excluding the excursions from the exports and
calculations.
Best, Peter Elderson
Op vr 6 mrt. 2020 om 06:23 schreef Jmapb :
> On 3/5/2020 9:27 AM, Peter Elderson wrote:
>
> Do you know trails with detached sections? We have some in Nederland, on
> the islands. Doesn't fit in the proposed role scheme, I think.
>
> Vr gr Peter Elderson
>
> See this section of the E10 in Czechia (
> https://www.openstreetmap.org/relation/5465693 ) -- there's no connection
> between these three sections of trail, and I don't know if there ever will
> be. I think the E* European long-distance trails have a lot of these
> discontiguous
> sections.
>
> In the USA I know of the North Country Trail, which is very incompletely
> mapped in OSM ( https://www.openstreetmap.org/relation/8808051 ). Much of
> it is made up of other trails. Unlike other long-distance trails, the North
> Country Trail doesn't claim to be contiguous on a micro level, and has
> hundreds of disjoined sections. It shares a lot of physical trail with the
> Finger Lakes Trail in New York State, but (by my understanding) in a
> conceptually different way: The Finger Lakes Trail aims to be contiguous
> and will consider a half mile (or much more in some cases) walk along a
> residential road between two sections of wilderness to be part of the
> route. The North Country Trail will include the sections of hiking trail
> through both of the wilderness portions, but will not include the road
> walk. When you step onto the road, you've left the North Country Trail but
> you're still on the Finger Lakes Trail. Once you go back into the woods,
> you're on both trails again.
>
> Jason
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
