Modify

Opened 18 months ago

Closed 17 months ago

Last modified 17 months ago

#17307 closed defect (wontfix)

Cycleways map paint style emphasizes cycleway=lane more than cycleway=track

Reported by: Doug Owned by: cmuelle8
Priority: normal Milestone:
Component: External mappaint style Version:
Keywords: template_report Cc:

Description

Minor thing, but a track is per the wiki a more substantial infrastructure divided from both the main road surface and the sidewalks. The colorizing for cycleway=track is so faint as to be difficult to even notice. If tracks are actually better is complicated and depends, but that's a whole other discussion.

By the way, your ticket instructions say that email addresses inserted when not using an account aren't shown, but everything up to the @ is actually shown if entering it in the "Your email or unsername" box. It's probably better to make that more clear to avoid misunderstanding.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-02-02 21:01:18 +0100 (Sat, 02 Feb 2019)
Build-Date:2019-02-04 21:50:11
Revision:14760
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14760 en) Windows 10 64-Bit
OS Build number: Windows 10 Enterprise 1803 (17134)
Memory Usage: 856 MB / 989 MB (126 MB allocated, but free)
Java version: 1.8.0_201-b09, Oracle Corporation, Java HotSpot(TM) Client VM
Screen: \Display0 2560x1440, \Display1 1920x1080
Maximum Screen Size: 2560x1440
Dataset consistency test: No problems found

Plugins:
+ Mapillary (v1.5.17)
+ apache-commons (34506)
+ apache-http (34632)
+ imagery_offset_db (34867)
+ jna (34867)
+ todo (30306)
+ turnrestrictions (34867)

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/SlovakiaBicycleRoutes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&zip=1
- https://raw.githubusercontent.com/yopaseopor/traffic_signs_style_JOSM/master/Styles_Traffic_signs_AME.zip

Last errors/warnings:
- W: Unable to convert property left-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property right-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property left-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property right-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property left-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property right-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property left-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property right-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property left-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!
- W: Unable to convert property right-casing-offset to type class java.lang.Float: found RelativeFloat{val=4.0} of type class org.openstreetmap.josm.gui.mappaint.mapcss.Instruction$RelativeFloat!

Attachments (1)

track-lane.png (144.4 KB) - added by Doug 18 months ago.
violet way in lower left is a cycleway=track. Double bold blue way on the right is a cycleway=lane. You can find these live just south of the Fort d'Ivry in Paris.

Download all attachments as: .zip

Change History (88)

comment:1 Changed 18 months ago by Klumbumbus

Component: CoreExternal mappaint style

Please add a screenshot. I think you are talking about the rendering with enabled Cycleways mappaint style!?

comment:2 Changed 18 months ago by Doug

Yes, I'm talking about when the cycleways paint style is enabled, as the subject implies.

comment:3 Changed 18 months ago by Klumbumbus

OK, I thought with "Cycleways mappaint style" you meant the mappaint style (i.e. styling) of the internal mappaint style.

comment:4 Changed 18 months ago by Klumbumbus

Owner: changed from team to cmuelle8

Changed 18 months ago by Doug

Attachment: track-lane.png added

violet way in lower left is a cycleway=track. Double bold blue way on the right is a cycleway=lane. You can find these live just south of the Fort d'Ivry in Paris.

comment:5 Changed 18 months ago by Doug

I attached the requested screenshot.

I'm confused. I only know one cycleways map paint style. It's turned on under View->Map paint styles->Cycleways.

I have noticed that if cycleway:right=lane is used the behavior is quite different. As I recall then both appear non-bold. I have not tried with cycleway:both. These are just using cycleway=lane and cycleway=track.

comment:6 Changed 18 months ago by anonymous

This is an old map paint style that you do not need to use, if you do not like it.

Remember that you can always edit and use your own map paint styles.

You can even change the style in question online, or put up a revised one with a similar name.

I do not consider this a bug. It's a style I've created to emphasize cycling infrastructure with dense cities in mind and it works well in my area. It was created before the default map paint style learned to colour cycling infra tags, iirc.

If you turn that map style off, you should still see cycling infrastructure, as emphasized and coloured by the default (internal) styling preset.

Greetings

comment:7 Changed 18 months ago by anonymous

You can also browse the history of this style btw

comment:8 Changed 18 months ago by anonymous

If you want to stick with this style and modify it, try to play around with the casing-width attributes.

Or remove the relevant lane styles alltogether if you do not care for cycling lanes.

If you need a reference, because you don't understand the MapCSS syntax yet,
you can take a look at Styles/MapCSSImplementation.

comment:9 Changed 18 months ago by Doug

Of course it's free software. Nobody is required to fix anything or use anything. I'm just reporting the issue. Personally I find "internal" styling barely visible, but obviously perceptions and/or equipment differ.

All the best,
Doug

comment:10 Changed 18 months ago by Doug

Also I meant to say thanks for the advice and tips on creating personalized styles. That could be useful. Regarding removing lane styles, actually, the lane styles, at least when used with a non-qualified cycleway are the ones I like. With left right or both is another matter and also an odd inconsistency. The track style is too hard to see when zoomed out on a large busy region, for me anyway.

I can appreciate if the styles were just collected on an as-might-be-useful basis. Sometimes adding more just creates more complaints, right?

comment:11 Changed 18 months ago by anonymous

You're very welcome to improve consistency of the style.

If you want my ok before overwriting the instance of the cycleway style available online,
then you can post screenshots to this ticket. I will review and comment them, if you like.

But again, you do not strictly need my consent to overwrite the style available online.
If you know what you're doing and have a strong feeling about a fix, then just post it.

In case there's something severly bad with it, you or i can always revert it at a later time.

As I have not worked on it for a rather long time, I have no hard feelings about you changing it.

Just make sure to test it with a couple of different areas (i.e. compare rural / urban).

Rule of thumb:

  • If it looks completely different, it may make sense to add as new cycleway style.
  • If it fixes minor or consistency issues then overwriting the existing version is no problem.

comment:12 Changed 17 months ago by Doug

Ok, I'm having a look at it.

I notice that aside from what I mentioned, cycleway=lane is, as it seemed, not treated the same as cycleway:both=lane.
The only documented difference that I can find in the wiki is that cycleway=lane implies only one lane (on unknown side) on a one-way street, as indicated in discussion of this "bug":
https://josm.openstreetmap.de/ticket/15512

there are no exceptions for oneways handled.

As this is for an editor and not a general purpose map renderer, I'm inclined to agree with not doing anything special in the oneway case because it makes it harder to know how it's tagged, even though I disagree that tagging cycleway=* on a oneway is wrong, but that becomes moot.

With the exception of one-ways, I think the two tags should render the same, so I'll see about that too.

comment:13 Changed 17 months ago by anonymous

I'm coming around to the idea of correctly rendering the cycleway=lane, oneway=yes as well actually. No rendering method will tell the user exactly how it's tagged. Better to just show the correct interpretation of the tag to reinforce how to use and understand the tag. The difficulty though with oneway and cycleway=* is that to really get it right, we have to know which side of the road people drive on, and I don't even know if it's possible for the paint style to get access to that information.

comment:14 Changed 17 months ago by anonymous

cycleway=* is almost _completely_ unrelated to oneway=*

  • the cycleway:left and cycleway:right keys depend on the direction of the way ("dotw", as given by the node order of the way list)
  • oneway=* encodes whether general traffic flows in one direction only (cars, hgv, and _maybe_ bicycles too, if there are no dedicated lane markings), together with
    • cycleway=opposite (road is open for bicyclists in opposite direction (too)) it effectively means the oneway=* condition does not apply to bicycle mode of traffic
    • cycleway=opposite_lane (a lane only allows cycling in opposite direction of the oneway) it effectively means the oneway=* condition is reversed for the lane; but it gives no info on which side of the way that lane actually is or if it eventually refers to both lanes should two lanes be physically present

The 'opposite' based values are kind of legacy, they're very old and kept for compatibility. They are not needed if cycleway:{left,right,both}=* are solely used together with cycleway:{left,right,both}:oneway=* - the latter key(s) of which do not interfer _at all_ with oneway=*.

Interpreting the legacy values 'opposite' and 'opposite_lane' are to my knowledge the only cases where evaluation of another attribute (oneway=*) is a prerequisite to compute resulting physical direction. However, this does not make statements about computing inherited defaults in case of omitted keys although, which may be implementation dependent.

To get anything *oneway=* related correct, programmers or style authors need to account for the ternary nature of the value (-1, 0, 1) which roughly translates to (oneway flow in opposite of "dotw", flow in both directions, oneway flow in "dotw"), but better see the osm wiki documentation for authoritative info.

Greetings

comment:15 Changed 17 months ago by anonymous

from the Twiki:

https://wiki.openstreetmap.org/wiki/Key:cycleway

"cycleway=lane is used to tag two-way streets where there are cycle lanes on both sides of the road, or one-way streets where there is a lane operating in the direction of main traffic flow."

This is what I was referring to. So cycleway=lane and oneway=yes implies "there is a lane operating in the direction of main traffic flow."

as opposed to cycleway=lane on a two way where "there are cycle lanes on both sides of the road"

Anyway, I'm learning, found the :righthandtraffic tag, but more importantly found where the default paint style already parses many of these issues. I started to write something and found it basically does it all already. So I'm considering making something by merging the logic there with the styles in the cycleways paint scheme, to basically have a similar look, but more consistent logic.

I've noticed that the cycleways paint is calling cycleway=* "weakinfo" and hence using a different color to cyclewa:both/left/right, but the Twiki quote above doesn't seem weak/vague at all, and with the exception of the oneway issue is defined identical to cycleway:both. The distinction is actually also quite handy when tagging dual carriageways (dual one-ways) that join often.

I suspect when left and right were added that most cycleway=* tags were vague, because there was no way to be clear. The paint style was written a long time ago. Someone has apparently decided that moving forward it should have or does have a clear meaning. We should either change the wiki to indicate that the tag has too much historical vague usage to now be interpreted precisely, or we should get on board with the meaning the wiki says. Which one is better probably comes down to how much imprecise use of it exists.


comment:16 Changed 17 months ago by anonymous

Oh, and if it wasn't implied, the parsing in the default paintstyle seems to agree with my interpretation of the wiki(and has thoroughly considered many combinations), so I while there may be disagreement and/or just poor communication, I think what I'm aiming at has some well-established precedent even in existing JOSM styles, but that doesn't mean it's the last word either of course.

comment:17 Changed 17 months ago by Doug

... and the last two comments were by me.

comment:18 in reply to:  15 Changed 17 months ago by anonymous

Replying to anonym:

from the Twiki:

https://wiki.openstreetmap.org/wiki/Key:cycleway

"cycleway=lane is used to tag two-way streets where there are cycle lanes on both sides of the road, or one-way streets where there is a lane operating in the direction of main traffic flow."

This is what I was referring to. So cycleway=lane and oneway=yes implies "there is a lane operating in the direction of main traffic flow."

Yes, and in an ideal world you could trust that anyone has read and obeyed the doc, right? (..)

Which one is better probably comes down to how much imprecise use of it exists.

True, but exactly how are you to measure that imprecision? There is a pledge against mechanical edits for a reason. You can get "a feeling" for the degree of imprecision by having done lots and lots of edits, researching and revisiting legacy data in the database and compare or update that with surveyed data you gathered yourself (your 'ground truth').

Having gained experience you will find some of the most common mistakes made, which in the OSM universe often means you have found some doc (in the wiki or elsewhere) disputes with actual tagging practice. Detecting errors this way is often easy, but fixing them can be (is?!?) a nightmare, when trying to find

  • whether its indeed the data or maybe the doc that is in error
  • the degree of approval or consent on a (so-called) established mapping practice
  • integrity of established mapping practice (sometimes problematic tagging is well established and a consistent doc hard-ignored, because its perceived as a minority pledge (even though it may actually solve smoldering problems))

Fixing the doc based on mass data, or editing mass data to adhere to the doc has inevitable feedback/dependencies on each other. The sheer existence of the phrase 'we don't tag for the renderer' teaches that even map or editor styles can add to that feedback loop. There is some mitigation by the fact that many styles exist and ideally, each of them should be weighted equally to minimize the effect of data/tag shaping to achieve a specific look in a specific style. However, the popularity of the main style rather categorizes that last thought into wishful thinking.

So while the wiki doc may suggest cycleway=lane to be hard info instead of weak one, at least past experience in working with the data had taught me that there is no 1:1 correlation to cycleway:both=lane on two-way and one of cycleway:right=lane or cycleway:left=lane on one-way streets.

And even if everyone had read the wiki and strictly uses the tag according to the spec there, it simply isn't self-documenting. For example, to be strict, on a physical two way street with lanes on both sides, you'd rather expect the tag to be cycleway=lanes. But since its easy to produce error in a character missing, or overread, its better to explicitly encode this info using :both suffix.

The problem with legacy data is that it's often more fuzzy than the newer, more explicit tags. And while you can write a style with great disambiguity for the latter ones, its harder for the legacy data, because by design it classified more instances of real world entities into a single datum (read: single phrase).

It may have been a bad idea from the start to mix legacy and the namespace suffixed tags using the same style, because it may lead to the wrongful imprecision that the legacy tags indeed may be interpreted as sharply/clearly as the ones that have been introduced later in time. Bad idea, because the style may have contributed to a redefinition of the legacy tags (in the perception of the style users) - however, such redefinition has not been the intention. Would a map have rendered the tags with greater precision exclusively however, most areas would have been rather empty at the time of style writing (so it was an offer for completeness to render the fuzzy tags in combination -- and _not_ to suggest that they are/were to be interpreted semantically the same).

Greetings

comment:19 Changed 17 months ago by anonymous

This is a secondary issue to consistency, but that's fine.

Ok, color can represent "legacy" tagging, only harm is less ability to represent other things with those colors, like share_sidewalk etc. I'm making my style easy to adjust though.

