Change access rendering

[matthijsmelissen]

This pull request proposes changing the look of no/private/destination access.

Currently, the dashes indicating that roads are not accessible are heavy and attract attention to private ways, instead of attracting attention away from them.

In addition, the colours are not intuitive to new users of the map.

This pull request attempts to make access restrictions not as visibly noticeable, while still preserving the information for users that need it. In addition, it aims to make the information more intuitive for a user that is not familiar with the map.

This pull request proposes:

• Gray dashes for roads with access=no and access=private
• Gray dashes for roads with access=destination
• A gray outline for footways with access=no and access=private
• A grayed-out outline for other paths with access=no and access=private

This pull request:

• Resolves access private casing too thick when used on footpaths, service roads etc #278
• Resolves Access restrictions on motorways nearly invisible #2053

[matthijsmelissen]

Screenshots (before/after):

Inaccessible service roads:

A neighbourhood that has banned through traffic:

A residential street accessible to residents only:

A track that is only accessible to the farmer himself.

This valley has many different access restrictions:

These footways are closed off because of construction on the bridge above:

An overview of all different road types:

[kocio-pl]

Nice idea! I don't have much to say about specific road solutions, but at least track and footways examples are great (decreasing visibility instead of increasing it!). However maybe we really want some restrictions to be visible in color? Or maybe "x" signs are possible for access=no?

[HolgerJeromin]

The decreasing visibility works if they are direct beneath. I am not sure if the access is visible on its own

[HolgerJeromin]

Oh, I meant the Footways only

[imagico]

I think for roads this looks OK, for tracks and footways it is probably still an improvement compared to the pink but it is problematic in several points:

• weakening the line color for tracks without weakening the casing at the same time looks ugly
• the gray footways will be more or less invisible on structured background (bare_rock/scree)

[jojo4u]

The idea is very good. Where are the motorway to tertiary examples? More examples for landuse and natural features are necessary to check visibility.

[polarbearing]

In the first post, did you mean "Gray dots ... for destination", not dashes? That's what I see in the examples.

[daganzdaanda]

Very good, makes the map much nicer to look at.

the gray footways will be more or less invisible on structured background (bare_rock/scree)

Yeah. That may be a problem for the mapper feedback loop... don't know how important this is compared to the reduced clutter in all other instances?

However maybe we really want some restrictions to be visible in color?

I was wondering the same. But access restrictions are IMHO not important enough to be so very prominent on this basic style "for all purposes". It's very good to be able to see that there is a restriction of some sort, but it doesn't need to shout "look at me"...

[HolgerJeromin]

And on the main osm page we have routing which can further help to analyze access.

[pnorman]

Looks promising, but I want to have a good look and try it out with the local area.

My concerns are that the grey might be a bit too subtle and light, and footpaths. Footpaths will probably always be a pain for access rendering so we're not going to have perfection there, but it needs to be considered carefully.

I might also review access rendering on other maps to see if there's anything we can learn there

[kocio-pl]

@imagico

the gray footways will be more or less invisible on structured background (bare_rock/scree)

It doesn't bother me when it's access=no/private, since this "is not to be used by the general public". However rendering in such places would be always worth testing.

[pnorman]

I had a look at a residential area with restricted access service roads. I like it on z17+, but I'm concerned that on z16 there's not enough room to put something in the fill

.

We may just have to accept that the rendering there won't be great. It's hardly much better now

I know both motorway_link and service are done by putting dashes inside the fill, but they give quite a different impression.

z16

z17

You don't get the feeling that the difference between a normal motorway(_link)/service and the restricted access ones is the same thing.

[pnorman]

I looked at an interstate on/off ramp with no public access. At NE 175th Street, there is public access. From left to right, Bing, Google vector based, esri

A local bus bay

Here WeGo

Other maps were derived from the same cartography as us or showed no difference

[pnorman]

In this comment I'm concentrating on non-vehicle ways

Footpaths/cycleways

v2.42.0/PR for 16/10413/22437

All the ways in the area have no surface or tracktype tag, part of Sheep Paddocks Trail has no access.

The changes do a great job at avoiding calling attention to the way making it seem like a more desirable route, but the difference looks very similar to the paved/unpaved difference. I adjusted the data in-DB to get this compairson, but look the cycleway and footpath differences

One is a paved/unpaved difference, the other is two paved with an access difference. They're using very similar cartographic language to express different differences.

Tracks

http://www.openstreetmap.org/#map=17/49.27104/-122.64466 with access tags modified

I like this better than the footpath handling, there seems to be a better distinction between tracktype differences and access differences.

v2.42.0/PR

General

If we can't find any solutions to the above I'd be okay with merging as is.

[matthijsmelissen]

I will have a look at this if we can do something do improve the mentioned points, or if this is the best I can do.

[simonpoole]

Please save yourself some work and do not render access=destination at all. The reasons have been given many times, but in case they have gone forgotten see for example: #214 and the may other issues that have been raised on the subject.

[pnorman]

Mentioned as an issue of interest on dev@ on the 18th (i.e. between the two comments above)

[pnorman]

Destination and no access beside each other

I think it's better with a slightly darker inner dash, shown here with #dddddd.

For z17+ service roads the no access dash pattern is 18px long with about 50% filled. The destination pattern is 9px long with about 25-30% filled. Should the length of the destination be increased? Here's what it looks like changed from 0.1,9 to 0.1,15

[Ircama]

Nice initiative.

Just a comment if I am allowed. IMHO the gray color looks fine to reduce noticeability but the dashes might be too thin and long, so I´m wondering whether they could be confused with some kind of two-way road symbol.

[dieterdreist]

I think this could be confused with some pedestrian related access feature, because the same colour is chosen.

[pnorman]

dashes might be too thin and long, so I´m wondering whether they could be confused with some kind of two-way road symbol

I know the type of cartography you're thinking of. I've normally seen it as a thin solid dark line on printed maps. There's some risk of confusion but I think it's okay, and the other options have worse downsides.

[pnorman]

I think this could be confused with some pedestrian related access feature,

Which this do you mean? There's a few things here. Could you provide an example rendering that shows the potential problem?

[dieterdreist]

2016-08-27 12:35 GMT+02:00 Paul Norman notifications@github.com:

Which this do you mean?

"because the same colour is chosen.". All of them which use the same colour
than pedestrian areas.

[pnorman]

I'm 👍 on merging this as-is and then doing improvements as additional PRs, but I'd first like to deal with some of the other easy PRs before tagging.

[matthijsmelissen]

Fine with me.

[matthijsmelissen]

I had another look at this, and personally I don't really have ideas on how to improve on this. However, pull requests with further tweaks are every welcome.