Render bicycle=designated on highway=track

[cm8]

There has been a lot of fight and reversal / back-reversal on the type-classification of several tracks or cycleways (depending on usage / user and resp. view or understanding of the infrastructure, of course).

To quiet down some of those edit wars it may help, if the map would render tracks as usual (i. e. brown line) and in case bicycle=designated is also tagged, overlay the blue dotted pattern on the brown line. However, if only bicycle=yes is present, that pattern should not be rendered.

This way mappers can indicate that some track is 'designated' to be used as cycleway (also, but not exclusively, if this track is part of a cycling route).

It may also bring together those people that usually tag new recreational ways around lakes (e. g. former open lignite mines) as highway=cycleway, even though they are multi-purpose tracks to be used by agriculture/forestry and common public. The understandable argument has been that the primary usage (percentage) of recreational use outweighs seasonal agricultural or forestry use. Thus justifying highway=cycleway tagging when the physical properties tend to ask for highway=track tags.

If the map style had a way to render these multi-purpose tracks (in the fashion asked for above), this may nullify the arguments and thus reasoning to do flip-flop toggling of these tags over large time-frames.

Testing may need to be done if this combination works ok with all tracktype styles (i.e. from grade1 to grade5 and those tracks without tracktype tag).

IMHO, no attempt should be made to transport this, analogously, to foot=designated on highway=track, unless someone asks about this in a future (to be opened) ticket with separate reasons/examples.

[jeisenbe]

The combination of highway=track + bicycle=designated is used 24k times, which is a small percentage of the 20 million highway=track features: https://taginfo.openstreetmap.org/tags/highway=track#combinations

In comparions, foot=designated is used 48k times, about twice as often, on these features, and horse=designated is used 16k times.

[cm8]

But that's exactly the point, highway=track which are also designated ways for bicycles /are/ a small percentage of tracks.

What sense would it make to request this feature if almost all tracks would receive this rendering? It would be pointless, because a users can identify any brown line as appropriate for cycling. The percentage of tracks people can and should also use as designated cycleways /is/ a fraction of all tracks out there. So it is expected and perfectly fine, that this rendering will not be found evenly distributed in any place.

Expectation is that most tracks (as part of signed cycling routes) receive the tag and therefore the rendering, plus those tracks that have been planned with multi-purpose usage in mind (built as a consequence of open lignite mining re-cultivation is an example).

If you want to transport the idea for foot=designated and/or horse=designated combinations, that's fine with me. But to start with, I think doing cycleway combinations has most appreciation. Personally, if I see a track open to the public on the map, I'd think they are all good to hike/walk on (as a hiker I would be more interested if the surface is water-bound or not to decide, based on wheather conditions which path suits my interest). There may be good reasons to do dedicated rendering for foot=designated I have not thought of, but I still think that change can come progressively and does not have to show up for all types at once. Stuttering this, testing, waiting for feedback is easier as well, imho.

[cm8]

Of course, you may also take into account that tag combination may increase, if its rendered (not saying that i support this correlation).

[cm8]

mockup - please have a look at the middle segment on the right side (left side shows status quo):

it may not be easy to get this right for tracktypes other than grade1 though:

• because they are built on dashing themselves, .. if the dashing offset is wrong, a grade3 track may either look like a grade1 track (gaps filled blue) or like a cycleway (brown dashes overdrawn by blue dashes)
• it may suffice if the overlay is done only for highway=track + tracktype=grade1 + bicycle=designated combination, as grade2 to grade5 tracks rather imply bicycle=yes tag (saying it may be nice to have it for all combinations, but if finding good dashing patterns results in a mess, grade2 to grade5 combinations are not a priority)

[jeisenbe]

Your example shows a potential problem: it looks like a highway=cycleway has been overlapped on top of a highway=track way in the database.

[imagico]

The idea in general seems to be worth considering but as @jeisenbe already said the design proposal is not going to work.

Also keep in mind that in a way we have a poorly defined tagging system with some gaps in this field. A track is according to the wiki a road primarily used for agriculture/forestry purposes. Many 'tracks' with bicycle=designated will be primarily (i.e. more frequently) used by bikes and accordingly would be incorrectly tagged as tracks. Yet this is of course common practice and we lack established tagging for a cycle path that functions and is suitable also as an agricultural/forestry road. We need to be careful not to state to mappers that a certain tagging is correct when there is no consensus in the community that it is.

[polarbearing]

I think it is hard for this style to show fine-grained permissions for each traffic class. A style dedicated to one particular traffic class, such as the various cycle maps we have, would be more suitable.

[cm8]

Your example shows a potential problem: it looks like a highway=cycleway has been overlapped on top of a highway=track way in the database.

This is a validating issue, not a rendering one.

From a semantic point of view this can indeed be considered equal in meaning. From a user perspective this is not a problem at all, two different data representations that result in equal rendering - ok, why not?

Of course, /if/ it is

• considered poor tagging/mapping practice or
• undefined which way gets rendered first of the overlapping pair

.. the wiki should point out the preferred mapping practice and validators should raise an error for the overlapping ways case.

It is not a good argument to avoid some rendering, because bad/erroneous/sloppy mapping could theoretically give the same result. OSM has dedicated validating tools (online and offline), so the standard carto style strictly does not need to provide ways to identify bad/discouraged mapping practice.

Of course, aside from that, if you find a better style expressing the same, there'd be no objection to use a different rendering (but please, not for the argument raised above).

If @imagico has success with #4322 in abolishing tracktype rendering (which has my support if unpaved/paved is considered instead), it may ease implementation of this issue, because the dashing conflict may resolve. However, a lot of people have grown accustomed to the tracktype interpretation/rendering and read the 6 class system conveniently.

Lots of people visit openstreetmap for the added detail, because the simple non-discriminating variants can very well be found on all commercial maps.

[jeisenbe]

Re: "the standard carto style strictly does not need to provide ways to identify bad/discouraged mapping practice.”

Please see https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md -

"This style has multiple purposes: "It's an important feedback mechanism for mappers to validate their edits...”

This is listed first among 4 main purposes. And among the main goals we have:

"Being understandable and supportive for mappers - To serve as feedback for mappers and encourage correct mapping this style needs to render the data in a way that allows mappers to understand how the data produces a certain rendering result based on basic observation without in depth understanding how map rendering works or looking at the style implementation.”

We often refer to this as providing “mapper feedback”, therefore the rendering should make it clear which tags were used and what geometry results in the rendering.

For these reason it would be against our design goals to create a style where a single way with highway=track + bicycle=designated was rendered the same as two overlapping ways, one with highway=track and the other with highway=cycleway.

[cm8]

I still think you are actively constructing this collision. The intention of giving a feedback to mappers regarding the tag combination is as of now non-existent (highway=track + bicycle=designated is not rendered, therefore no mapper feedback).

On the contrary you object giving this feedback by constructing invalid data and suggest this invalid data would render in the same way.

CARTOGRAPHY.md relates to data consented upon or de-facto mapping styles, it does not advocate that any mapping style should be conflict-free with hypothetic/malicious data, entered by incidence or on purpose to exploit such rendering collisions.

If I follow your argument, e. g. landuse=railway and landuse=industrial is in conflict with the intentions of CARTOGRAPHY.md as well, because if I 'wrongly' draw a polygon around an industrial area and tag that as landuse=railway, the rendering will be just about the same. And it will not give me any feedback as a mapper that something is wrong with the data.

For this reason I insist on the map style not being a general purpose validator for each and every pitfall. True, it can and should be used for mapper's feedback, but it's (by far) not a complete all-in-one error detection tool you claim it should be (and it does not have to).

[jeisenbe]

The risk your rendering suggestion is that mappers might see this rendering and wrongly guess that it is created by overlapping highway=track and highway=cycleway ways, and therefore think that they should map features in that way. If they see the same rendering result, they will then false assume that they are mapping in a standard way.

In contrast, if someone maps landuse=railway and landuse=industrial areas which are identical in shape, the rendering is not changed, so there is no suggestion that this is a preferred rendering.

[cm8]

I get your point, but wouldn't a mapper simply look at the data to see how it's done and then take and copy from there. Simply guessing mapping practice from seeing a rendered feature on the slippy map? Is this an issue, .. really?

Also, consider that the blue dashing of cycleways uses a white background halo. If you omit that when combining blue dashing with the brownish tracks, you'll probably even get a distinguish-ability to some extend.

[cm8]

You could also use either a darker blue, or change spacing or segment length of the dashes, if it absolutely needs to be different from the standard cycleway style for the reasons you've mentioned. Maybe they are an issue, I just haven't observed something like you've described.

[hungerburg]

Around my area of mapping, there are lots of tracks that serve as officially designated mountain-bike trails. They all have "highway=track;bicycle=yes", in MTB maps they are highlighted, due to the relations built on them. There is an avid MTB cabal around, yet they never questioned the markup (from browsing the history of the ways). Perhaps it is a different culture, here "designated" can only be applied, if there is the well known blue circle sign besides the way, which would then prohibit use by agriculture etc. if not explicitly signed otherwise.

The paper maps of a popular publisher's draw those as a two-colored (white+green) line, which makes it look like there was a cycling-lane on the track. A track where a hiking and a biking trail go thus looks like the flag of Italy (red=hiking, white=track, green=cycling). Quite helpful. Could be used in OSM for "cycleway=lane" too! (Would be blue then.) Might just as well be used for pedestrian lanes too (a.k.a. sidewalks)! (Not sure about the colour to use.)

Update: Sample picture https://www.almenrausch.at/fileadmin/userdaten/bilder/wanderungen/tirol/innsbruck-feriendoerfer/hoettingeralm-planoetzenhof/karte.jpg

[cm8]

Perhaps it is a different culture, here "designated" can only be applied, if there is the well known blue circle sign besides the way, which would then prohibit use by agriculture etc. if not explicitly signed otherwise.

This setting has been mapped by bicycle=official or, more common, highway=cycleway which implies bicycle=official - unfortunately this specific difference has gently been wiped away by wiki editors that either never understood this difference or peculiarly did not want to understand it (for convenience).

Because of this and in consequence the wiki has proclaimed or wrongly implied that "designated" value is the same as "official" and the latter therefore has no use. However, this is/becomes only true, if you recognize the presence of "traffic_sign=*" as an indicator whether "designated" is indeed to be interpreted as "official", case by case. Historically, "designated" has a broader range of use cases than "official". Recognizing "traffic_sign=*" you could in theory live without an official/designated value distinction, because you can deduct "official" by the presence of "traffic_sign=*" tags.

The main problem with relying on "traffic_sign=*" is: What do you do if the tag is absent? If mappers do not tag "traffic_sign=*" or/and are unaware of the implications of omitting it, a data user is unable to tell if "designated" was chosen because of official sign presence or for another reason.

In other words: If "designated" were only to be used for "blue circle sign" cases, you would not need it at all, because "blue circle sign" cases are directly mapped to "highway=cycleway" (, unless maybe for segregated foot/bicycle paths).

[hungerburg]

As you say, "designated" here is rare, as those ways were mapped as cycleways from the start. No one here uses "official". One more thing that cannot be the source of confusion, I'd say.

Back on topic: Rendering bicycle-designation-acces-etc. on tracks as a line alongside the track, not over it, can this work? The underlying graphics engine must support borders on lines. SVG does not. Can OSM Carto do it?

That is, treat it like a "lane" - will be a "shared_lane" in this case, a value that exists for cycleway: Different stipple indicate different values… Still lots of things to work out, while not making it overly complicated. But maybe also a start to unhide cycle-lanes on other kinds of highway and thereby furthering the number one goal of the standard map - to give mappers feedback for QA.

[Adamant36]

"Back on topic: Rendering bicycle-designation-acces-etc. on tracks as a line alongside the track, not over it, can this work? The underlying graphics engine must support borders on lines. SVG does not. Can OSM Carto do it?"

IMO not in an understandable way. Since it would be to easy to confuse as rendering for one street parking or sidewalks. Anyway, its not like the specific cycle maps can't be used for mapper feedback. I use Open Infrastructure Map as feedback when I'm mapping power poles all the time. So the main map rendering them isn't really necessary (although I'm aware it does, but that's not my point). I'd say the same thing for cycle ways. In a lot of cases it doesn't need to render things that are already rendered fine and can be used as mapper feedback by other maps.

[cm8]

But maybe also a start to unhide cycle-lanes on other kinds of highway and thereby furthering the number one goal of the standard map - to give mappers feedback for QA.

+1 I would be in favor of also indicating cycleway lanes by adjusting encasing line color, but it is not the topic of this issue. Maybe open another one for that, it may have more implications not obvious at the moment (it also increases visual entropy and the map may appear untidy if applied to/in lower zoomlevels to early).

I'm not in favor of pushing the rendering of general tags away to dedicated maps. Ok, yes, for cycle routes such a request does make sense, but not for basic street features.

The name OpenStreetMap (as used in project title and domain name) indicates that the information provided centers around street infrastructure. I'd understand arguments to 'outsource' rendering of pipeline, powerlines, lots of natural features to dedicated maps (if they distort a general purpose map), but the basic modes of transportation (foot, bikeriding, car, rail) and how a street of interest provides for these modes should be readable, imho.

While the map currently achieves this goal with separately mapped ways (horsetrails, bikeways, footways, highways, etc.) it is in particular not very helpful in answering questions like (which streets have sidewalks? or which streets have cycling lanes? - information that is often present in additional tags on existing geometry representing some "main" object). I don't urge anyone to move forward fastly on improving this - just assessing the state rendering is in. Color-coding encasing lines may look alluring at first sight, but may not be an ideal over-all solution to render that information, because it can add noise (compared to current rendering), especially in low map zoom levels.

One way to go forward on this aforementioned QA goal may be to concentrate efforts on the two highest zoom levels only and implement encasing coloring there (way density may be low enough at these zoom levels as to not introduce too much noise). If that matures, gradually move towards the lower zoom levels.

---

If we are to replace the blue dots on brownish tracks with an encasing solution that probably won't do the job of resolving this ticket, because the encasing encoding may be mistaken for a track that has marked cycle lane(s) on them. We'd just have another QA conflict where a rendering may also result in assumption of two different data mappings.

[hungerburg]

I suppose the participants in this thread are all in the know, still I'd like to add some pictures of" OTG truth": There are many ways to map cycleways, most prominently, "highway=cycleway" and "highway=path"+"bicycle=designated". The second method has got a twist: What makes the cycleway? Is it the "path", is it the "designated" or is it the combination? Here two pictures:

A "green" "cycleway" on a track

A couple hundred meters away it splits into two, the "track" mapped as a "cycleway" turns into a "footway" Note: the ordering recently got reversed by the municipality, cyclists seem to do fine, while pedestrians rather dislike the swap.

PS: In this region, shared bicycle and pedestrian ways numbers are not in the ballpark of what taginfo posted above suggests, c.f. https://overpass-turbo.eu/s/171G - it is a mix much more even.

PS2: As far as I can tell, large regions in the world, notably the USA, do not know "blue" cycleways, which are common in Europe and get special legislation. The blue colour used in OSM-Carto looks a Europism, Americans from the Eastcoast perhaps would have chosen green?