There's still the issue of what to assume though, and I'd say at times (I'll get to it) legacy is more clear than supposedly more "precise" modern tags.

We probably should look for oneway:bicycle=yes on two-way roads with cycleway=lane, however an overpass search in Europe for this turns up very few hits. So either this practice was never established and there are many two-way roads with one-way cycle lanes that were just tagged very poorly, with very few marked right, or they've all been converted to left/right, or there just aren't many two way roads with one-way cycling lanes in existance. I strongly suspect the last one.

Regarding oneway roads, rather than saying it's "weak" information, I'd say it's at worst not all the information, but that's got very little to do with legacy tagging. If you have a oneway road with cycleway=lane and no other modifying tag, you better at least have a lane going with traffic, and I would not assume you have lane going the other way. This is what following the wiki and the core elemstyles gets you. Ok, maybe there is *also* a lane going the other way. That doesn't make what we do know any weaker though. With legacy [cycleway=lane][oneway=yes] doesn't mean there is *not* a reverse cycleway, and modern [cycleway:right=yes][oneway=yes] also doesn't mean there NOT a reverse cycleway; it might just mean the tagger doesn't know and didn't tag it. At least with legacy it is *possible* but probably rare to tag that this does *not* exist. Anyway, it's clearly better to display [cycleway=lane][oneway=yes] as only one sided without further information, and the core style does this. Also I really don't see what problem the modern tags solve here. They do cause a big problem though...

Tracks (and even segretated share_sidewalk which may really be a track) have another issue that they might be two-way but on one side of the road, and this is a bigger problem because directionality matters much more than placement, which the modern tags emphasize. So you may have cycleway:right=track, with no corresponding :left, and no bicycle:oneway indication, and to me it's completely unclear if that's a oneway or two-way track. There could be a wiki spec (I think there's not even), but it's easy to see a two way track on the left and just think and tag "oh that's a left cycleway", but also easy for someone else to see a one way and assume that :left sufficiently implies the direction of travel. In this sense cycleway=track is to me *stronger*, in that it's more likely that you can assume that if it were oneway, it would have been tagged as oneway, regardless of placement which never had anything to do with it. Maybe the placement refinement distracts from and creates unclear assumptions about direction, while allowing more clarity on placement.

We can agree though there are two tagging systems and they can have different colors. I am not at all convinced about which system is more or less ambiguous or even useful.

I've got something worked up now that does most of this. I can try to shoehorn legacy coloring back into it. I'm considering ways to rework the code though, but options are limited with the available tools of course.

-Doug

comment:20 Changed 17 months ago by anonymous

I looked a bit for two-ways with one-sided cycle lanes using new tagging. There are actually a bunch even once you remove junctions or links. Most are really micro mapping, and I found one of my own like that even, lane on one side, a separated path on the other. Many are like that. Many are lanes for a short block to position traffic for an intersections. Most are on small low traffic streets where I guess there was enough room to add one. I found a few long ones, with the paint worn off, and a few where the next block over had the reverse lane. At any rate they do exist. So far I haven't found any that would have bothered me much as a cyclist, like a heavy traffic street with no obvious reverse alternative, but there are many cases tagged.

comment:21 in reply to:  19 ; Changed 17 months ago by anonymous

Replying to anonym:

Regarding oneway roads, rather than saying it's "weak" information, I'd say it's at worst not all the information, but that's got very little to do with legacy tagging.

Please, don't be biased by the term "weak" - it does not mean bad info. In essence it just sums up what you are describing with other -your- words. Its really just a terminology thing. Weak refers loosly to 'not all info' or 'general info', while strong means a set of information leaves little to no doubt on details.

The comparison on the two methods stands. The legacy method was neither designed to be self-documenting nor is it universal, it has lots of cross-dependencies and conditions and tag semantics does even change depending on the combination of tags, e.g. cycleway=lane So yes, in combination with a detailed documentation that lays out these conditions and how they are to be interpreted it may achieve the same level of descriptivity, but it does so with much more effort and things you'd have to remember as a mapper or programmer.

Also, do not try to speculate into the void by trying to make assumptions about a situation on ground based on absent tags. This is useless, e.g. if cycleway:right=track is present, then there is

  • no implication by default on the directionality - could be a oneway for cyclists or they could be allowed to travel in both directions, we simply don't know if cycleway:right:oneway=* is not given as well
  • no information on what's on the left side of the street - it's a nuisance to try to derive information from absent tags (!)

All it says is, that there is a cycle track accompanying the road on its right, nothing more, nothing less.

Similar to the legacy tags (put aside the hard-coded wiki specifics for a moment, please): cycleway=lane by an intuitive interpretation scheme will mean that there's at least one lane marked on the road - we don't know which side and we don't know if that flows with or contra motorized traffic (unless we superimpose that information by specifying it in the wiki: this has been done but at a level that lies above intuitive interpretation, very high so even if you consider the different interpretation based on whether its used with or without oneway=* tag).

Greetings

comment:22 in reply to:  21 ; Changed 17 months ago by anonymous

Also, do not try to speculate into the void by trying to make assumptions about a situation on ground based on absent tags. This is useless, e.g. if cycleway:right=track is present, then there is

  • no implication by default on the directionality - could be a oneway for cyclists or they could be allowed to travel in both directions, we simply don't know if cycleway:right:oneway=* is not given as well
  • no information on what's on the left side of the street - it's a nuisance to try to derive information from absent tags (!)

All it says is, that there is a cycle track accompanying the road on its right, nothing more, nothing less.

That was exactly my point. While you are right that I shouldn't assume cycleway:left=track implies direction, it's easy for people in general to feel that they have sufficiently tagged a road by saying cycleway:left:=track, where with cycleway=track you'd probably feel it's misleading if there's only a one way track on the left, and you'd be more likely to instead add a separate one-way way.

The new tagging focusses on placement, which is almost irrelevant compared to direction. Furthermore how to clarify direction isn't even obvious, relative to the main road? Or relative to the flow of traffic on the cycleway side? Even the overall oneway:bicycle=no doesn't clearly relate to the track.

If we cannot clearly specify direction of travel then more so called precision is useless to actual cyclists wanting to know how to get somewhere. So much for more precise modern tags. Really I don't feel this was ever thought out well, but that's the nature of OSM.

And so we should probably add all cycleway:both/left/right tags to the "weak" category? What about lane? Surely we can assume directionality of lanes by their placement? If not, then why in the world are we bothering with the micro-tagging at all?

comment:23 Changed 17 months ago by anonymous

-Doug

comment:24 in reply to:  22 Changed 17 months ago by anonymous

From the twiki.

cycleway=lane is used to tag two-way streets where there are cycle lanes on both sides of the road, or one-way streets where there is a lane operating in the direction of main traffic flow.

Consider using the cycleway:left=lane and/or cycleway:right=lane tags instead for a cycle lane which is on the left and/or right side, relative to the direction in which the way was drawn in the editor, as this describes on which side the cycle lane is. It should then be assumed that cycle traffic is allowed to flow in the customary direction for traffic on that side of the road.

And indeed the bold does't exist in the description for track. And yet it's clearly easy to fail to appreciate this when tagging. I would say cycleway:left/right=lane is a strong tag but cycleway:left/right/both=track is weaker than cycleway=track. In the wiki there is discussion of implied directionality for cycleway=track. There is no such discussion for left/right/both=track.

We do assume things. We assume separately mapped paths are two way. The reason we can't assume about track:left/right is that it carries weak implications that may have been relied upon when tagging, but also may not have.

comment:25 Changed 17 months ago by anonymous

-Doug

comment:26 Changed 17 months ago by anonymous

And so we should probably add all cycleway:both/left/right tags to the "weak" category? What about lane? Surely we can assume directionality of lanes by their placement? If not, then why in the world are we bothering with the micro-tagging at all?

I meant to say cycleway:both/left/right =track should be considered weak.
-Doug

comment:27 in reply to:  22 Changed 17 months ago by anonymous

Replying to anonym:

Furthermore how to clarify direction isn't even obvious, relative to the main road?

With the newer tags it is! Relative to the direction of the osm way. This means that e.g. cycleway:right:oneway=1 encodes a cycleway to the right of the road where flow of direction is legally allowed in the direction of the osm way only. And, as stated earlier, it also means that cycleway:right:oneway is completely independent on the value of a hypothetically, also present oneway=* tag.

"To the right of the road" also solely depends on the directionality of the osm way

  • i.e. to the right of the vectors given by the node list of the osm way
    • if you have three nodes A, B, C and a way composed of {A, B, C} then "right" refers to the right side of vectors AB and BC respectively
    • or in other terms if you stand at A and look at B (or stand at B and look at C) then anything to your physical right side)

This is why I stated earlier that the newer tags do not cross-depend on the value of a maybe present oneway=* tag. This is a good thing, because you can decode all the tags without caring about the value of oneway=* if it is present. (This contrasts the legacy cycleway=* tags, that change their meaning depending on the value of oneway=*.)

I think, to sanely continue this conversation we should come up with some graphics that lay out all the possible cases and then we can assign tag sets to these and argument referring to them rather than continuously pulling vagueness of natural language into our objects of discussion.

Greetings

comment:28 Changed 17 months ago by anonymous

Also, considering the wiki doc, there is another inconsistency in the interpretation of absent tags, I guess. For example, the absence of oneway=* tag usually indeed implies that traffic flow in both directions is allowed and _not_ that a mapper has forgotten to tag oneway=*.

To the best of my understanding, this is different with :oneway=* suffix based tags used in combination with cycleways. If :oneway=* is absent in that realm, there is no automatic implication that traffic flow in both directions is assumed. Do not take this for granted although, I might err badly on this one, but having read the relevant wiki pages I have not found any implied defaults documented.

If the majority of software treats this differently and harmonizes in interpretation of the absence of both of these, then the wiki should be updated to reflect this. This seems hard to answer as an individual, really. It seems like a good question for a poll:

"Do you think the absence of :oneway=* implies that traffic flow is permitted in both directions of a highway feature?" ;-)

comment:29 Changed 17 months ago by mkoniecz

