Add missing oneway arrows for tracks and paths #3614
Conversation
jeisenbe
force-pushed
the
path-oneway
branch
from
66d4f9d to
0eda58f
Compare
z17
@pnorman would you like to see changes for footway, cycleway or highway=track as well? I think there is some utility in matching the arrows to the color of the highway=* in cases where there are parallel paths close together, but slightly darkened arrows would still be readable as related to the original color. |
|
Here's another test area, showing all 5 different track grades with the track oneway arrows. This also allows us to see the other arrows in a different orientation.
|
|
Another cartographic option is to move the arrows off of the line. This makes it possible to keep the arrows close to the path fill color. It looks especially good for one-way cycleways or paths which parallel a road on both sides - but only for one direction of travel; left-hand or right-hand (i.e. Continental vs British Empire). 65% of the world population travels on the right-hand side of the highway - not an overwhelming majority. Right-hand: Left-hand: z16 z17 Circular and curved roads and paths: Compared to the previous idea with darker arrows (all darkened 5%, except steps 10%) |
|
Arrows of bridleway and track (especially tracktype=1-4) are not well readable when located along the path |
|
Would/should fix #1937 too |
|
I like the idea of it being on the side of the path. Except where the symbol would overlap a road, like in the second to last test rendering. It would be interesting to see another exemple like that where the road is also one way. It would probably be either A. confusing or B. one arrow would out render the other. @jeisenbe, wasnt there a propsal a while back to make track roads or paths render more like regular roads since they aren't very visible in the first place (I think like the German style or something)? Maybe its worth revisiting. I kind of like the idea. It would give a better area for the arrows and showing paved or not later. As it is, on the path doesnt look great and off has its own issues. |
|
That’s true, changing the path style might help make the arrows more
legible.
I had hoped this could be a simple fix, because it was meant to revert the
arrows to the way they used to be rendered a year ago.
But if the old one-way arrows style is not acceptable, then we can consider
more significant changes.
…On Wed, Jan 2, 2019 at 8:17 AM Adamant36 ***@***.***> wrote:
I like the idea of it being on the side of the path. Except where the
symbol would overlap a road, like in the second to last test rendering. It
would be interesting to see another exemple like that where the road is
also one way. It would probably be either A. confusing or B. one arrow
would out render the other.
@jeisenbe <https://github.com/jeisenbe>, wasnt there a propsal a while
back to make track roads or paths render more like regular roads since they
aren't very visible in the first place (I think like the German style or
something)? Maybe its worth revisiting. I kind of like the idea. It would
give a better area for the arrows and showing paved or not later. As it is,
on the path doesnt look great and off has its own issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshDwrhGAvmwIrGs4M1j6V8B02oEA9ks5u--yfgaJpZM4ZlV5_>
.
|
|
I can understand that. From my experience openstreetmap-carto and simple fixes don't usually go together, but its always worth a try anyway ;) |
Did you found out with which commit we lost the arrows? |
|
Did you found out with which commit we lost the arrows?
No. I suspect it happened the last time that the project.mml file was
significantly changed in this area.
I wonder if there is a way on git or github to find the last change to a
line of code?
|
|
You might be able to do an advanced search in the search box for any closed PR that has a specific word in the code. Or if not, at least by commit message. https://help.github.com/articles/searching-issues-and-pull-requests/ I know it at least does it by key words in PR messages. |
Git: git blame [filename] |
matthijsmelissen
changed the title
|
Related to Any ideas about how to do this? Otherwise, darkening the arrow color and moving the arrows off of the line are the two best options, as shown above. |
Fixed rendering of arrows on footways: these will always use the footway color, rather than changing if there is designated=bicycle or designated=bridleway Fix bridleway arrow color: based on brideway color instead of track color now. Fix merge conflict in project.mml
Steps 50%, bridleway 25%
Also check for oneway = -1 to make sure text and arrows are on the correct side of the path Fix whitespace & simplify oneway arrow code for paths
|
(Or go the more complicated but good route and change paths to render more like roads first. Then this wouldnt be an issue. Plus, there would be other benefits) |
|
I've pushed several commits that show the code changes for the different options in the previous test renderings. The most recent commit has the arrows off of the path. |
That's also an interested idea, I forgot about that. I've just downloaded the German and French styles to see how they work, but I thought it may have only been the footways that were changed? There still might be an issue with track roads, bridleways and cycleways to consider. |
|
Here are some real-world renderings in the Netherlands, land of the cyclepath: This road is only a few meters wide and has one-way cycle paths immediately next to it, so they overlap with the road rendering. This is a challenging rendering situation: At z18 the version with the arrows to the side could be confusing, because the path is partially covered by the road. This is an unusual situation but can happen with a one-lane road like this. z18 arrows to side This bridge is a more reasonable width: 10 meters between the center of the two cycleways (33 feet) A one-way path (MTB trail?): One-way footway(?): One-way track road: |
|
I think originally it was for footways. Track roads etc could be more view-able though and they would also benefit from paved/unpaved rendering later on. A while back I was screwing with an idea of having them render similar to normal roads, but with the brown colored dashes (or whatever they are) larger and inside of the road (I've always wondered why that wasn't explored as an option for showing paved/unpaved). Kind of like this |
|
One-way steps (an escalator in a mall in Harburg, Germany): Arrows to side |
|
When looking to the MTB trail example, I'm wondering if it would be better to also apply opacity to arrows |
|
@jragusa, see #3614 (comment) |
|
I haven’t been able to find the PR where the arrows were removed. I tried
`git blame` but it wasn’t clear what happened.
Was this discussed at some point?
…On Fri, Jan 11, 2019 at 7:12 AM Paul Norman ***@***.***> wrote:
- a simple bug fix for a regression
I don't view it as a bug fix. Removing catch-alls and only rendering
arrows on explicit objects caused arrows to disappear from non-motorized
ways. I believe this to be intentional.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshGVOJsuY6UxlD1z5Gr-pD5PmgplDks5vB7q9gaJpZM4ZlV5_>
.
|
I'd go for using
For the purpose of this style, highway=path is turned into highway=footway or highway=cycleway. |
|
Perhaps oneway=no is more interesting to render. But i have not checked the usage |
|
For the purpose of this style, highway=path is turned into highway=footway
or highway=cycleway.
Right. A highway=footway can have bicycle=yes, and a highway=path can have
bothe bicycle=yes and foot=yes. In either case it might be one way for
bicycles.
A number of paths on bridges in Portland, Oregon could be tagged this way;
the sidewalks are used for one way bike travel (actually some are two-way,
so it’s useful to show the difference)
… |
|
Ok, i will try to comment without making assumptions on if parts of this is a bug fix or not. To me oneway arrows on steps definitely make sense. In particular for escalators where up and down might be separated and it is important for navigation to know which is which. But for escalators there is also conveying=* which is more common than oneway (not sure how many have both). Also often a direction arrow is of little help with steps when incline=* is not rendered. So improving rendering of steps to be more meaningful is kind of a separate matter. Almost 10 percent of highway=cycleway (100k) have oneway=yes but only 6000 of nearly 10 million footways. path: 20k of 7 million (many of them probably foot=designated + bicycle=designated), track 5600 of 15.7 million, bridleway: less than 1000. I see the problem mainly in that cycleways are the primary use case here and there are practical cases where showing oneway arrows is useful - like a large street crossing with various direction segregated cycleway links where oneway arrows would be good to have and important for feedback or downhill mountainbike routes but this strongly interferes with local implicit rules. In Germany for example all road parallel cycleway are legally oneway for bicycles unless designated otherwise. Therefor tagging those oneway=no makes more sense and showing this like @HolgerJeromin would be more significant. Oneway footways are a highly specialized thing and usually not really a legal "you may not go in the other direction" but more of a "this is the normal direction you are expected to go of you do not want people to think you are weird". For track and bridleway i don't know. Would be helpful if someone would extract those 5.6k from a planet file for reviewing. In general when showing oneway arrows for non-motorized traffic it might also make sense to start later than z16. I am not opposed to this change as is but my recommendation in principle would be to separate into different matters (which could of course all be tackled either with or without this PR merged):
|
|
Rendering the arrows a zoom level later is a reasonable idea, but I had
been hoping to keep the number of changes down, since several maintainers
have said that they prefer simpler PRs.
One of the main reasons to show the arrows, even on tracks and bridleway,
is to help mappers find mistakes which will affect routing applications.
It’s a pain when a router sends you the wrong way, or mistakenly avoids a
path because it is mistagged as oneway.
…On Fri, Jan 11, 2019 at 8:38 AM Christoph Hormann ***@***.***> wrote:
Ok, i will try to comment without making assumptions on if parts of this
is a bug fix or not.
To me oneway arrows on steps definitely make sense. In particular for
escalators where up and down might be separated and it is important for
navigation to know which is which.
But for escalators there is also conveying=* which is more common than
oneway (not sure how many have both). Also often a direction arrow is of
little help with steps when incline=* is not rendered. So improving
rendering of steps to be more meaningful is kind of a separate matter.
Almost 10 percent of highway=cycleway (100k) have oneway=yes but only 6000
of nearly 10 million footways. path: 20k of 7 million (many of them
probably foot=designated + bicycle=designated), track 5600 of 15.7 million,
bridleway: less than 1000.
I see the problem mainly in that cycleways are the primary use case here
and there are practical cases where showing oneway arrows is useful - like
a large street crossing with various direction segregated cycleway links
where oneway arrows would be good to have and important for feedback or
downhill mountainbike routes but this strongly interferes with local
implicit rules. In Germany for example all road parallel cycleway are
legally oneway for bicycles unless designated otherwise. Therefor tagging
those oneway=no makes more sense and showing this like @HolgerJeromin
<https://github.com/HolgerJeromin> would be more significant.
Oneway footways are a highly specialized thing and usually not really a
legal "you may not go in the other direction" but more of a "this is the
normal direction you are expected to go of you do not want people to think
you are weird".
For track and bridleway i don't know. Would be helpful if someone would
extract those 5.6k from a planet file for reviewing.
In general when showing oneway arrows for non-motorized traffic it might
also make sense to start later than z16.
I am not opposed to this change as is but my recommendation in principle
would be to separate into different matters (which could of course all be
tackled either with or without this PR merged):
- more meaningful rendering of steps possibly indicating conveying=*,
incline=* and oneway=*
- rendering of direction restrictions and permissions on cycleways
taking into account that there are implicit defaults that likely vary
between countries
- analyzing the quality of oneway tagging on track, bridleway and
footway if it makes sense to render oneway arrows on those.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshJHfkBeo_2UEXzzrun-HSEFrTwJPks5vB88HgaJpZM4ZlV5_>
.
|
This was unintentionally removed and would prevent the rendering of name labels for under-constructions paths
Simplify current PR by removing the changes to text-dy for path name labels, which had been intended to make sure that the text was always on the same side as the arrows if these were rendered next to the line
|
I removed a minor change to the text-dy for path name labels, which would have been necessary if using arrows next to the path rather than on top of it, but is no longer needed, and I fixed a mistake that would have stopped the rendering of the names of under-construction paths. I believe everything is now working properly. |
|
I'm holding of merging this until we find out when and why the arrows were removed in the first place. Would be great if somebody could find this back. |
|
Does anyone know a commit or version where the arrows were last shown, so I
can use `git bisect`? I don’t want to start back in 2015
…On Sat, Jan 12, 2019 at 7:46 AM Matthijs Melissen ***@***.***> wrote:
I'm holding of merging this until we find out when and why the arrows were
removed in the first place. Would be great if somebody could find this back.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshNVmc2BOSAr-EKP_bV3AKAHC-hwuks5vCRRAgaJpZM4ZlV5_>
.
|
|
@jeisenbe |
|
Also it looks like #2342 fixed the rendering of one-way arrows on roads, but probably it was missed that they were still not rendering on paths. There was never any discussion about removing the rendering of oneway arrows from paths; this was an unintentional change. |
Perhaps this is true in the Netherlands, which has world-renowned bicycle infrastructure However, the UK, USA and other English-speaking countries are notorious for having one-way cycleways only on one side of a street (you get to ride with motor vehicle traffic on the other side), and having complicated ways to access one-way cycle paths on bridges, and at major intersections. We also have a number of one-way mountain bike trails. Another situation that has been mentioned are one-way "via ferrata" in the mountains, foot/climbing paths. |
|
I checked Singapore, which is relatively well-mapped. There are 111 ways tagged with oneway=yes and highway=path, =cycleway, =footway, =steps, or =track. Cycleway and footway have 39 each, the rest have 6 to 13 occurrences. These examples are the first I found. There are no examples of parallel one-way paths or cycleways on opposite sides of a street, but there are a number of one-way mountain bike paths, one-way pedestrian bridges and steps (at the international border, in a zoo and in a park), and one-way circles for bike and golf carts. z19 Create Tower oneway bicycle path
z17 Chestnut Point Mountain Bike trails z17 Singapore Island Country Club golf cart path z16 HSBC-sponsored "Treetop Walk" (wooden path thru the trees and up hills) z18 Woodlands checkpoint (international border)
z16 Pulau Ubin track road "Jalan Durian"
|
|
I searched a couple more areas. Basilicata (southern Italy) had only a handful of cycleways, and none that were one-way. There were couple of one-way paths near a zip-line: z16 Marcirosa path near Castelmezzano, Basilicata, Italy In Washington DC there are a handful of one-way cycleways, usually on the left side (!) of a one-way street, such as the L Street Cycle Track: (https://www.openstreetmap.org/#map=18/38.90402/-77.04310) The only oneway footpaths were these sidewalks, which are certainly mistagged. However, I suppose it is still helpful to show the arrows in this case, so that mappers realize there is a problem, rather than being puzzled when a routing app sends them the long way around: |
|
Bremen, Germany - there are a number of cycleways and paths, and a few tracks and footways with oneway=yes https://www.openstreetmap.org/#map=17/53.09655/8.87581
https://www.openstreetmap.org/#map=18/53.08297/8.79848
https://www.openstreetmap.org/#map=16/53.0723428/8.8427867
https://www.openstreetmap.org/#map=16/53.0681/8.7594
|
|
Canberra, Australia This capital city was purpose-built in mid-century style, with lots of motorways and roundabouts, including a motorway circling the parliament buildings. I guess they didn't think much about air pollution back then? I've shown the first 2 oneway cycleways and paths that I found by randomly searching. There was only one footway with oneway=yes, and no tracks or bridleways (which are quite rare in this area). Cycleways
https://www.openstreetmap.org/#map=18/-35.42391/149.07949 https://www.openstreetmap.org/#map=18/-35.16602/149.13933 Paths
https://www.openstreetmap.org/#map=17/-35.25670/149.10143 https://www.openstreetmap.org/#map=16/-35.3146/149.0181 Footway
|
|
As this reverts an unintended change, I'd be happy to accept this PR (and certainly the part of the PR reverting this change). I don't have time for a full review now though, is anyone else willing to help with that? |
|
A few more examples of arrows on paths and cyclepaths in Hamburg: https://www.openstreetmap.org/#map=16/53.4893/10.2108 |
|
Since track/path/cycleway are thinner than highway=residential/tertiary/..., why not shift arrows for the formers to z18 ? They look prominent in the two first pictures. |
|
That’s possible. But this PR was originally intended to fix a bug that had
stopped the arrows from rendering on paths, rather than significantly
change the old rendering.
…On Sun, Feb 3, 2019 at 2:58 AM Jérémy Ragusa ***@***.***> wrote:
Since track/path/cycleway are thinner than
highway=residential/tertiary/..., why not shift arrows for the formers to
z18 ? They look prominent in the two first pictures.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshGkJ4YqyogloJHeRkmc6t4IKkUJfks5vJdG7gaJpZM4ZlV5_>
.
|
|
Thanks for this PR, and sorry for the wait! |
|
Thanks!
If anyone finds the problems with arrows on z16, or has other ideas for
improvements, I would be happy to do another PR to adjust the new rendering.
…On Wed, Feb 13, 2019 at 5:50 AM Matthijs Melissen ***@***.***> wrote:
Merged #3614
<#3614> into
master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshJUnJTMeVxLIgSyQLhTiM3MJfu76ks5vMykdgaJpZM4ZlV5_>
.
|
|
The choices made in osm-carto are generally well researched, and I am impartial to the arrow style. Just an inquiry though, did you consider JOSM style arrows (triangle with a colored outline), and if so, what was your opinion of those? |
|
I did not consider that style. This change only affected the one-way arrows
on paths, so they needed to closely match the existing arrows on roads.
…On Fri, Feb 15, 2019 at 6:27 AM jengelh ***@***.***> wrote:
The choices made in osm-carto are generally well researched, and I am
impartial to the arrow style. Just an inquiry though, did you consider JOSM
style arrows (triangle with a colored outline), and if so, what was your
opinion of those?
[image: josmarrow]
<https://user-images.githubusercontent.com/8861948/52818654-9fca0780-30a7-11e9-9290-f0ba6ed4cc3a.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3614 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshIUl3yfKqNJHQBIV3rFOF_KSZw8Dks5vNdSsgaJpZM4ZlV5_>
.
|
Fixes #2865
Fixes #1937
Changes proposed in this pull request:
EDITED: New changes
oneway = -1to make sure text is always on the same side of one-way paths and tracksTest rendering:
(First option, without change to unicode text arrows and halos)
Before
After - first option
EDITED: Current commit:
