Some parts of Mapeak are open source and some are not, I’m not sure it’s relevant for this discussion.
Regarding the question about the license:
Mapeak allows content providers to publish their route collection in Mapeak. The license of these collections is decided by the content provider. For example the routes from 4x4.co.il that were recently added have the copyright of 4x4.co.il.
So every content provider is allowed to define the relevant license for their content.
From the OSM community perspective, we can agree that a specific user or a few users will manage these routes on their accounts and provide a permissive license.
I believe this will suffice the need of the community here. If this is not the case I’d like to know why and maybe find a way to solve this.
I’d like to emphasize here that the purpose of this thread, from my point of view, is not about publicizing Mapeak, but to find solution for a problem that was raised by our community.
If there’s a different way to do it that I’m not aware of, i.e. other platforms that can solve this, I’ll be happy to know and we can decide to use a different solution if the community can agree on/endorse it.
The thing is that your platform is simply irrelevant to this discussion. The only relevant thing is what is considered a trail that should be included in OSM. Adding content to OSM or removing a content from OSM is in the scope of this discussion. “Moving” them to a different platform or site is not.
I respectfully disagree. Without a proper solution for our community we will loose valuable editors and data. People have invested time and effort into adding this information. Just deleting this information does not serve our community well.
As I understood, part of why you made this post is to gather community feedback on what is missing for Mapeak adoption.
This makes the open source status very relevant. There is nothing wrong with making a commercial product! But to answer your question on what is missing, the OSM community has a strong openness ethos and what would still be missing for many community members to adopt this is it being a true FLOSS product.
Personally, I wish you the best of luck but I would feel hesitant to contribute data myself. When I volunteer, I want my resulting work to be as open and accessible as possible and I’ve been bitten before by volunteering to feed data to partly-open systems and be disappointed down the line.
If you want to maximize the chance of the adoption, especially globally and especially hardcore OSM users (who contribute the backbone), this is something to consider seriously.
I would really appreciate that you’d confirm/object that we’re not talking about the סינגלים I mentioned earlier as I have not been involved in the Telegram discussion. If you’re not touching those, I am ambivalent about the rest and have nothing further to add to the discussion.
I suspect that many of the cycle routes are more than just a mere “trip recommendation”. A singletrack often has verifiable on the ground features: From obvious things like ramps and technical obstacles added on purpose, to more subtle things like compacted dirt, methodical removal of problematic plants, rocks and grass, trimmed head-height branches, intentionally bermed corners to improve traction, and so on.
I would bet that two people who know what they are looking for would map many of these singles’ start/end exactly the same or pretty similarly, making them more or less answer the verifiability criteria.
So I think they are physical entities whether the operator is kkl, informal “pirates”, or even just the occasional riders who sometimes take initiative, and that makes them belong to OSM par excellence.
I typically mark them the way I mark Way: 280522491 | OpenStreetMap , but maybe a relation makes sense for longer ones. I am not necessarily advocating the specific tagging scheme used today. Just pondering if removal is justified.
In summary, I am inclined to believe that “trip recommendations” don’t belong on OSM, but that doesn’t mean all the operator-less cycle routes are trip recommendations. Some are physical features.
But I just want to clarify that I highly suspect some of those route relations in question are in fact physically on the ground and not mere trip recommendations.
In other words, they are essentially longer strips of what I usually tag with mtb:name.
So I think they do belong on OSM one way or another, even if not as relations or as a different kind of relations.
As far as I understood the facts you see on the grund are for highway=path+bicycle=yes/designated.
For bus route relations, there are bus stop signs with the route name or number that indicate a specific sequence of street & road segments as a route of that bus.
For hiking trail route relations there are trail marks that indicate a specific sequence of path and track segments as a route of that trail.
What facts on the ground are indicating a bicycle/MTB route relation?
Note that OSM does not use relations to “glue together” segments of a street. This is not the purpose of a route relaton.
Just to be sure we’re on the same page, are you implying the following?:
If there is an on-the-ground mtb track, no signage, and is currently marked as a route relation, then:
I should remove the relation, copy the name of the route relation to the mtb:name of all ways the route relation was composed of (so long as this is an mtb track known to the community and not a personal bookmark) and make sure highway=path + bicycle=yes/designated is there. This is similar to normal streets made of multiple ways.
If there is signage on the ground, then a route relation can stay.
(I think the formal vs informal operator distinction is irrelevant and was mistakenly bolted in)
Although different from the approach proposed in the OSM Israel channel, this proposal is complaint with OSM guidelines.
There are pros and cons for both proposals. Specifically, this proposal does not capture the order of the segments in the route or the “riding direction”.
@zstadler what is the alternative approach proposed in the Telegram channel? Although I followed this thread I am not sure I understand the concrete proposal fully.
Also: There’s a small side-thought that’s been bugging me and I wonder if it needlessly complicates the discussion or if it’s relevant to it.
highway=path + bicycle=yes/designated simply means that a bicycle can pass there.
mtb:name makes a more powerful statement though not with 100% certainty: this is likely a maintained singletrack, someone (official operator/non-official/some of the riders themselves) physically takes care of it occasionally. Sometimes people ride with a hoe or some other tool on their backs and fix up problematic sections! There is likely on the ground evidence of the maintenance (berms, branches out of the way, etc as I described before).
The route relation is an alternative way to make the mtb:name statement.
It feels like mtb:name is a bit overloaded. It carries the name and some other detail, and there’s no osm-compliant way to mark a nameless yet maintained singletrack.
In practice, if I am in an area, I am more likely to check out the ways with an mtb:name or with a relation first as they’re likely more high quality than a mere highway=path + bicycle=yes/designated. I think this data should be preserved no matter the proposal.
For my Australian bushwalking website beyondtracks.com, I created beyondtracks / beyondtracks-walks · GitLab as a repository of suggested walking routes. Signposted routes are still best stored in OSM, but having an external repository for editorialised routes is necessary.
The since the route geometries are derived from OSM data, the collection of routes are licensed ODbL. I opted to use the .osm format and a dedicated tagging schema to organise the routes data.
That’s a very interesting approach to this problem. Although it might not be convenient to query this information, all the data is there and one could spin up a service that can read and serve this data, so from a data storing perspective, this is a great solution.
If I were to contribute data to this repo, how would I track the ID on my system? I did not see a mention of ID stuff in that repo?
Another question is about photos. Currently the link is to flickr user and ID, is it possible to use other image links?
I see that the repo wasn’t updated for some time now, can you clarify why?
I can move this conversation to the repo if this is too technical for this thread.
@zstadler and I had a personal correspondence to try and figure out why we’re not fully in sync and we’ve made progress.
My personal conclusion is that there are 3 types of mtb-related data currently in OSM:
1, Route relations which encode signed, formally maintained routes. This data belongs on OSM.
2. Route relations encoding trip recommendations. This data does not belong on OSM.
3. mtb singletracks.
They are physically different from a simple bicycle-accessible path thanks to regular ground maintenance by a formal/informal operator. This has nothing to do with signs and more about the ground truth of the path itself. (see addendum 1 for details)
Singletracks are sometimes encoded as mtb:nameon the way segments. This data belongs on OSM.
I highly suspect singletracks are sometimes encoded as a route relation. Particularly by @Tsur_Halamish , but this needs verification. This data belongs on OSM but (I think) not as a route relation.
They are often much more enjoyable to ride than plain highway=path + bicycle=yes and seeing them differently on a map is very useful. IIRC On IHM this currently shows as a clickable flag in the POI layer whether tagged as an mtb:name or a relation.
With this distinction in mind, I do not oppose new stricter criteria for routes (e.g. signs + maintained by an operator), as long as routes which do not meet this criteria are not blanket deleted and are inspected on a case-by-case basis:
If they do not meet the criteria, they can be deleted from OSM.
If some/all of their segments are mtb singletracks, that data should be transferred to all relevant segments, by adding mtb:name. Whether the operator is formal or informal is irrelevant.
Regarding moving the trip recommendations to some other platform, I am ambivalent and my opinion on non-open options has already been expressed in a previous post.
Addendum 1 - what is a singletrack’s ground truth
An mtb singletrack is a routinely maintained path with mtb bicycles in mind and it often has a name. The maintainer is either formal or informal. The maintenance makes it acquire some distinct on the ground features. They gradually revert back to just regular paths if unmaintained. Because they are physical on-the-ground things, mapping them is legitimate whether the operator is formal or not and whether signs exist or not.
Mapping them isn’t just “academic”. It’s extremely useful for an mtb cycler to see them standing out on a map compared to regular paths.
Here is a list of distinct on-the-ground features. I possibly missed some.
Berms built on the sharp corners to help the bicycle wheels grip them better, or to make it safer when there is a cliff or a sharp decline right after the corner. Here is a photo of what I mean:
Artificial technical obstacles placed along the path (e.g. logs, ramps).
small sections of dirt arranged for “pumping” - Wobbly height that is technically interesting. (If the track is fully dedicated for pumping it’s called a pumptrack).
The path is intentionally made to go over natural obstacles like rocks.
Problematic objects routinely removed. E.g. branches that get in the way of your head, loose rocks.
Compact dirt and very little grass growth because of the number of bicycles passing there.
Narrow passage
Addendum 2 - Verifiability
Singletracks’ ground truth has the same verifiability caveat as intermittent streams: On one end of the spectrum you have features which are very clearly intermittent streams and on the other end you have clear cut dry land but there is some gray area in the middle.
But I think many cases aren’t in the gray area and I think many cyclers would more or less tag them the same because you know it when you see it.
The mtb:name tag is a little overloaded. It is a name but it implies something about the path arrangement. This creates an awkward situation where it’s hard to tag a nameless singletracks. The proposedhighway=pathpath=mtb tag solves that, but it’s not widely used.
The approach above regarding transferring route-encoded singletracks to mtb:name encoded singletracks has some caveats. Mainly: longer singletracks segments are often not fully continuous and have some highway=track in between. e.g. see w1306999986. A route allows for the highway=track to take a part while my mtb:name proposal would create a split.
This might be OK, as being a singletrack is a physical feature of the segments but not of the highway=track.
Alternatives could be:
a new kind of route-like relation
a tag on the route indicating some sort of distinction between it and a proper signed route.
But we’re bordering on trip recommendations here and maybe this creates a verifiability mess again. I am not sure.
Making sane allowances and tagging those small highway=track sections with the mtb:name if there’s an mtb track of the same name on both sides of that highway=track.
In some places like the Yaran each small segment has a different name so the split is fine and people don’t think of them as the same singletrack even when riding one after the other. e.g. w280522491 and w124839757.
Do you think my proposed solution of putting those in mtb:name of relevant segments is good enough for those pirated routes that lack a sign? They unquestionably exist on the ground and so that’s very much in line with OSM guidelines.
This can also be encoded on the segment with oneway:bicycle=yes/no and the direction of the segment. Also, since informal singletracks have no signs, the riding direction is sometimes not specified.
Route relations which encode signed, formally maintained routes. This data belongs on OSM.
Route relations encoding trip recommendations. This data does not belong on OSM.
mtb singletracks.