If :oneway=* is absent in that realm, there is no automatic implication that traffic flow in both directions is assumed.

Citation needed. I never ever used it, in all cases known to be one of following was enough

  • no oneway and no oneway:bicycle tags
  • oneway=yes and withiut oneway:bicycle tag
  • oneway=yes and oneway:bicycle=no

comment:30 in reply to:  29 Changed 17 months ago by anonymous

Replying to mkoniecz:

If :oneway=* is absent in that realm, there is no automatic implication that traffic flow in both directions is assumed.

Citation needed. I never ever used it, in all cases known to be one of following was enough

The citation is the absence of an explicit statement in the wiki about implied values (while for the non-suffixed use defaults are documented).

But in the meantime I've also found a footnote in DE:Bicycle/Radverkehrsanlagen_kartieren, that is in favor of explicit use in the yes and the no case.

However, DE:Key:cycleway states that, in Germany, all accompanying cycleways to roads are oneway cycleways unless an additional traffic sign permits two-way usage, but that wiki page is unclear about whether that implication covers the tag. IMHO it does not, because the tag is international and so I assume that the implication just mentions the legal status within german jurisdiction and not that a mapper or programmer should assume that as a value in case the tag is absent.

Since the translation of the tag documentation accounts for national peculiarities, it may be wrong to advertise the tag as a universal, generic one. The translations of the documentation to universal tags should be kept universal, otherwise these peculiarities will go by unnoticed by anyone reading the doc for the tag in another language: If a tag has heavy polymorphism based on country-code, then this must be documented in all language translations. But in this case it may make more sense to not use a universal tag key at all, but country-specific ones.

comment:31 Changed 17 months ago by mkoniecz

DE:

In that case apparently German translation is incomplete, contains mistake or there is some undesirable local change of what tag means.

Though it is possible that mistake is also on English version.

comment:32 Changed 17 months ago by Doug

muella8

Your last couple of comments are helpful. I'm a little confused who thinks what.

But I agree that for cycleway:left/right/both:oneway only oneway travel can be assumed to exist for each side. The other direction could exist but is not made clear, or we could say is unstated (just as road that isn't drawn). This fact is made clear in the English wiki for lanes but not tracks in either the cycleway wiki or cycleway=tracks wiki (which also documents cycleway:left/right/both, but, and you said we need examples, it is clear in the bicycle wiki and this is probably really the most used reference I suspect:

https://wiki.openstreetmap.org/wiki/Bicycle

And they apply that same logic to tracks as well as lanes.

I'm not sure what your reference is for cycleway:left:oneway referencing to the way direction, but ok. It's interesting because the default direction for cycleway:left:right is traffic flow direction no according to the English cycleway wiki lanes section. So for an righthandtraffic oneway=no, cycleway:left:oneway=-1 is default and does NOT change anything. And I found one live example of exactly that tagging (by accident, probably are more). Reverse a cycle track direction is probably rare anyway. cycleway:left:oneway=no is a more common qualifier. There is no example in the bicycle wiki of a reversed cycle track direction. I'm not sure how well established the meaning of -1 is.

I agree that for cycleway=* two-way is certainly implied. Well what's implied is the same movement as the road. The wiki makes this explicit now for lane, and I think this was always kind of the obvious intuitive macro meaning of this simple system. It means we have this road that does this, and it does it with bike lanes too. If you can't do something the road can do, obviously you better be clear about that. It's not 100% clear that you can do something the road doesn't do, go backward down a oneway, just as it's probably not 100% clear that you canNOT go backward down a left side track, but better not to assume it in either case, and I don't plan to.

Anyway, I'm slowly (in bits of time) writing some code.And it will separate all these issues pretty cleanly I hope. In the first iteration (ok 2nd really, 1st is done) it probably won't render direction of tracks though, only sides, but really it needs both because cycleway:left:oneway=no is important. Anyway, I'm workig out logic to establish the facts, and then can worry about rendering those details. I have an idea ho to render a two-way subscript track. I have no idea how to render a reverse track. My plan at the moment is to use the "weak" color because I don't know how much we can trust it anyway really.

Eventually we can discuss any remaining differences about details once it's literally encoded, but I think basically we agree. Taggers just need training in programming to understand the rules, which is why maybe it's good to have a renderer that captures some agreed understanding, and we can work from there.

-Doug

comment:33 in reply to:  28 Changed 17 months ago by anonymous

Replying to anonymous:

"Do you think the absence of :oneway=* implies that traffic flow is permitted in both directions of a highway feature?" ;-)

Yep, that poll question would clear up, uhm, nothing, lol.

comment:34 Changed 17 months ago by anonymous

Here's an even better one.

right hand traffic,
oneway=no
cycleway:left=lane
cycleway:left:oneway=yes

The way points opposite to the flow of traffic on the left. So the default ..:left=lane direction is -1.
Does yes=1 as is the usual case?

If so did that just reverse the lane direction? Saying that a lane that was already oneway, is, "yes", "oneway", now made it go the other way?

comment:35 Changed 17 months ago by anonymous

-Doug

comment:36 Changed 17 months ago by anonymous

I'm not too bothered by it though. Default is the correct way for the side of the road it's on, cycleway:left:oneway=no is well defined, and any city planner who somewhere made a one way cycle path that goes the wrong way for the side of the road it's on, should probably be fired (There's probably one somewhere). So I'm marking any use of oneway other than no as "weakinfo", should probably really red flag it as just plain wrongly tagged.

-Doug

comment:37 in reply to:  34 Changed 17 months ago by anonymous

Replying to anonym:

Here's an even better one.

right hand traffic,
oneway=no
cycleway:left=lane
cycleway:left:oneway=yes

The way points opposite to the flow of traffic on the left. So the default ..:left=lane direction is -1.
Does yes=1 as is the usual case?

If so did that just reverse the lane direction? Saying that a lane that was already oneway, is, "yes", "oneway", now made it go the other way?

According to all the docs we've read so far, yes, it does "revert" lane direction, because :oneway=*, as stated, is interpreted strictly to be based on the osm direction of way (_not_ on the flow of motorized vehicle traffic (bold arrows below) and _not_ on the general oneway=* tag). To lay out some utf-8 graphics, the above refers to a layout similar to this:

             dashed arrows reveal direction of osm way:
      ⇡      -- last node of the osm way on this end
|↑|   .   |
|↑| ⇓ ⇡   |
|↑|   . ⇑ |
|↑|   .   |
      ⇡      -- first node of the osm way on this end

Because the interpretation is based on the osm direction of way it is independent on right/left hand traffic system (!), so your example applies to left hand traffic systems as well. If, hypothetically, :oneway=* was interpreted base on right/left-handedness this would break consistency with the semantics of the general oneway=* tag which is also, exclusively(!), interpreted based on the osm direction of way.

But actually this is another good example to the problem I've referred to earlier: Is the doc actually in sync with established mapping practice? Adhering strictly to the doc does not do us any good if the de facto standard does it differently (read: if the de facto standard conflicts with the doc). If we have detected a conflict, then there are two ways to solve it: fix the doc _or_ do a, possibly mechanical, edit once to sync the tags to the doc (and then hope that all the mappers will pick it up).

Greetings

comment:38 Changed 17 months ago by anonymous

btw: -1 value to reverse the semantic of oneway=* or :oneway=* suffixes is well established and has been so for a long time; it also has strong editor support, e.g. josm will warn and offer to change 1/-1 if you are about to revert the osm direction of way (revert the node list) in the editor.

comment:39 Changed 17 months ago by anonymous

I've edited https://wiki.openstreetmap.org/wiki/Bicycle to not suggest opposite_lane as a value in combination with cycleway:left, cycleway:right or cycleway:both key variants. The proper way to express directionality with these keys is and has always been *:oneway=*

There's simply no sanity in the mixed variant. I've no idea what individual or group discussed it in whatever forum or mailing list, but the state this has been in was plain wrong. It mixes two tagging schemes that were well separated at the time of design. Of course, the wiki edit may be reverted and the page will then continue to misinform people seeking advice. I'll not start an edit war about it, but don't complain that I have not tried.. ;-p

