Is the "orange line" immutable?

Vaguely following on from my still-unsolved relation duplication problem, I came up with a different attempt to differentiate allowed usage within the one relation. For a stretch where bicycles aren’t allowed, I want to illustrate an alternate way to go around it on local roads. Since nodes can also be in a relation along with ways, why not try to make kind of a “dotted line” to just show the alternate? Problem is, when you view a given relation in the generic web view, the “dots” I wanted show up as big circles, which get (relatively) even bigger when zooming out. If I zoom out far enough, these all collapse into one big ugly orange blob. The way lines are fine, the dots are visually highlighted in a way that sort of makes this not work as intended.

Is there any way to modify the default web view? When other services like Alltrails and Gaia render stuff like this, they do a lot more visually to represent usage types and other data. I want people to be able to find the info directly in Open Streetmap and have it directly usable.

What you’re looking at there is just the default view of a certain geometry (a relation with some ways and some nodes) on osm.org.

You certainly could display it differently, in a way more sensitive to the data you’re showing, but you’d have to create that view yourself. There are various ways of doing that. The easiest is probably uMap (an online service run by openstreetmap.fr), but there are more complicated options too, such as designing a complete map style yourself (something the online sites you mention probably do).

Are you (mis-)using nodes to paint a dotted line on the map in the osm.org geometry preview? :face_with_raised_eyebrow:

Please revert that and fix the relation so it’s aligned with the bicycle route tagging scheme.
Like SomeoneElse already said, the geometry preview on openstreetmap.org is not suitable for your purposes. The openstreetmap.org website is primarily intended for mappers, not as a service to display customizable map overlays for non OSM users.

Either use the proper route tagging schemes and a specialized website that shows routes based on OSM data like e.g. https://cycling.waymarkedtrails.org, or don’t add the data in the OSM database in the first place and simply show it as an overlay on e.g. uMap instead.


Route relations in OSM also need to satisfy verifiability requirements. If this is a route that’s not either signposted on the ground or already well known among a large group of (unrelated) people, it should not be added to OSM.
OSM isn’t the right place for personal routes or routes created by private organizations that do not have a (semi-official) mandate or influence to declare public cycle routes (like e.g. tourist boards or cycling associations).

I created Note: 5284272 | OpenStreetMap so cleanup will not be forgotten

Tagging for the renderer - OpenStreetMap Wiki describes why not (if you mean adding nodes intended to render in a specific way, instead of standard ways of mapping alternate signed variants)

I want to illustrate an alternate way to go around it on local roads

is it signed? Or is it your personal suggestion?

Is there any way to modify the default web view?

no, it is a debug view - not a customizable service

If I wanted to point people to a hiking or cycling route relation to be used in a web browser, I would point them to waymarkedtrails.org which has already been mentioned. Unlike the main website and standard renderer, it is designed for this type of information, and can give useful additional information such as elevation profiles.

I also find waymarkedtrails useful to check I have mapped relations sensibly. I’m not talking here about mapping things artificially so they look nice on that site, rather confirming that I have followed standard mapping practice in a way that a specialised route renderer can interpret correctly.

As others have said, this assumes you are mapping a verifiable route. To illustrate a personal suggestion something like umap would be better.

Edit: change waymarkedtrails.com (which is something else) to waymarkedtrails.org (which is what people have mentioned above).

What is currently in OSM is a name=Mystic Link Trail; route=foot; type=route. It sounds like what you actually want to do is to create at least two routes, one on foot and one for bicycles, but have those relations share significant sections.

Sometimes an example helps - here is a map of part of the Peddars Way in England:

There are three “Peddars Way” relations there, a hiking route, a horse route and an MTB route.

In each case the route tag is different (hiking, horse, mtb). There is some usage in taginfo of route tags with semicolons in, but they are not widely supported (just me I think).

On the subject of nodes and ways within routes - that is something that people within OSM do, but the nodes have to be something verifiable; for example this one is a guidepost on a couple of relations.

With regard to “more complicated” routes generally, I’d definitely suggest having a look at the author of “Waymarked Trails”’ talk at SOTM EU last year - video here.

Well, “waymarkedtrails.com” redirects to some for-pay thing called “hiiker.app”, which is not useful.

Look: we are a small group trying to define a knowable sequence of green spaces and less-busy roads to explore between Boston MA US and various park destinations north of there, similar to how the well-established Bay Circuit trail is a big relation that links up *many* open-space components encircling the Boston area like part of a wheel. We’re essentially working on one of the north-south “spokes” of same, and if our work-product is going to show up in other facilities like AllTrails we have to have *something* defined in Open Streetmap as that’s also the backend they use. It is only a single relation at this point, it’s not destroying anything on the underlying map, and nobody will even be able to find it until it’s officially linked on our website in some form or other. The point is to get the appropriate data laid out *without* having to tediously add a bunch of duplicate ways, which would be stupid. There are plenty of relations (and super-relations, I’ll point out) like these that “piggyback” off what’s already there, even if what’s already there is kind of sketchy in the first place.

We’ve also had to re-think and modify the route a bit over time, based on real-life evaluation of which components make the most sense for our purpose and keep people safe while exploring them. That’s why there might be a few off-route chunks still kicking around – I’ll get to those, I only have so many hours in the day.

Maybe we’re not quite as “verifiable” as the Bay Circuit yet, but we ARE working on that and for anyone to denigrate those efforts and advocate simply trashing the whole thing is just rude. Check our website, really. We even have one of the original founders of the Bay Circuit on our little committee, who busted his butt many years ago getting permission to install physical markers across various towns and parks and pushing for general open-space preservation at administrative levels.

The other “cloning” thread reflects intent to have two relations or some better solution, one for hiking and one for biking at a minimum, because there are some areas where bikes are prohibited and we want to accomodate both modes. So that’s why I started that thread, and I’ll comment on developments there in a bit.

Our relation, and its bicycle-mode clone if we ever manage to set that up, will get cleaned up over time as I work on it. I’m trying to do as little way-splitting as needed, although it is needed here and there for tiny sections of long roads and the like. I’m finding quite a few ways that simply don’t make sense in the process – and other mappers created those, it’s not MY fault. In the interim, I include them or skip them with the intent of going back and cleaning up the necessary components later.

So, WORK IN PROGRESS, please don’t bother commenting if you’re only going to be is antagonistic. We are a legitimate effort, but still finding our way, so to speak.

Well spotted! That was a typo in a post above. I’ve edited it.

:smiley:

Realistically, relations in OSM do need a bit of “gardening”, and it does make sense to strive to have routes as contiguous, because people will try and download them as GPX files onto some device and try and follow them. Yes, it is a lot of work at the outset but that’s because you’re trying to fix years of breakage at once.

I think that the comments above are all trying to be helpful. The language used around the world varies hugely in how much time they want to “pussyfoot around”** a statement rather than actually making it. People from parts of Europe are perhaps a little more direct than some people from the USA. Also, OSM is a shared project; nothing in it “belongs” to any one person. I posted the ra.osmsurround.org link in the other thread in the hope that someone - not necessarily you - might take it as a challenge…

** in their eyes

Thanks, I found waymarkedtrails.org now and see that it apparently just digs relations out of OSM and shows them. Yes, the Mystic Link still has a few issues, and fixing some number of them involves more modifications to the underlying data and possibly adding a new way or two – again, I’m loath to do much of that until I’ve got a “followable-enough” baseline in place with minimal gaps and stray ends.

Next question: my edits have obviously been all over the place, so there’s no specific “order” that could generate a single GPX that could take someone from one end to the other. How does that get done?? I didn’t think relations had any usefully defined order, they just exist as collections of pointers into the database. It’s weird that waymarkedtrails flags that at all.

Sorry about that, I had waymarkedtrails.org in my head but it somehow got autocompleted to .com

It depends on the type of relation. But for route relations (cycling and hiking trails and also public transport routes) it is common to keep the elements sorted (at least the way elements). See Order Matters, and also Elements of a Relation on the Hiking wiki page for concepts such as alternative branches.

Aside from potential advantages to users of the data, I find that is much easier to maintain a route if the ways are sorted in the first place. Route relations do get broken over time, usually unintentionally by mappers working on something completely different, and especially in or near populated areas where “stuff happens” - construction, changes to street layouts and so on. I find it much easier to identify and fix where things have gone wrong if the route was previously an ordered list of ways.

JOSM has some support for sorting - it can take a few iterations if there are gaps in the relation to start with, but I generally find it helpful. I don’t know about other editors, that is just the one I happen to use for this kind of thing.

It would be nice if iD had some way to drag elements around and reorder them. It looks like the only feasible way I have is to go through the entire relation end-to-end [after it’s fixed up] and add each member to a new relation alongside, and then have that new one be the “final” real deal. But then making changes midway later is going to be a PITA, and I anticipate that some changes will be needed.

If I download the XML for a given relation/route, does that always reflect its member order?

With iD, you can manually change order of the members in a relation. When modifying the relation, unroll the “Members” list on the left, then select/drag elements and drop. But I don’t know if you can do that for long relations.

And the easiest way to do this is with a mouse.
First (down)load the whole relation (click on a way that’s already added to the relation, in the relation view on the left side it should show the relation with a (down)load button next to the name. Click that.)
Second open the relation by clicking on the name.
Third in the member list drag the way you want to move to the right position, scroll at the same time with a mouse to the right place in the member list and drop the way there.

When hovering over a way in the list, it highlights the way in the editor so you can check if it’s sorted right.