comment:40 Changed 17 months ago by Doug

Sorry, but I think some of your opinions, like that yes=1 are at complete odds with reality, so I've dug in to get data.
<pre>
World:
cycleway=lane= ~277,000
cycleway:right=lane ~73,000
cycleway:left=lane ~30,000
cycleway:left=lane combined with cycleway:right 19,870
cycleway:right=lane cycleway:left oneway~"yes | 1 | -1" 47652

conclusion: excess cycleway:rights are on one-way streets, fine.

cycleway:both=lane 2,000
cycleway=both 2,000
cycleway:left:oneway no 1,693 -1: 979 yes: 791 1: 0
cycleway:right:oneway yes 3,378 no: 2,672 -1: 18 1: 0

sum of =both :both=lane and right+left ~ 24,000 , 11.5 times less than cycleway=lane

In Germany:
cycleway:right=lane 11,595 (73,000 world wide)
cycleway:right=lane and cycleway:right:oneway 10,731
cycleway:left:oneway=-1 864 ( 979 total world wide)
cycleway:left:oneway=yes 733 (791 word wide)
</pre>

From surveying actual use cases and by comparing left and right here,
basically only Germany uses values of cycleway:*:oneway other than no.
For cycleway:right:oneway, they only use yes and no. This suggests wrong-sided lanes don't exist in Germany.
But for cycleway:left:oneway there are, in contrast, equal numbers of "yes" and "-1" (and reviewing some they are the same and do flow opposite the way direction.

Clearly "yes" is referenced from traffic direction, ie the default. But -1 is referenced from the way direction. In effect yes==-1 on the left, which might be logical in Germany or..

MOST (93% for right) cycleway:*=lane in Germany are not tagged with cycleway:*:oneway even though it's clear that most LANES are oneway. So even MOST of German tagging is the same as the rest of the world where the direction is assumed to follow traffic. In all cases cycleway:*:oneway=no implies of course an explicit two-way lane/track/thing.

What I can't be sure is still most two-way tracks on one side marked with ...:oneway=no. This is very hard to determine. In many cases it's even hard to clearly say if you'd call the track two-way. Looking at many, some are clearly one way, narrow, with a thin curb separation from the road. Some are not clear, a moderate width sidewalk that you probably could go backwards down. Some are clearly meant for two-way travel but not explicitly marked. I think it's best to only assume one-way. Most of these one-sided subscripted things are not important cycle ways. Long distance two-way paths off the road are mapped separately.

Another interesting point, there is almost no use of any cycleway:*:oneway tags in any lefthandtraffic country that I can find.

Conclusions:
-cycleway=* is still over 10 times more prevalent than cycleway:*=* and is still used extensively and I think well.
-left and right are usually used without oneway modifiers when they go in the correct-sided direction, even in Germany.
-Tracks cannot be assumed to be two way but can be assumed to at least go in the correct-sided direction. It's still probably better to mark them like :left:oneway=yes to be clear, but few people do.
-cycleway:*:oneway=yes DOES mean the default correct-sided direction, always, never backwards to normal-sided traffic, but outside of Germany and for 90% of German taggers too, nobody tags oneway lane/track/things as oneway anyway. At least the proper direction is assumed. There's no conflict there though.
-I don't see any important differences in German tagging compared to the rest of the world, although two small, differing, but compatible groups might like to think so, there is no real incompatibility with the world.
-Share_sidewalk? Do we have to go there. Ok, I'd probably assume two-way always actually?

This is reality.

comment:41 Changed 17 months ago by anonymous

Me:"Another interesting point, there is almost no use of any cycleway:*:oneway tags in any lefthandtraffic country that I can find."
I might have that statement slightly wrong. That was from memory. There was some combination like that that was very absent.

I still don't know know what document you insist references oneway to the way direction. The only docs I find in English are this:
https://wiki.openstreetmap.org/wiki/Tag:cycleway:right%3Dlane

which ONLY documents the value of "no", which is probably why most people only use "no", in agreement with my findings above.

I agree that opposite_lane seems like a truly different name space than :left/right/both: and my parser treats it as such.

comment:42 Changed 17 months ago by anonymous

-Doug

comment:43 Changed 17 months ago by anonymous

Also I do agree that -1 means opposite to the way direction... for oneway= . But that doesn't mean it's true for cycleway:right:oneway=

It so happens it's never used for that, but only for left and only ever tagged in right hand drive countries (yes, that was it) and in that case -1 does mean opposite the way direction, true, but in that case "yes:" also means opposite the way direction.

So in a practical sense I suppose we could agree on -1, but must disagree on "yes==1" in the way direction sense.

comment:44 in reply to:  43 Changed 17 months ago by anonymous

Replying to anonym:

Also I do agree that -1 means opposite to the way direction... for oneway= . But that doesn't mean it's true for cycleway:right:oneway=

Yes, it is true for cycleway:right:oneway= - why in the world should it not?

comment:45 Changed 17 months ago by anonymous

As stated earlier, there is no cross-dependence of oneway=* and cycleway:right:oneway=* (!) Both are to be interpreted based on the direction of the osm way, period.

If you want cross-dependence then walk with the legacy, unaffixed tags and values.

comment:46 Changed 17 months ago by anonymous

TYPO
cycleway:right=lane and NOT cycleway:right:oneway 10,731

comment:47 in reply to:  40 ; Changed 17 months ago by anonymous

Replying to Doug:

Clearly "yes" is referenced from traffic direction, ie the default. But -1 is referenced from the way direction.

This is untrue. To re-iterate, cycleway:left:oneway and cycleway:right:oneway both refer to the osm way direction (read: the direction given by the node order of the osm way).

comment:48 Changed 17 months ago by anonymous

Yes, I agree, it's just yes==1 that isn't true. That's true in Mapcss though which could cause confusion.

comment:49 in reply to:  48 ; Changed 17 months ago by anonymous

Replying to anonym:

Yes, I agree, it's just yes==1 that isn't true. That's true in Mapcss though which could cause confusion.

Please elaborate. What do you mean by "yes==1 that isn't true".

comment:50 in reply to:  47 Changed 17 months ago by anonymous

Replying to anonymous:

Replying to Doug:

Clearly "yes" is referenced from traffic direction, ie the default. But -1 is referenced from the way direction.

This is untrue. To re-iterate, cycleway:left:oneway and cycleway:right:oneway both refer to the osm way direction (read: the direction given by the node order of the osm way).

Cross posted. I agree that oneway=-1 refers to the lane direction "But -1 is referenced from the way direction." (I did mispeak once later). But yes does not ==1. Nor does yes== -1.

Yes == references the traffic direction. That's just actual reality on the ground. I suppose to be consistent with you we could say the value of yes changes. Fine. The value of yes changes and that value references the way direction. Good enough? This only matters to 10% of mappers in Germany. Nobody else cares, since that 10% is only mapping facts that are already assumed.

comment:51 in reply to:  49 ; Changed 17 months ago by anonymous

Replying to anonymous:

Replying to anonym:

Yes, I agree, it's just yes==1 that isn't true. That's true in Mapcss though which could cause confusion.

Please elaborate. What do you mean by "yes==1 that isn't true".

:oneway=yes is only used in Germany (or nearby)

  • On the right, only yes (forward, in the way direction) and no (two way) are used. -1 is never used with :right:oneway.
  • On the left both yes and -1 are used and they both refer to the same thing, traffic opposite the way.

90% of the time even in Germany no tag is used for this as the one-way is assumed correctly.

This is fact of how its used. The usual direction on the left side of a way in Germany is opposite the way. So yes==-1 on that side.

comment:52 Changed 17 months ago by anonymous

Do not superimpose any complexity on the oneway keys that is just not there.

Both, the general oneway=* and the *:oneway=* are always and in any case interpreted based on the direction of the osm way. Anything else would harshly violate the consistency of that tag and its meaning (and its ease of use).

There is also no difference between 1/true/yes, they are all to be interpreted the same, unconditionally. Just as the triple 0/false/no are to be interpreted the same, unconditionally. -1 is special only in the sense that its a stand-alone value

comment:53 Changed 17 months ago by anonymous

"I agree that oneway=-1 refers to the lane direction " and again, sorry, I mean way. We agree on this.

comment:54 Changed 17 months ago by mkoniecz

Note that this ticket is supposed to be about " Cycleways map paint style emphasizes cycleway=lane more than cycleway=track", not place to discuss how oneway lanes are supposed to be tagged.

comment:55 in reply to:  51 ; Changed 17 months ago by anonymous

Replying to anonym:

:oneway=yes is only used in Germany (or nearby)

  • On the right, only yes (forward, in the way direction) and no (two way) are used. -1 is never used with :right:oneway.

If I have a highway + oneway=-1 and a cycleway:right=lane which allows cyclists to traffel only in the direction of the main traffic flow of that oneway, you will tag cycleway:right:oneway=-1 This is pure logic.

  • On the left both yes and -1 are used and they both refer to the same thing, traffic opposite the way.

Sorry, this does not make sense. yes/1 and -1 do not refer to the same thing. If you deducted this belief from data, then the data or your interpretation is wrong.

comment:56 in reply to:  54 Changed 17 months ago by anonymous

Replying to mkoniecz:

Note that this ticket is supposed to be about " Cycleways map paint style emphasizes cycleway=lane more than cycleway=track", not place to discuss how oneway lanes are supposed to be tagged.

Yes, sorry. You're right. This discussion has blown up pretty far from that.

comment:57 in reply to:  55 ; Changed 17 months ago by anonymous

Replying to anonymous:

Do not superimpose any complexity on the oneway keys that is just not there.

Both, the general oneway=* and the *:oneway=* are always and in any case interpreted based on the direction of the osm way. Anything else would harshly violate the consistency of that tag and its meaning (and its ease of use).

There is also no difference between 1/true/yes, they are all to be interpreted the same, unconditionally. Just as the triple 0/false/no are to be interpreted the same, unconditionally. -1 is special only in the sense that its a stand-alone value

You're welcome to opinion. I'm telling you the actual fact how it's used. Yes means the correct-sided way of traffic in germany. That's how it's actually used, and it's how it's used most places too. this goes with the idea that the direction can be and is assumed by everyone outside of germany. And that oneway=yes just makes it clear that no other direction is possible. There is not only one way to be logical.

Regarding tagging and rendering, it's the same thing. I'm making a renderer, and I'm making it match the actual tagging in use. cmuelle8 still has not provided a reference for this idea that yes must mean 1 in a way sense. Replying to anonymous:

Sorry, this does not make sense. yes/1 and -1 do not refer to the same thing. If you deducted this belief from data, then the data or your interpretation is wrong.

I thought it was clear I was being witty. Yes = both plus and minus one only if you insist that yes is referenced from the way direction. I don't care what number you want to call it. Yes is in fact used to mean the way direction on the right, and opposite the way direction on the left. That's not my opinion. It's how it's used. You're welcome to go search it.

comment:58 Changed 17 months ago by anonymous

-Doug

comment:59 in reply to:  57 Changed 17 months ago by anonymous

Replying to anonym:
Yes = both plus and minus one only if you insist that yes is referenced from the way direction. I don't care what number you want to call it. Yes is in fact used to mean the way direction on the right, and opposite the way direction on the left. That's not my opinion. It's how it's used. You're welcome to go search it.

Let's first continue this discussion on Talk:Key:oneway in the osm wiki, to respect mkoniecz's objections, and post a link there to real data where you think your opinion applies. I'm telling you, again, that yes != -1, always and ever. The value yes is a synonym to the values 1 and true (and has ever been in the osm universe), _not_ -1. You can learn about that, among other places, here.

comment:60 Changed 17 months ago by anonymous

I already posted the data.

comment:61 in reply to:  60 Changed 17 months ago by anonymous

Replying to anonym:

I already posted the data.

Yes, but you seem to misinterpret it, which is why I asked for an exemplary link to a "real" world location to underline the claims you've made.

comment:62 Changed 17 months ago by anonymous

it's not a good idea to decide new schema or wiki change here in stead of talking about it with the "global community" (mailing tagging for ex)

comment:63 in reply to:  62 Changed 17 months ago by anonymous

Replying to anonym:

it's not a good idea to decide new schema or wiki change here in stead of talking about it with the "global community" (mailing tagging for ex)

there is nothing new really, just concretion of things of the past that were left open for ample speculation. if you search the mailing list you should find patterns of what has been discussed here.

comment:64 Changed 17 months ago by anonymous

there is nothing new really, just concretion of things of the past that were left open for ample speculation. if you search the mailing list you should find patterns of what has been discussed here.

Could you point this discussion or anything that shows this? I am okay with the different ways to discribe the opposites lanes but I know that this way to change the wiki are source of problems.

comment:65 Changed 17 months ago by anonymous

You know I thought for a minute maybe the huge discrepency between left and right tag results, and you can see it on taginfo, is because there are maybe more way pointing left cycleways than way-reversed right ones due to one-ways usually being drawn with the lane. That wouldn't explain all the cases I've seen that are two way, but it would explain SOME of the imbalance. That's not the case though. Of the 733 cycleway:left:oneway=yes tags in Germany, 596 of those are on two-way ways, and by your reference system would imply a reversed direction left-side cycletrack. Most don't have mapillary, but most of those are simply two way streets with tracks/lanes on both sides.

Here is the overpass query, so go try it and review some for yourself.
[out:json];
/* for counting: */
/* [out:csv(::"count:ways")][timeout:25]; */
{{geocodeArea:Germany}}->.searchArea;
(

query part for: “"cycleway:right"=lane”
way[!"oneway"]["cycleway:left:oneway"="yes"](area.searchArea);

);
(._;>;);
/*end of auto repair*/
out;
/* for counting: */
/* out count; */

;

Yes, it's a biased query. In your reference system it's biased toward selecting wrongly tagged things, and some wrongly tagged always exist. I concede that. However, again, remove the !"oneway" and you don't get many more!

This is the first one I randomly zoomed in using that search:
https://www.openstreetmap.org/way/331512936

Although I'll admit it's not the first time I searched something similar, but it is one of the better examples mostly just by way of having clearly painted tracks with mapillary photos, so slightly hand-picked.
It's a two-way street. One-way cycletracks on both sides. cycleway:left:=yes is marked, but the left cycle track goes in the normal sense... against the way. And you can find many more.

Again I explain it as yes of course means 1, unity, the unitary operator, the agreement, nonchanger, in some sense. One times some vector, but what vector? The default understood vector. For a way, the only and established one is the way vector. For a left side cycletrack, the default understood vector might be the way, or might be the default notion of the cycletrack direction which for a two-way is opposite to that. That doesn't mean oneway= doesn't reference the way, or that yes means negative 1. It means tagging isn't vector math. It must make sense clearly by everyone's intuition or the tag will fail, and tags without directional wording won't be directionally unarguable. We can state this alternative as vector math though. The math is is yes means 1 times the default vector for the travel in question, which can be -1. Obviously another interpretation is yes means 1 times the way direction. This ambiguity is exactly my point about :left/right: not being clearly more clear. Maybe a consensus will establish. This is still 2% of all cycleway cases right now. I believe a consensus is developing, but I'd call it early. Only :oneway=no is documented and widely used.

comment:66 Changed 17 months ago by anonymous

-Doug

comment:67 Changed 17 months ago by anonymous

Sorry, yes, if we change something we should take it to the wiki. I'm doing real work on I think a significant encoding, and maybe it will or won't replace cmuelleas, at the moment it's targetted to look very similar, but maybe I get a little flexibility as being the guy doing some work at the moment. For the moment I think it's easier to discuss here at this level of nuts and bolts than on a wiki and if we really think we find some discrepency or thing that needs addressing, that has to go the wiki, but maybe in a simplified form.

-Doug

comment:68 Changed 17 months ago by anonymous

The example of course has cycleway:left: oneway =yes .

comment:69 Changed 17 months ago by anonymous

Sorry, yes, if we change something we should take it to the wiki. I'm doing real work on I think a significant encoding, and maybe it will or won't replace cmuelleas, at the moment it's targetted to look very similar, but maybe I get a little flexibility as being the guy doing some work at the moment. For the moment I think it's easier to discuss here at this level of nuts and bolts than on a wiki and if we really think we find some discrepency or thing that needs addressing, that has to go the wiki, but maybe in a simplified form.

This topic is also very discused in the talk-fr but we wait to have a consensus before adressing it to the tag list and I hope after a clean porcess modify the wiki.

I am still looking for archive that could enforce the cycleway:left=lane + cycleway:letf:oneway=-1 instead of cycleway:left=opposite_lane. I am ok with the two way even if I prefere the seconde one*. I just would like to have some information about the acceptation of the way to tag opposite lanes

*Some explaination : every week I check every contributions one bicycle data in Île-de-France (Paris region) and way to contribute to bicycle layout are really not mastered. Because of the complexity and diversity of bicyle layouts and because of the complexity of scheme. Event experimented contributors make a lot of mistakes. The use cycleway:left=lane + cycleway:letf:oneway=-1 will increase the difficulty and it is not only my view but the other contributors I have ask to have there feedback. And again I am ok with every way to tag as long as it is accepted and not the deduction of one person point of view because we are a lot to have a point of view and to be sure it is the right one...

The only thing I have read in favor of the *:onway=-1 is that : "you can decode all the tags without caring about the value of oneway=* if it is present." But this is really a personal point of view since a tag is added so we can ignore one other !?!

comment:70 in reply to:  65 Changed 17 months ago by anonymous

Replying to Doug:

Of the 733 cycleway:left:oneway=yes tags in Germany, 596 of those are on two-way ways, and by your reference system would imply a reversed direction left-side cycletrack.

This is easy to understand and I'm with you on this one. But it still does not mean I'm in favour of the data, because it conflicts the tag documentation in a crude way. And not only that, it also conflicts the values you can empirically derive by looking at how the unaffixed oneway values are used and distributed (!).

I've not done an overpass query, but am willing to presume that you will not find (or at least not massively find) oneway=yes tagged on a highway that is used in replacement of a oneway=-1.

(It should be harder to find a good query for this, as there are no implications you could test against - a ground truth oneway that is represented by an osm way with its first node at the end and its last node at the start of that oneway, imho you'd need an aerial to tell, because the prerequisite is that you cannot query for oneway=-1).

Do you acknowledge that it's a very bad idea to interpret the yes value of oneway=* and *:oneway=* in a different way?

comment:71 in reply to:  69 Changed 17 months ago by anonymous

Replying to anonym:

The use cycleway:left=lane + cycleway:left:oneway=-1 will increase the difficulty.

This is also just a point of view. Because it is rather explicit and will more rarely lead to mapper disputes you could also argue that difficulty is decreased by magnitudes. Not every map is affine to consider left/right hand traffic related peculiarities when mapping and remember that OSM is an international project and theoretically anyone could map anywhere in the world based on aerials.

Also note that this argument vanishes/erodes almost in full if there is a consent (and a proper documentation) of -1 being implied for cycleway:left:oneway=*. Such implication will need to reference the traffic system left/right-handedness, however. In other words, within a left hand traffic system 1 should probably be implied instead. This puts (affordable) burden on programm code to derive a value for the tag if its absent, but would free mappers from having to tag the default case.

Lets suppose there is a consent for this, then this would still mean, that the current data needs to be checked or removed, because with the implication of the last paragraph cycleway:left:oneway=yes tags the exemption from the default, not the implied default.

Lastly, if oneway=* and *:oneway=* is consistent in its use, I cannot see where this would increase difficulty. As a mapper you can rely on the same use and interpretation in any context, regardless of it being used unaffixed or suffixed. This does rather put confidence at hand, than difficulty.

The empirical mess you've dug up now is full of things you have to consider, you'd have to draw a flowchart to get the interpretation right for all its special cases, spare the hidden inconsistencies (..). With any goodwill, I do not see how this is "easy".

comment:72 Changed 17 months ago by anonymous

Both -1 and yes are used and at the moment both seem used consistently without confusion, but it's probably a pretty small group of people, and could get worse.

For the purpose of defining a style parsing (now finished, just touching up the rendering), I'm satisfied that I have something that reflects present reality.

The rest, probably can be discussed elsewhere, but I'll just say, both are a point of view. People are turned off by -1 being against the default, and people are turned off by yes being in some sense equivalent to -1. To if we interpret numbers as coefficients on the way vector, and answers as answers to the question of is it oneway but not what direction is it(which we already think we know), then they both work.

It's not actually true either that you have to think that the "yes" value is interpreted differently than it is for oneway=. Even that depends on how you think of it. Both indicate onewayness and both leave the direction up to some predetermined standard default. For a way, there's no real default, so it's the drawing direction. For a cycleway, there is a default. I get the criticism, but I also get why people like it and criticize -1.

The real problem is the same one I pointed out from the beginning before realizing that it would manifest in precisely this way, that being that cycleway:left and right are simply not more clear about direction than legacy tags were. If you want a direction intuitive tag that everyone is certain to agree on, you need tags about direction, not sides. For now though, it's not a mess really. Both yes and -1 are being used very harmoniously for now to indicate the normal direction of a left side cycleway.

A better solution might be at least be, like
cycleway:left=lane
cycleway:direction=*
with values of "default", "contraflow" and "both", and no numbers since it's impossible to agree what they reference to.
I started to say reversed and thought better. Some will think about the way.

Anyway, you could automatically re-tag everything now and probably have 20 errors. So discussion can continue on that.
I'm not cutting anything off, but my feeling is we've smoked out all the detail we can here and I can write a style!

Oh, and as for that flow chart, I've done it. The old styles basically hand described every combination and that's not easy to maintain or to add to. I've broken it down. I'll post it up, but I peck at it slowly to perfect it. Just added two-depiction of tracks/lanes. Basically every cycleway/path looks different and kind of representative of what it is, and yet on the whole it still feels much like the old one.

comment:73 Changed 17 months ago by anonymous

And even counterflow or whatever could be confusing next to a one-way.

Maybe "right-handed" "left-handed" and "both" are actually the simplest values for cycleway:direction
Notice one of the biggest things it does is remove the answer of "yes." Q: What direction? A: Yes. uhm... That's half the problem really. The other half being how to tell direction in a way that is obvious to everyone without even reading a wiki.

-Doug

comment:74 in reply to:  72 Changed 17 months ago by anonymous

Replying to anonym:

The real problem is the same one I pointed out from the beginning before realizing that it would manifest in precisely this way, that being that cycleway:left and right are simply not more clear about direction than legacy tags were.

This is untrue. In fact they were _very_ clear about direction, but if people decide to ignore proper documentation and change it at mood, there's nothing we can do against that really. If you accept this, you also accept that there cannot be a disambiguous tagging ever and this will then have nothing to do with a particular tag set in question.

The real problem is that people go and change documentation and wonder afterwards that the meaning is a different one than before.

comment:75 in reply to:  73 Changed 17 months ago by anonymous

Replying to anonym:

Maybe "right-handed" "left-handed" and "both" are actually the simplest values for cycleway:direction

The simplest thing is to accept hard facts, instead of toying around with them.
Re-iterating, although it has been stated very often before and is by no means bound to my personal opinion:

cycleway:left - refers to the left of the osm way as given by the order of its node list
cycleway:right - refers to the right of the osm way ..

any oneway= or *:oneway= with a value of

  • 1 or yes encodes a legal oneway along the direction of the osm way ..
  • -1 encodes a legal oneway in opposite direction of the osm way ..
  • no simply means that travelling both directions is legally allowed (regardless of the direction of the osm way ..)

Any of that is agnostic to ancillary conditions, its really basic and very simple if you just stick to it.
There's no influence by the nature of the traffic system or any other side conditions.


And the most wonderful thing is, if you stick to that, its easy to write a parser and render maps based on that. If you live on the polymorph side of things, and if values can mean this or that based on that or this, well you probably have a very hard time making any use of the data.

comment:76 Changed 17 months ago by anonymous

Standards and "hard facts" are not the same. If this was for work I'd be happy with either standard as they both work just fine, objectively, as does the third and still most used standard of not tagging direction at all except two-way since reverse cycle paths almost don't exist. The only issue here is meeting OSM needs of things being intuitive to as many people as possible.

Anyway, regarding the styles, the computations are made significantly more ugly by the lack of tools in mapcss. We're mapping 6 lanes of bicycle traffic. For example after getting a left_dir =-1 or 0 or 1
and a right direction it would be great to find out which directions are now covered by the two sides together and use the inverse as a mask for which access rights to display. If we had even some combination of arrays, loops, functions, or bitmap logic, this would all be much easier. 0 is not a great way to represent [ 1, 1 ] in calculations. Oh well.

comment:77 Changed 17 months ago by anonymous

And by either I mean of course allowing yes to not change the direction, as it is now, or for yes to mean, mean "yes, in the direction of the way". They both clearly, objectively, work if standardized.

-Doug

comment:78 Changed 17 months ago by mkoniecz

Can you consider moving this discussion to place suitable for it? Tagging mailing list of the OSM Wiki? Not in "Cycleways map paint style emphasizes cycleway=lane more than cycleway=track" ticket?

comment:79 Changed 17 months ago by stoecker

Resolution: wontfix
Status: newclosed

This discussion does not belong here. This is a bug tracker and no forum.

comment:80 in reply to:  69 ; Changed 17 months ago by Doug

Replying to anonymous:

Sorry, yes, if we change something we should take it to the wiki. I'm doing real work on I think a significant encoding, and maybe it will or won't replace cmuelleas, at the moment it's targetted to look very similar, but maybe I get a little flexibility as being the guy doing some work at the moment. For the moment I think it's easier to discuss here at this level of nuts and bolts than on a wiki and if we really think we find some discrepency or thing that needs addressing, that has to go the wiki, but maybe in a simplified form.

I am still looking for archive that could enforce the cycleway:left=lane + cycleway:letf:oneway=-1 instead of cycleway:left=opposite_lane. I am ok with the two way even if I prefere the seconde one*. I just would like to have some information about the acceptation of the way to tag opposite lanes

For what it's worth, that wasn't me. It turned out the issue in the bug title was related as much to cycleway=* vs cycleway:*=* as it was to lane vs track once I dug into things. I'm happy to have found how the tags ARE used and that they are in fact used consistently so I can make an updated renderer in a similar style. The original bug response did suggest I try. Redefining standards is not something I claim authority over and actually opposite_lane is very clear and easy to interpret.

-Doug

comment:81 in reply to:  80 Changed 17 months ago by anonymous

Replying to Doug:

Redefining standards is not something I claim authority over and actually opposite_lane is very clear and easy to interpret.

Adding opposite_lane to the style, because empirical studies show that it's used, is ok, but please stop claiming that its easy to interpret. It is inherently dependant on side conditions, i.e. where the tag as used. It is therefore not universal and not self-describing.

(Re-read this thread: It's very easy to get confused when reading terms like "direction of way" - which direction is meant? The one resulting from an applied tag, or the one given by the osm geometry (order of node list)?)

The other approach (*:oneway=*) is universal and therefore easier to interpret, admittedly under the premise the doc has been read, but this applies to both methods nonetheless.

Because empirical studies show that both are used, the style should render both. Or in other words, if you seriously rework the style, simply pick up both methods and it will succeed, because the new style then won't be biased.

As for your wish to not redefining standards: You probably will influence the standard, there's really nothing you can do about it. If a significant number of people pick it up and use it for mapping, stakes are high that they will also map according to it - despite the pledge of not tagging for the renderer.

If you succeed in updating the style to not conflict/deviate to any of the methods currently employed, you shall be called a great artist rather than a style developer, me thinks. But in anything you do: Move forward slowly and it will hopefully spare you from disappointments.

comment:82 Changed 17 months ago by Doug

That's not my post. Sorry for the anonymous mess. Weird system here.

Here's the new section of mapcss that figures this. It's actually easier with yes meaning default, because I can ignore the yes value in my parsing entirely:

way[highway]{

handedness: -1; /* drive on left */

}
way[highway]:righthandtraffic{

handedness: 1; /* drive on right */

}

way[highway]{

right_cwdir: eval(prop("handedness"));
left_cwdir: eval(-prop("handedness"));

}

/* Kust ignore yes, which keeps the default, and just set numerical tags directly, and no goes to zero(two-way) */

way[highway][cycleway:left:oneway=~/1|0|-1|no/]{

left_cwdir: eval(tag("cycleway:left:oneway")=="no" ? 0 : tag("cycleway:left:oneway"));

}
way[highway][cycleway:right:oneway=~/1|0|-1|no/]{

right_cwdir: eval(tag("cycleway:right:oneway")=="no" ? 0 : tag("cycleway:right:oneway"));

.. Really not bad at all.

For cycleway:left=opposite_lane, it's perfectly synonymous with cycleway:left=lane unless we want to consider
cycleway:right=opposite_lane and oneway=yes as valid tagging in Germany. By treating them as synonymous I will get that tag "wrong", but I think that tag is just wrong. If someone wan't to tag that, in that case they certainly should use cycleway:right=-1, but I don't think that's the normal clear documented meaning of opposite_lane and I can't imagine it exists in the real world.

For cycleway= there's no choice anyway and yes, you have to figure out which side is the "opposite" side. But that's needed anyway if you're doing cycleway= rendering, as you need to render the non-opposite lane tracks anyway when opposite isn't set. Opposite is just filling in the other branch on a conditional you have to code anyway.

comment:83 Changed 17 months ago by anonymous

That's not my post. Sorry for the anonymous mess. Weird system here.

Sorry ignore that bit.. What you replied to was my post. I was confused but forgot to delete that.
-Doug

comment:84 in reply to:  82 Changed 17 months ago by anonymous

Replying to Doug:

Opposite is just filling in the other branch on a conditional you have to code anyway.

True, unless you don't want to render the legally allowed direction at all. E.g. on low map zoom scale you often only care about if any cycling infra is present, not about its specific details.

Your mapcss code depends on ':righthandtraffic' which is afaik not a tag. You'll get this 'for free' in JOSM's implementation of MapCSS, me thinks - this check may (currently) not be portable, you'd have to check that.

Anyway, this is what I was refering to the whole time: With the *:oneway={1,-1} depending on the direction of the osm way (as given by order of node list) you do not need this check and these will work in software that does not implement ':righthandtraffic'.

If ':righthandtraffic' check (or an equivalent) is part of most toolchains you could ignore my objection, but consulting https://wiki.openstreetmap.org/wiki/MapCSS/0.2 for example, support already ends. Even if all MapCSS implementations do implement it, tools remain that process osm data without relying on MapCSS. (Which means, if the style would indeed influence people to use opposite* values more regularily, those tools would need to learn the extra logic if they were to make data processing decisions based on the data. The implementation effort, to interpret tags based on the location they are employed at, may be reasonable, but its not negligible)

Side note: pgmapcss does seem to support ':righthandtraffic', so your style in its current form may port to applications making use of that.

comment:85 Changed 17 months ago by anonymous

Porting is another thing. It's a useful point. Is inside() portable? Surely yes, or something like it. I'd suspect someone has already done the work that way if it is. Just need a list.

comment:86 Changed 17 months ago by anonymous

Also I agree that it's usually enough to know cycling infrastructure is present. Even if it's one-sided that usually means there's some reasonable-ish way to go to and fro on that street or the next one. This is why cycleway= tags are usually fine. I don't think most routers can or will soon if ever deal with situations where it's actually impossible to cross the street to get to the needed cycle track, not without mapping it as separate ways, which is probably sensible then. Maybe google can sort that out when they release their self-driving bicycles.

comment:87 Changed 17 months ago by stoecker

Again: This discussion does not belong here. This is a bug tracker and no forum. If you want to talk search another place. If you don't stop I'll handle new entries as SPAM and delete them without notice!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain cmuelle8.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.