Openstreetmap-carto: Render paved/unpaved

[joakimfors]

Would be nice if unpaved (surface=unpaved/gravel/ground/etc etc) roads were rendered a bit differently from paved (paved/asphalt/cobblestone/etc). Perhaps brown casing?

[lxbarth]

+1

This is an important request as the absence of a style for unpaved roads leads to many roads being tagged as highway=track where they clearly aren't - especially in countries where unpaved major and residential roads are common.

Example:

_Residential areas in Managua, Nicaragua. Brown solid and dashed lines are highway=track where they should be highway=residential + surface=unpaved_

[skorasaurus]

One alternative to not having this included in the OSM-Carto is to use HOT's HDM Carto Styling
The rendering of surfaces (including unpaved) is one key component of our rendering and here's an example of it.

[mibmib]

I agree roads that are unpaved should be rendered differently. In Canada there are many unpaved roads. In Alberta alone 165,000 km out of 226,000 km of public roads are unpaved.
http://www.albertacanada.com/business/overview/roads-and-highways.aspx

[ftrebien]

+1 for roads in Brazil. We've actually been talking about it in the wrong place (https://trac.openstreetmap.org/ticket/1447). Most drivers here would consider a road "paved" (therefore, minimally safe for reasonable speed even under bad weather) if it had any of these surfaces: asphalt, concrete, sett, or paving_stones. On the other hand, cyclists might not like sett very much. I believe (but I'm not totally sure) that users in countries with better infrastructure or regular snowfall would agree with this as well.

It seems that the file that needs editing is this one: https://github.com/gravitystorm/openstreetmap-carto/blob/master/roads.mss

HDM's MapCSS uses a single rule to override the fill color when the surface is unpaved, see here at line 102: https://github.com/hotosm/HDM-CartoCSS/blob/master/roads.mss

And the "surface" variable gets set here at line 628: https://github.com/hotosm/HDM-CartoCSS/blob/master/hdm.mml

I'm not experienced with Carto or Mapnik, but I'm willing to try and test some similar changes. Could you provide any links that would help me do that? (I'm using Debian Wheezy, but I may adapt.)

[matthijsmelissen]

By memory:

First install Mapbox: https://www.mapbox.com/tilemill/docs/linux-install/ (should be the same on Debian as on Ubuntu)
Then install Osm2pgsql: http://wiki.openstreetmap.org/wiki/Osm2pgsql#Installation
Then follow these instructions: https://github.com/gravitystorm/openstreetmap-carto/blob/master/README.md

Let us know if anything is missing here, it might be good to have these three steps documented somewhere within the project.

[richlv]

for the record, "paved/unpaved" is not suggested, as, technically, compacted is paved, too...
better use specific surface tags like asphalt, concrete, compacted...

[ftrebien]

For rendering we could consider "compacted" as paved too, if that's how it's viewed in most countries.

[joakimfors]

IMHO compacted shouldn't be considered as "paved". It might be nice and firm when it is dry but pour enough rain on it and it will become "mud" like any other unpaved surface. Perhaps a quick and dirty rule: if it erodes during heavy rain => unpaved. :)

[tyrasd]

@richlv In OSM context, a _paved_ road is defined as _“A highway feature [that] is predominantly sealed […], i.e. it is covered with paving stones, concrete or bitumen.”_

[davidbannon]

I am not sure the tag surface= is the right one here. It has a lot of possible values, and a lot of them in use. We'd need a look up table to decide what to do. Better, in my humble opinion to use the tracktype= tag. This tag is intended to show what state the road is likely to be in and thats the information a user really needs. Further, this tag is very widely used.

The Australian Tagging Guidelines on OSM discusses this ( http://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines#Unsealed_and_4wd_Roads_.28Dirt.2C_Gravel.2C_Formed.2C_etc.29 ) and believes that any road with tracktype= asserted needs to be shown so people are aware its not a sealed road.

Please remember that highway= type tags should show what a road is is intended for, further information is needed if the surface of that road is not what might be expected ! This is particularly important in places like the Australian Outback where long distances are involved. Many people have died as a result of them underestimating their ability to use a particular road. I don't want to see OSM mentioned in a coroners report.

David

[matthijsmelissen]

This is also currently being discussed on the tagging mailing list:
https://lists.openstreetmap.org/pipermail/tagging/2013-December/016007.html
https://lists.openstreetmap.org/pipermail/tagging/2014-January/016016.html

[matthijsmelissen]

I think that this is an important issue where all possible solutions have disadvantages. @gravitystorm, do you have any input? Would you support using tracktype on regular roads as a way to render unpaved roads differently?

[gravitystorm]

If we're going to render unpaved roads differently, I'd prefer to use the surface tags and keep tracktype for tracks.

[matthijsmelissen]

Would you prefer to only render surface=unpaved, or keep a long list of unpaved values?

[dieterdreist]

Am 03/gen/2014 um 13:43 schrieb math1985 [email protected]:

Would you prefer to only render surface=unpaved, or keep a long list of unpaved values?

long list

[vincentdephily]

+1 for using surface instead of tracktype because we want to support all kinds of highways.

+1 for using a long list (just one for the "unpaved" cases, and consider the rest as paved ?)

That said, we still need to define the usecase to know what surface goes in which category (and how many categories we have). For example, if I'm driving a truck I'll prefer surface=cobblestones to surface=compacted. But if I'm cycling or rollerblading I'll prefer the opposite.

I do not really care which usecase(s) osm-carto decides to support; just be aware that the choice needs to be made.

[richlv]

paved/unpaved is an old discussion and there are some views that gravel is paved, too, some consider it unpaved... i don't really care much about that.
lately i try to avoid paved/unpaved tags and always use surface tag instead.
on the other hand, for rendering a choice must be made - and here "paved" (or rendered differently) should mean things like asphalt/concrete, otherwise such a render would be of little use

[Rovastar]

If we do decide to render these how do we purpose we do it?

Personally if there is no surface type then they should be rendered as is. So the default is paved. Then have a list of surface types that we want to render unpaved.

However I am unclear how this should look. Should we make them lighter (more logical as not as ' important' as paved roads) or darker (so people know they are different/more potentially perilous.) or dashed in some way or different casing?
all options sound complex/problematic/ugly.

[matthijsmelissen]

I would prefer to use dashed casing. It is easy to implement, it is similar to how other maps display unpaved roads, and people on the tagging mailing also seem to be in favour of this option.

The only risk I see is that it adds yet another rendering style to the large number of rendering styles we already have. It might increase the level of visual clutter, and the difficulties users might have with learning the meaning of the different lines. However, that would be a problem with any rendering style for unpaved roads.

I agree with using paved as default, and that seems to be preferred on the tagging list as well.

[richlv]

for an example render see http://balticmaps.eu/?lang=lv&draw_hash=goiujv&centerx=553766&centery=6275034&zoom=6&layer=map&ls=o

yellowish ones are mostly compacted or gravel roads, darker ones - asphalt.

personally, i'd prefer to render as "unpaved" by default - there is a much smaller set of surface tag values that should be considered "paved" (asphalt + concrete, what else ?) so that would be much, much easier to maintain

as for casing, that might be pretty bad/hard to see on narrow lines

[ftrebien]

I think we have less "disagreement" on the tagging list now about this issue. Instead of thinking of paved or sealed ways, I proposed that the following tag combinations represent "bad" highways (those significantly worse for most people than its best possible state):

• tracktype=grade2/grade3/grade4/grade5 (or simply anything other than grade1, which would support new values such as grade6, grade7, grade8, etc.)
• smoothness=bad/very_bad/horrible/very_horrible/impassable
• surface=ground/dirt/earth/sand/grass

So far, only one user (malenki) wouldn't generally expect grade2 to be in poor conditions. Moreover, nobody has disagreed so far that the following are "potentially bad" (perhaps under bad weather): surface=unpaved/gravel/fine_gravel/pebblestone/compacted

One may have to decide if it's best to represent only those surfaces who are surely bad for general use or also those that are potentially so (which is the one I would prefer). Because of how I phrased that question in the beginning, I think these are tags that "may" be used, we're not required to support all of them. Since "surface" has an open set of values, I wouldn't worry if it's not supported, as long as any of the others are. But I also think that the more relevant tags we support, the better.

Some ways have higher pedestrian usage (highway=residential/living_street/pedestrian/service), so you may interested in considering them as "bad" also when a wheelchair=no tag is present. There was no disagreement on that so far.

This discussion in the tagging list went around many possibilities: new tags to fully describe the surface, a new surface quality classification tag, a separation of the surface tag into paved and unpaved tags, and the choice of a single tag instead of multiple tags. Unfortunately, all of those caused some concerns. You can see if there's any further disagreement on that starting from this message: http://gis.19327.n5.nabble.com/Tags-useful-for-rendering-of-roads-in-poor-conditions-tp5791303p5791712.html

[Rovastar]

I was following the tagging list for a while but it was so long and so many different tag types I think I counted 7 in one mail. Far too complex for the 'simple' CartoCSS.

I think if we are to do this lets just base it on the surface tags as we have discussed before and that seems to be the general consensus here.

[ftrebien]

That's totally acceptable by as far as this complicated discussion went. It just may have the inconvenience in the long run of more requests for support of new surface values. Supporting an extra tag such as smoothness or tracktype would reduce the priority of such updates, requiring only one or two simple extra rules that probably never will change.

[gravitystorm]

Just a comment on the rendering of unsurfaced as dashed casing - my concern is how that fits in with tunnels, and to minimise confusion between the two.

[matthijsmelissen]

Good point. I imagines thinner dashes for unsurfaced roads than for tunnels, but it might still be problematic.

[ftrebien]

I'm not sure it's problematic because tunnels are also rendered in fainter colors. But maybe a different dashing pattern, or shorter/longer dashes, or (as suggested) thinner dashes would help.

[matthijsmelissen]

I think for tertiary and higher roads there is no problem, because tunnels in these roads are indeed drawn fainter, but residential/service tunnels would look very similar to unpaved roads, as these are not drawn fainter. See here: http://www.openstreetmap.org/#map=19/49.60533/6.12901

The solution might also be to change the rendering of residential/service tunnels, of course.

[ftrebien]

I see. Well, maybe the guys at the design list can help us figure out the best solution for the general user.

[dieterdreist]

2014/1/5 ftrebien [email protected]

• tracktype=grade2/grade3/grade4/grade5 (or simply anything other than
  grade1, which would support new values such as grade6, grade7, grade8, etc.)

there is really no indication for tracktypes other than 1-5, see taginfo
for instance:
http://taginfo.openstreetmap.org/keys/tracktype#values

as the tracktype scale is intended to be a complete list from 1-5, I think
it is impossible to later (i.e. now) add more values at the end.

So far, only one user (malenki) wouldn't generally expect grade2 to be in
poor conditions.

add me to this list. grade2 is slightly worse than grade1, and grade1 is
generally assumed to be in good conditions, so yes, grade2 also is not what
I'd call "poor condition".

[ftrebien]

Some people in the tagging list have expressed the desire to add at least one more value to the tracktype tag. If we considered only tracktypes 1-2 as "good condition" and any other value as "bad condition", we would be making our change more resilient to future changes. It would also display incorrectly when users entered a typo or some other invalid value, which I believe would prompt them to correct the mistake. But either way (positive or negative logic) is fine for me as a mapper.

As for which tag values should be considered "good" or "bad" condition, I think it's best not to branch off into Github the long discussion we're having at the tagging list, it's probably best if you repost your opinion about grade2 there where more people can read and decide if they agree or not and why. Some have already started trying to summarize those many opinions and yours should count.

[dieterdreist]

Am 07/gen/2014 um 21:02 schrieb ftrebien [email protected]:

If we considered only tracktypes 1-2 as paved and any other value as unpaved,

usually only grade1 is considered as paved or with similar characteristics (I.e. smooth compacted hardcore).

[richlv]

please do not advocate rendering any tracktype as paved. that would make such a distinction useless.

i'd suggest to keep it simple and i like the list of "asphalt, concrete, sett, or paving_stones", provided in comment https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-28198956 above. simple, short, easy to explain, reasonable.

[vincentdephily]

please do not advocate rendering any tracktype as paved.

highway=track _can_ be paved at high quality.

But because tracktype is specific to tracks, and overlaps surface/smoothness, I'd say we ingnore the former and use only the later, keeping this stylesheet simple.

[ftrebien]

Paved/sealed/good condition are different expressions used this debate that would influence results differently. We probably still need to pick the best one (and I suggest "good condition" because some unpaved types of roads may still be fine for normal traffic). Maybe we could think of values of those tags that remain in good condition even under bad weather (such as under rain). I'm not sure how vehicles would interact with gravel under rain and whether such roads will remain in good condition after it, probably different types of gravel would behave quite differently, that's why I introduced the expression "potentially in bad condition". We still have to decide if we're going to represent only those that are almost certainly in bad condition or also those that have significant potential for bad conditions.

[PauloCarvalhoRJ]

+1 here.

[matthijsmelissen]

I'm still not very sure on how to render this. Using dashed outlines is not sufficient because they are barely visible. We should also avoid confusion with tunnels. Any ideas?

[ftrebien]

What do you think of adding a dashing pattern to the body of the way, similar to steps but light grey instead of red? Here's a quick preview of what I'm imagining on a tertiary, a residential and a primary way: http://i.imgur.com/H3TFG4F.png

[davidbannon]

Generally, on printed maps in Australia, they are show as coloured
dashed lines. So, larger, important roads are wider with a continuous
casement and dashes appearing inside that casement. Lesser roads just
have dashes, usually in the same colour as a similar, sealed road.

Some maps go as far as showing more dash and less space for better roads
and visa versa for worse ones but that may well be a bridge too far away
at present !

The current OSM map key (when zoomed in enough) shows "Unsealed road" as
dashed at about 50% in grey. That would be fine for much of the need. It
also show a "Railway" much as I describe for more important unsealed
roads so thats an issue. Maybe a case of choosing the colour carefully ?

David

On Mon, 2014-05-26 at 14:30 -0700, math1985 wrote:

I'm still not very sure on how to render this. Using dashed outlines
is not sufficient because they are barely visible. We should also
avoid confusion with tunnels. Any ideas?

—
Reply to this email directly or view it on GitHub.

[nighto]

Perhaps adding a 2px/3px brown solid border to the ways?

[matkoniecz]

It would make unpaved more prominent that paved.

[ftrebien]

As it was pointed out by Mathijs in tagging@, dashing patterns need to be well thought out to avoid confusion with the current dashed style used for paths. Most tracks in lxbarth's example have been reclassified as living streets and paths and now the rendering is very legible to me (but maybe the map is now "logically" incorrect since these may not really be living streets in the legal sense). One of the problems to be handled is that tertiaries (and even secondaries and primaries) might be unpaved in some poorer nations, so we may need a rendering rule that applies to those types of ways too. I only see these options as technically viable right now:

1. Dashing the border of the way with some darker color: may cause confusion with paths (pointed out by math1985)
2. Dashing the filling of the way: may cause confusion with access type
3. Adding a border to the way: would make the unpaved more prominent than the paved (pointed out by mkoniecz)
4. Removing the border from the way: may not be noticeable on darker backgrounds
5. Changing the color of the way entirely, perhaps combining the way's current color with a new color such as brown with 20% alpha: generates even more color variation on the map but may work well if the combination color is carefully chosen
6. Changing the (a) width of the way and the (b) zoom levels in which it appears, similar to service=alley and specially so on unpaved residential/unclassified but not on unpaved tertiary/secondary/primary/etc. which may include certain countryside roads in some countries

We can pick some of these and try to work out the best settings for them, or we'd have to change the rendering of other elements such as path and track (and I think this may make some people quite angry). My opinion is that 1+6b or particularly 5+6a+6b would cause least confusion and would be the most useful choices both for mappers and for regular map users.

[matkoniecz]

We may also stop displaying highway=track with separate style and display unpaved roads with current track style. highway=track would imply unpaved, other highway types would imply paved.

And paved tracks would be displayed like highway=service.

Note that in my country road to field is (almost?) synonymous with unpaved road.

[ftrebien]

I think there is a somewhat significant difference between an unpaved residential/tertiary and an unpaved track in a farm/forest. The former is usually open to the public, whereas the latter in many cases is not. Tracks are usually narrow, so usually only one vehicle can get through at a time (thus represented by a thin line - perhaps also because they're usually nameless), but at least where live (Brazil) unpaved residentials are usually wide enough for 2 vehicles.

And then there is style: if we eliminate the distinction between tracks and other unpaved roads, lxbarth's example at the top will go back to its original look. The dark brown color stands out in the city (but these ways are usually less significant than the nearby residential streets), and the thin line has insufficient space to hold the street's name inside (but it could be a little wider, like a service way). And those ways (different from usual tracks and service ways) should probably be rendered at the same zoom levels as regular urban ways. When we do have very long unpaved and important ways (as some of the remote national routes in Brazil in the Amazon region), one would probably wish to see them without having to zoom in too much. Some of them may even function as primaries in that area and therefore be classified as such.

I'm citing Brazil, but being a country full of contrasts and with somewhat poor infrastructure, I believe similar observations would apply to many other poor countries.

[matkoniecz]

"The former is usually open to the public, whereas the latter in many cases is not. " - access is displayed separately (magic dashes).

But there is another problem - mappers checking their work are likely to be confused by complex rules, what worse it would redefine meaning of currently used symbols what would keep everybody confused for a long time.

[richlv]

a) it would be bad to render tracks same as other roads, current dataset has not been made with that in mind
b) as for rendering, how about a solid line casing for paved roads ? it would make them stand out more and would not conflict with tracks or footways or paths.

[Rovastar]

I am thinking overall for unpaved having a brown casing like the colour of the tracks we have currently. Leaving paved as they.
enough of a distinction for those that need to know but not too radical that it changes everything and we reinvent the wheel.

[davidbannon]

You are aware that unpaved roads can, on occasions be major connecting
roads and therefore need to be shown prominently ? Important to note
that not all unpaved roads are minor, short roads...

Sorry if this has been already raised, I have not been following the
topic due to some personal issues. But acutely interested !

David

On Mon, 2014-07-21 at 02:41 -0700, Rovastar wrote:

I am thinking overall for unpaved having a brown casing like the
colour of the tracks we have currently. Leaving paved as they.
enough of a distinction for those that need to know but not too
radical that it changes everything and we reinvent the wheel.

—
Reply to this email directly or view it on GitHub.

[ftrebien]

+1 davidvannon

[Rovastar]

Yes we understand that paved/unpaved is not dependant on road classification.

[PauloCarvalhoRJ]

I vote for a distinct rendering for unpaved streets/roads.

Road conditions change a lot when it rains, thus driving through unpaved streets and roads is obviously a major concern in trip planning.

This is indepedent of the road inportance ou class.

[ftrebien]

What if the way is unpaved AND important, as in many tertiaries in Brazil in remote places like the state of Amazonas? There would be no visual distinction between an unpaved major way (a tertiary) and other unpaved local ways?

Most roads in Chad are unpaved: there are 124 unpaved kilometers for every paved kilometer [1]. Rendering them all exactly the same would be pretty useless there. This would affect some users, particularly those on OSM working with humanitarian aid. Other countries where this could be a problem are: Laos (74 unpaved km/paved km), Congo Democratic Republic (54 unpaved km/paved km), North Korea (34 unpaved km/paved km).

Some selected statistics that might interest you: Uruguay has more unpaved roads than Brazil (9 and 6.4 unpaved km/paved km respectively), and trailing Brazil closely are Bolivia, Paraguay and South Africa (5.7, 5.6 and 4.6 respectively). The first developed country in that list is Sweden, with 3.3 unpaved kilometers for every paved one, followed by Canada and Australia at 1.5 and 1.3 respectively. That's correct, there are more unpaved roads than paved roads (by length) in Canada and in Australia. This is probably because these countries are sparsely populated.

[1] http://www.nationmaster.com/country-info/stats/Transport/Roadways

[ftrebien]

For readability, this is the ratio of paved road (not street) length to total road length in the mentioned countries: Chad 0.8%, Laos 1.3%, CDR 2.1%, North Korea 2.8%, Uruguay 10%, Brazil 13%, Bolivia 15%, Paraguay 15%, South Africa 18%, Sweden 23%, Canada 40%, Australia 43%.

[pnorman]

There's been a lot of discussion about the need to render unpaved roads, but no one has yet come up with anything that they've taken a screenshot of to demo. Unless someone does so, it's unlikely any progress will be made. A few things to keep in mind are

But there is another problem - mappers checking their work are likely to be confused by complex rules, what worse it would redefine meaning of currently used symbols what would keep everybody confused for a long time

paved/unpaved is not dependant on road classification.

Just a comment on the rendering of unsurfaced as dashed casing - my concern is how that fits in with tunnels, and to minimise confusion between the two.

I don't really see that there's much to be gained by further tagging discussion, or even cartography without some pictures to see what people are proposing.

[ftrebien]

I haven't heard any feedback on this suggestion, maybe because it's not good. What about option 5 from these ideas? I've played with it a bit and got to the following result using 25% multiply blending with color #d09f00:

Quick explanation: vertical ways are paved (no change from current style), horizontal ways are unpaved (with proposed colors), both have the same ways in the same order (2-ry, 3-ry, pedestrian, residential, living street, 1-ry), and the bottom and right edges also show a residential area as background.

Other than this, instead of a dashed border, I'm curious about how a dotted border would look, but it would take me quite a while to get TileMill running on my machine; if someone has configured it thoroughly, it may be worth trying.

I don't see other useful options if we want to:

• avoid making unpaved ways stand out from the rest (as if they were more important)
• avoid redefining the current style of other elements (path, track, etc.)

So, if these suggestions are not enough, we may need to rethink those two constraints.

[pnorman]

I'm skeptical about colour, simply because we have so many road colours already.

[matkoniecz]

In this proposed style darker unpaved roads are more prominent and for me it would indicate higher quality roads.

[davidbannon]

On Sun, 2014-07-27 at 20:37 -0700, ftrebien wrote:

I haven't heard any feedback on this suggestion, maybe because it's
not good. What about option 5 from these ideas? I've played with it a
bit and got to the following result using 25% multiply blending with
color #d09f00: test

nice work ftrebien. I don't think its the solution however, really hard
to see what it is we are looking at.

I really think we need dashed something, either casement or infill. Main
reason, that is how most people expect unsealed roads to be shown. Few
people look up the Key, they guess ! Now, we have some roads with no
casement so that eliminates dashing the casement !

IMHO, we need to show unsealed roads as dashed infill, about the same
dash frequency as already reserved for Track or Byway. So no changes to
width, casement etc. If the road deserves a casement (motorway, trunk,
primary, secondary), then its there, not dashed. For 'other' roads,
white and no casement of course, just dashes. Now, what does that clash
with ? Railways are grey and we don't have grey roads so thats not a
problem. Byways, Bridleway, Cycleways, Footways are all their own
colours so no clash.

ftrebien suggested that "(2) Dashing the filling of the way: may cause
confusion with access type." I don't understand this one, its not shown
on the map key, to what level is this attribute used ? Is it a case
that its not sufficiently prominent that its not on the map key ?

We have to keep in mind that unsealed roads are, statistically far more
common than some of the things we are worried about it clashing with. Is
it time to bite the bullet ?

I have blow away my TileMill install when updated the OS so cannot demo,
can anyone else, easily ?

David

Quick explanation: vertical ways are paved (no change from current
style), horizontal ways are unpaved (with proposed colors), both have
the same ways in the same order (2-ry, 3-ry, pedestrian, residential,
living street, 1-ry), and the bottom and right edges also show a
residential area as background.

Other than this, I would like to see how a dotted border would look
(instead of a dashed border), but it would take me quite a while to
get TileMill running on my machine; if someone has configured it
thoroughly, it may be worth trying.

Besides these things, we don't have many options if we want to:

  * avoid making unpaved ways stand out from the rest (as if they
    were more important)
  * avoid redefining the current style of other elements (path,
    track, etc.)

—
Reply to this email directly or view it on GitHub.

[richlv]

another example from http://balticmaps.eu - asphalted roads have red casing :

[Rovastar]

sorry but I don't like having new separate colours for each one.

I think the only way we are going to do this is a coloured casing.

We currently do not use the colour of the casing for anything but we do use the colour of the fill, hashed fill (access, etc), hashed casing (tunnels)
having a coloured casing means you can still use all the above style scenarios in conjunction with paved/unpaved and avoid confusion.

[davidbannon]

On Mon, 2014-07-28 at 06:47 -0700, Rovastar wrote:

sorry but I don't like having new separate colours for each one.

Agree Rovastar, whole new set of colours does not work, mainly IMHO
because the casual user would not know the colour code.

I think the only way we are going to do this is a coloured casing.

I am not so sure. Some roads do not currently have a casing so adding
even a dotted/dashed one would seem to increase their visibility. And a
colured casing would be very hard to see on a major road, shown, eg, in
dark blue.

I'd prefer a minimal change model, don't change the default, sealed
roads, just add something for those unsealed roads. Dashed infill IMHO !

I still don't see how widely this "access" coding that seems associated
with dashed infill is used. Any examples please ?

David

We currently do not use the colour of the casing for anything but we
do use the colour of the fill, hashed fill (access, etc), hashed
casing (tunnels)
having a coloured casing means you can still use all the above style
scenarios in conjunction with paved/unpaved and avoid confusion.

—
Reply to this email directly or view it on GitHub.

[Rovastar]

There are millions of tagged access values. Have you never seen any?
https://taginfo.openstreetmap.org/keys/access#values

So this is established and, at this stage, I would be uneasy with changing any established rendering that clashes directly for this. Maybe we will review the access rendering in the future but this is also a complex and no doubt lengthy process.

That for me why dashed fill is out. Also again you cannot have access=private and unpaved roads with that we hence why I thinking more about the mostly unused and possibly underutilised casing.

[matthijsmelissen]

I would be interested to see brown dashes as outline, it would be easy to interpret due to the visual similarity with tracks.

[davidbannon]

On Mon, 2014-07-28 at 16:35 -0700, Rovastar wrote:

There are millions of tagged access values. Have you never seen any?
https://taginfo.openstreetmap.org/keys/access#values

No Rovastar, have not seen any ! Was hoping you could point to a place
on a map where its shown so I could see what they look like.

This access=private is not listed in the map key so I don't even know
what to look for ! Interestingly, as its not shown on the key, how do
map users know that particular coding means access=* ?

Do we have any potential to use really short or really long dashed
infill perhaps ?

Would be really hard to have both short and long dashes on a private,
unsealed road ! I see your point.

Looking at the map, I find it quite hard to see the casement on most
roads, exception being unclassified. What effect would a thicker
casement have ? Can we vary the colour behind the dash ? So dashes on a
white background mean access and dashes on a dark background mean
unsealed. Hmm, that combo problem again....

My chief interest here is to address a real problem of many 'outback'
roads here in Australia that are major connecting links but unsealed.
From time to time, people, often visitors, take these roads without
realising that there is some risk for the ill prepared or inexperienced.
Lives have been lost but so far not due to use of OSM. But its just a
matter of time.

David

So this is established and, at this stage, I would be uneasy with
changing any established rendering that clashes directly for this.
Maybe we will review the access rendering in the future but this is
also a complex and no doubt lengthy process.

That for me why dashed fill is out. Also again you cannot have
access=private and unpaved roads with that we hence why I thinking
more about the mostly unused and possibly underutilised casing.

—
Reply to this email directly or view it on GitHub.

[matthijsmelissen]

Example: http://www.openstreetmap.org/#map=16/49.6278/6.1192

Blue is access=destination, red is access=private or access=no (they are rendered the same).

As you can see, access=destination is crucial in Luxembourg, as you wouldn't be able to guess that you are not allowed to use Avenue Pasteur.

My chief interest here is to address a real problem of many 'outback' roads here in Australia that are major connecting links but unsealed.

Do you have an example of these?

[davidbannon]

On Tue, 2014-07-29 at 03:06 -0700, math1985 wrote:

Example: http://www.openstreetmap.org/#map=16/49.6278/6.1192

Ah, I see what you mean.

As you can see, access=destination is crucial in Luxembourg, as you
wouldn't be able to guess that you are not allowed to use Avenue
Pasteur.

Agree.

    My chief interest here is to address a real problem of many
    'outback' roads here in Australia that are major connecting
    links but unsealed.

Do you have an example of these?

Sure, try these popular tourist routes -

Plenty Highway, Northern Territory -
http://www.openstreetmap.org/way/172620251

sandover highway, NT -
http://www.openstreetmap.org/way/174644417#map=8/-21.527/136.313

gibb river road, WA
http://www.openstreetmap.org/way/28335211#map=10/-17.0568/125.3423

David

[matthijsmelissen]

Thanks. How do local maps render these?

[davidbannon]

On Tue, 2014-07-29 at 03:41 -0700, math1985 wrote:

Thanks. How do local maps render these?

Generally, dashed lines. Thicker for more important roads, thinner for
minor.

Taking one of my favourites 'cos its sitting on the coffee table beside
me -

"Major Highways" have a casement, red infill is dashed for unsealed,
solid for sealed.

Then, "major road", "minor road" red lines, dashed if unsealed.

"track 4x4 only", "rough track 4x4 only" red, dashed lines.

Getting thinner as they get more interesting !

ftrebien, can you tell us what is the 'normal' way in your parts of the
world ?

David

—
Reply to this email directly or view it on GitHub.

[ftrebien]

The official map of the state of Roraima (12 MB), made by the National Department of Infrastructure and Transportation (DNIT), might be an interesting example, but the visual language is quite different from Carto. It adopts two colors to represent federal (red) and state (green) roads, and then varies the line type to represent variations of road structure:

• Pair of parallel solid bold lines: paved dual carriageway
• Pair of parallel dashed bold lines: second carriageway under construction next to a paved road (single carriageway)
• Single solid bold line: paved regular road
• Single dashed bold line: pavement underway, currently surface=compacted
• Pair of parallel medium lines connected by spaced vertical bars: surface=compacted
• Pair of parallel thin lines with a dash-dot pattern: compaction underway, currently surface=earth
• Pair of parallel solid thin lines: surface=earth
• Pair of parallel dashed thin lines: planned road

In essence, dashing is used to mean "some kind of construction is/will be going on here".

An extra yellow casing means it is a toll road. You may ignore the green casing as it refers to a slowly ongoing transfer of roads from federal to state administration.

The most popular map in Brazil, called "Guia 4 Rodas", uses a similar language but makes no distinction between federal and state roads (just like the Brazilian OSM community), and also makes no distinction between surface=compacted and surface=earth. Here's an example:

The visual language always uses black casing in addition to:

• Red fill with a yellow central line (likely representing separation): paved dual carriageway
• Dashed red fill with a yellow central line: second carriageway under construction next to a paved major road (single carriageway)
• Red fill: paved major road
• Yellow fill: paved regular road
• Dashed yellow fill: pavement underway, currently surface=compacted
• White fill: surface=compacted/earth

There is also a style for roads in poor condition (smoothness=bad/very_bad/etc.): black squares filling the line (as a big dot pattern) combined with a small increase in line width around the squares. I couldn't find a practical example of this (will try), but meanwhile here's the complete symbol list (in Portuguese):

[joostschouppe]

I'm surprised that after all these years so few proposals have been made as to how to actually do this. As pnorman said, proposals help. So here's my naive shot at it. I'm probably overlooking something, because it felt too simple (I checked contruction and tunnels, does not seem to give trouble).
Idea: why not just do what any paper map does?
Just dashed roads for unpaved, a little stronger outline for paved roads, no change for untagged roads. The stronger outline is not really necesary, but anything that is rendered is more probable to get mapped, so why not?

[joostschouppe]

When it comes to "what is paved or unpaved", keep it simple too. Paved roads are tagged "paved", "asphalt" or "concrete" (including concrete:plates, conrete:lanes).

Unpaved roads are: unpaved, gravel, ground, dirt, grass, wood, pebblestone, fine_gravel, earth, mud, grass_paver, clay

Up for discussion could be: paving_stones, cobblestone, compacted, metal, sett
I would suggest treating these as "unknown". If that makes too many people angry (oh dear), maybe an "unpaved" style with dashed filling but full outline could be tried.

[matkoniecz]

@joostschouppe It would result in ugly map in regions where many roads are unpaved.

BTW, paving_stones, cobblestone, metal, sett are in my opinion obviously paved.

[gravitystorm]

Paved/unpaved is defined on the wiki by the two sections of the table at http://wiki.openstreetmap.org/wiki/Key:surface - please stick to that.

@joostschouppe the devil is in the details, especially with rounded end-caps and line joins, bridges etc. I encourage you to try it out using the stylesheets and Tilemill.

[davidbannon]

Yes Joostschouppe, there have been lots of proposals, usually based on
the widely used (on paper maps) dashed casement. I produced some
examples back before the Tilemill days and updated it when Tilemill was
new. Irreverent now and I cannot justify the effort of doing it again
when it will just be ignored.

Truth is, with so many tags and values claiming to define whats
paved/unpaved (surface= tracktype= hightway= smoothness= 4wd_only and so
on) we need the renderers to show some leadership and pick one. Any
one !

People who live where unsealed roads means little more than a bit of
dust on the paintwork cannot understand that badly detailed maps put
lives at risk.

If we consider pretty maps the only issue, should we have a watercolour
render model ?

David

On Tue, 2014-12-09 at 04:20 -0800, joostschouppe wrote:

I'm surprised that after all these years so few proposals have been
made as to how to actually do this. As pnorman said, proposals help.
So here's my naive shot at it. I'm probably overlooking something,
because it felt too simple (I checked contruction and tunnels, does
not seem to give trouble).
Idea: why not just do what any paper map does?
Just dashed roads for unpaved, a little stronger outline for paved
roads, no change for untagged roads. The stronger outline is not
really necesary, but anything that is rendered is more probable to get
mapped, so why not?

roads

—
Reply to this email directly or view it on GitHub.

[pnorman]

Just dashed roads for unpaved, a little stronger outline for paved roads, no change for untagged roads. The stronger outline is not really necesary, but anything that is rendered is more probable to get mapped, so why not?

The dashed style conflicts with tunnels, and potentially proposed as well.

[richlv]

again, any objections to coloured casing as in https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-50326807 ?

[pnorman]

People who live where unsealed roads means little more than a bit of dust on the paintwork cannot understand that badly detailed maps put lives at risk.

Please stop claiming this is not implemented for reasons like this - it can be insulting to the stylesheet maintainers. The reason it is not implemented is a lack of solid proposals and a complete lack of PRs. As is fairly clear, it's not cartographically obvious how to implement this and trying to persuade the maintainers to implement it is not what needs to be done, what is needed is PRs or mockups of which there have been a total of two.

[pnorman]

again, any objections to coloured casing as in https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-50326807?

Can you show an example of that with openstreetmap-carto? My thoughts are it won't work too well given that we have solid fills with strong colours while the example shown has white fills.

[richlv]

sorry, i've never done that and it would probably take me somewhere between days and ages :)

[davidbannon]

it can be insulting to the stylesheet maintainers.

Paul, it is not my intention to insult anyone and if I have, I apologise
unreservedly.

I was suggesting why we have found it so hard to have this matter
addressed. People who don't understand the need are hardly likely to be
motivated to help resolve it. And without the help of the stylesheet
maintainers, or someone with similar skills, it won't get resolved.

lack of solid proposals and a complete lack of PRs.

I refer you to a six year old ticket,
https://trac.openstreetmap.org/ticket/1447 and from memory, there was
something pre dating that.

I don't know what a RP is, I am sure you are not using it in the medical
sense ! Perhaps you could elaborate ?

I could be wrong, but my guess is that there is many more kilometres of
unsealed road than, for example, tunnels. But in OSM, tunnels seems to
have reserved what is used elsewhere to mean unsealed roads. We'd be
willing to help find an alternative, but without the involvement of the
stylesheet maintainers, its futile.

David

On Tue, 2014-12-09 at 14:48 -0800, Paul Norman wrote:

    People who live where unsealed roads means little more than a
    bit of dust on the paintwork cannot understand that badly
    detailed maps put lives at risk.

Please stop claiming this is not implemented for reasons like this -
it can be insulting to the stylesheet maintainers. The reason it is
not implemented is a lack of solid proposals and a complete lack of
PRs. As is fairly clear, it's not cartographically obvious how to
implement this and trying to persuade the maintainers to implement it
is not what needs to be done, what is needed is PRs or mockups of
which there have been a total of two.

—
Reply to this email directly or view it on GitHub.

[pnorman]

I refer you to a six year old ticket,
https://trac.openstreetmap.org/ticket/1447 and from memory, there was
something pre dating that.

And in the six years there's been two examples given of a modification to the style - https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-50297563 which people thought didn't work, and https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-66274450 which is a day old. To properly judge any proposed changes we really need to see it in the context of the map, i.e. where there is other stuff rendered at the same time.

There has not been an obvious cartographic solution that works with the style to the various maintainers over the last 6 years. We don't need more voices calling for this feature, we don't even need more examples of other maps where the entire style is completely different.

I don't know what a RP is, I am sure you are not using it in the medical
sense ! Perhaps you could elaborate ?

Pull requests.

[dieterdreist]

have you considered bridges within this proposal? I can imagine it is confusing to see a dashed bridge, even more several consecutive bridges.=

[davidbannon]

On Tue, 2014-12-09 at 23:16 -0800, Paul Norman wrote:

And in the six years there's been two examples given ...

And a large number of verbally described examples. And several links to
images that don't exist any more.

Paul, do you honestly require people to go off and build a complete
TileMill install and then understand the style sheet before they can
contribute to this discussion ?

There has not been an obvious cartographic solution .....

No, of course not. Not without the help of the people experienced with
the stylesheet.

David

[gravitystorm]

Paul, do you honestly require people to go off and build a complete TileMill install and then understand the style sheet before they can contribute to this discussion ?

Nobody is obliged to install Tilemill in order to contribute to the discussion, but...

No, of course not. Not without the help of the people experienced with the stylesheet.

... please do not place obligations on other volunteers to do work that you are unwilling to do yourself. Everyone here who is 'experienced with the stylesheet' was once in the same position as you - that is, 'not experienced with the stylesheet', but they invested time and effort to develop new skills.

For different topics we need a continuum of contributions. People can start an issue outlining a problem with the map. Other people (with an interest in the topic) can contribute to the discussion. Other people (with an eye for cartography) can propose changes, and other people (who have installed tilemill) code them, and others review them. Everyone is welcome to contribute at any stage that they feel is appropriate. If the topic is stuck at a particular stage (e.g. patch review) then so be it - complaining doesn't magic up any more volunteers with the particular skills.

Paul has said that for this particular topic, what is needed is some implementations. Please respect that.

I'd encourage @davidbannon - in the same way that I encourage everyone - to dig in, learn how things work and help out further. If you'd like to sett up Tilemill there are instructions and a whole bunch of people willing to help you out if you get stuck. That's the way this topic will move on.

[pnorman]

On Tue, 2014-12-09 at 23:16 -0800, Paul Norman wrote:

And in the six years there's been two examples given ...
And a large number of verbally described examples. And several links to
images that don't exist any more.

Verbal descriptions or examples with a completely different road style don't help move the issue forwards.

There has not been an obvious cartographic solution .....
No, of course not. Not without the help of the people experienced with
the stylesheet.

There isn't an obvious solution to those who are experienced.

[joostschouppe]

Glad to see so many reactions to my little mock-up. Based on the comments here, I don't really feel encouraged to try and make a real proposal. Maybe I'm misinterpreting your words, but it feels like you're expecting a proposition ready for a pull request, but you still want to be able to say "no, don't like it".

If there is no obvious solution, we'll need a less obvious ones. If unpaved roads conflict with something exotic as a planned road, well, change the style for the planned road. Or even keep them for a specialized OpenPlannedStreetMap. That's where the Eurocentrism argument does make sense. Unpaved roads need to adapt to this pretty style we have - while for most of the world it's obviously the other way around.

If, as a community, we couldn't solve this in a six year period, that means our community serves the interests of Europe, not the world. That's not an accusation, but an observation. We're volunteers, so we do what we think is necessary and fun to do. And as most of us are European or urban, we focus on urban, European needs. Those who see the non-urban, non-European needs are not more lazy than you, there's just fewer of them. If we want to change that, yes, maybe we should try harder. I will try and get something moving in the Latin community to make a better proposition than my quick mock-up. But I do think all volunteers should try to work towards an OpenStreetMap that makes sense to as much people as possible. I think people who do already have experience with Tilemill are in a unique position to vastly improve the usefullness in the Americas, Africa and Australia with relatively little effort compared to what other people would have to invest. But of course, don't do it if it doesn't make you happy - volunteers hould keep doeing what they believe in.

I repeat, I will try and keep working on this, and try to get more people involved. But don't frustrate those efforts. I do hope I can count on it, that if we do manage to get a well thought out proposal ready, we will get more constructive feedback than "it's not pretty", or "it means we have to change some other things".

[kocio-pl]

The discussion is long and has many aspects I don't have the time to study yet (though eventually I plan to), so I may say nothing new or miss some points, but I'd like to suggest very limited proposition: let's render the road surface instead of its type only on the highest zoom level. It makes a perfect sense for me in conjunction with area:highway rendering idea (https://github.com/gravitystorm/openstreetmap-carto/issues/180) - on the micro scale it is more interesting what the street/road looks like than what function does it have in the network. When I see asphalt-covered broad street I think of it as a more important than one lane road covered with dust. It is not a 100% accurate way of recognizing road importance, but the primary/secondary/tertiary classification is also not always realistic and we'll still have some hints about it.

I see the problem with rendering access restrictions in the same time, but we can render the surface to look like it typically looks like in the wild (blackish/grayish for asphalt, light-brown for dirt etc), so the dashing will be reserved for access indication.

I think of max-zoom surface rendering as a better reality representation even for big cities in Europe (I live in such a place), but this may also serve as the one foot in the water testing to make sure we got it right before we even try using it wider (for the sake of the rest of the world, as @joostschouppe suggests).

[matkoniecz]

So consensus is that for roads paved should be default.

I think that it may be possible to render surface for highway=track (paved track with tracktype=grade1 would be rendered stronger than unpaved track with tracktype=grade1). Here assuming unpaved would be a good idea.

Maybe it would be possible to display paved/unpaved status also for footways and cycleways.

[matkoniecz]

Some people proposed narrow set of values that would be considered as paved. I think that it would be better to use as many as reasonable.

Therefore I am proposing to consider following values as paved: paved, asphalt, cobblestone, cobblestone:flattened, sett, concrete, concrete:lanes, concrete:plates, paving_stones, metal and wood.

And these as unpaved: unpaved, compacted, dirt, earth, fine_gravel, grass, grass_paver, gravel, ground, mud, pebblestone, sand and clay.

In current situation I propose to treat other tags (mentioned below this line) as equivalent to lack of surface tag and use default surface value.

There are also tartan and artificial_turf - described as a special surface unused for roads and paths.

And there are undocumented tags: cement, bricks, brick, hard, interlock, pebbles and laterite. I asked for documenting these tags on tagging mailing list but it seems to not resulting in any improvement to OSM Wiki.

There is also family of undocumented rock-related tags: stone, rocky, rock, limerock, granite. Here meaning is either unclear (stone, rocky, rock) or too specific (limerock, granite). I proposed on tagging mailing list introducing one documented value to cover tagging solid rock surface but there was no interest.

paving_stones:30 is documented on wiki but considered as a bad idea - see https://lists.openstreetmap.org/pipermail/tagging/2015-March/thread.html#22426

Multiple values in one tag (like ground;grass or paved;unpaved) are considered as not valid.

All other, unmentioned values appear less than 400 times worldwide and together represent 0.22% occurrences of all surface values.

[davidbannon]

On Sun, 2015-05-17 at 01:12 -0700, Mateusz Konieczny wrote:
..

Therefore I am proposing to consider following values as paved: paved,
asphalt, cobblestone, cobblestone:flattened, sett, concrete,
concrete:lanes, concrete:plates, paving_stones, metal and wood.

And these as unpaved: unpaved, compacted, dirt, earth, fine_gravel,
grass, grass_paver, gravel, ground, mud, pebblestone, sand and clay.

I think that makes a heap of sense. If some other tag does become widely
used, it would be relatively easy to add it to one or the other side
anyway, I guess ?

And there are undocumented tags: cement, bricks, brick, hard,
interlock, pebbles and laterite. I asked for documenting these tags on
tagging mailing list but it seems to not resulting in any improvement
to OSM Wiki.

Sorry, I don't use them, I am pretty certain all I have ever used is
"unpaved" !

Most unsealed roads I am familiar with are either well maintained gravel
or a motley collection of surfaces, changing as you traverse just short
distances. I have never seen a (eg) 'rock' road that is rock for its
full length. Honestly, I think most of the problem is solved with the
binary decision [paved; unpaved].

Anyway, more power to your strong right arm Mateusz !

David

[joakimfors]

matkoniecz: Looks good.

[daganzdaanda]

Agree with the groups for paved / unpaved. If needed, adjustments could be made later. For now it would be really great to get any visual indication for unpaved roads.

[dieterdreist]

Am 17.05.2015 um 13:04 schrieb davidbannon [email protected]:

Honestly, I think most of the problem is solved with the
binary decision [paved; unpaved].

for cars yes, for bicycles cobblestones can be a real nuisance, and different kinds of unpaved roads in wet conditions will differ significantly.

[dieterdreist]

Am 17.05.2015 um 10:12 schrieb Mateusz Konieczny [email protected]:

Therefore I am proposing to consider following values as paved: paved, asphalt, cobblestone, cobblestone:flattened, sett, concrete, concrete:lanes, concrete:plates, paving_stones, metal and wood.

And these as unpaved: unpaved, compacted, dirt, earth, fine_gravel, grass, grass_paver, gravel, ground, mud, pebblestone, sand and clay.

almost completely agree, but move the grass_paver to paved (and unsealed), unsure for compacted (tending towards paved).
By usage we might also add to paved: paving_stones:30
tartan
stone
bricks
hard ?
interlock?
cement

maybe it doesn't matter if paved is the default, in this case we should extend the unpaved list at least for values used more than 1000 times

[richlv]

first, discussion about a gazillion of surface values is bikeshedding until a nice and accepted rendering solution is found.

second, it would still be better to treat default as unpaved - that would make the default map "safer" to use. it's better to plan a bit longer route on paved ways than plan a shorter one and result in a fail.

third, if the default is unpaved, it is enough to list whatever is treated as paved and we could avoid spending time on several dozen tags that 'unpaved' could be completely.

[dieterdreist]

Am 17.05.2015 um 19:01 schrieb Richlv [email protected]:

third, if the default is unpaved, it is enough to list whatever is treated as paved and we could avoid spending time on several dozen tags that 'unpaved' could be completely.

that's true, but it will force mappers to add surface tags to every paved road, we should keep that in mind. I'd assume paved as default for motorways, motorroads and trunks at least (on a global level), maybe also primary and secondary. According to the region there will be defaults for all other road types as well, but that would get complex.

Still I like the idea of unpaved per default, with the 3/5 exceptions mentioned above, it will encourage mappers to collect details

[richlv]

i don't see adding surface tag as a bad thing - in some region major ways would be asphalted, in another - concrete covered.

as for defaults, motorways sounds fine, maybe trunk... but i've heard that in iceland an unpaved road can be trunk. in latvia many primaries and most secondaries will be unpaved (compacted). per-region defaults would be overly complex and could be so easily solved by adding surface tag (a useful information in any case), i would find it strange if osm admins would want to bother with that :)

[matkoniecz]

move the grass_paver to paved (and unsealed), unsure for compacted (tending towards paved).

See comment by @gravitystorm

Paved/unpaved is defined on the wiki by the two sections of the table at http://wiki.openstreetmap.org/wiki/Key:surface - please stick to that.

I think that it is a good idea.

By usage we might also add to paved: paving_stones:30

see https://lists.openstreetmap.org/pipermail/tagging/2015-March/thread.html#22426

tartan

is it used for roads/path/footways/anything tagged as highway=*?

stone bricks hard ? interlock? cement

Relatively rare values that are not documented will be not supported (see tagging mailing list for documentation request)

values used more than 1000 times

I considered all valued used 400 and more times worldwide

[joostschouppe]

Binary distinction paved/unpaved sounds good. More details could be shown
when zoomed in.

Tracks are the ones in least need of a surface rendering. If it is a track,
it is going to be a slow road. It is in areas with a less developed road
network that this information is most valuable. In countries like Bolivia,
Peru and Argentina, maybe half of all trunk roads are unpaved. Regional
decisions are difficult: in Ecuador, Chile and Brazil almost all unpaved
roads are classified tertiary or lower.

Agree on unpaved as default. Sounds like a good way to make the kind of
ugly map all mappers will want to fix by cleaning data as soon as possible.

[kocio-pl]

I guess on the highest zoom levels (z19 for sure) we should not care much about red/yellow/green/blue as a symbol of road category, but rather start rendering highway areas and the paving status could be shown here somehow, because area gives us more space to show details.

[davidbannon]

On Sun, 2015-05-17 at 12:15 -0700, Joost wrote:
...

....In countries like Bolivia,
Peru and Argentina, maybe half of all trunk roads are unpaved.

This is the key IMHO. A trunk road needs to be rendered when zoomed out
but its important to show if its unpaved.

A while ago I suggested use of tracktype= should change the default
paved to unpaved. The original definition of tracktype= was to be
applied to any highway= way. It is intended to grade unpaved roads.
But if its practical to render on the basis of long list of surface=
values, I'm fine with that too.

Trouble is, at present as there are many possible approaches and none
appear on the authoritative map, people are looking for some leadership.

David

[joostschouppe]

David, I don't really know in the rest of the world, but in South America,
the mileage mapped with surface is hundreds of times the amount mapped with
tracktype.

[pnorman]

We need some way to indicate paved, unpaved, and possibly unknown. The tags for each state don't really matter right now, given it's the cartography issue that's the blocker, not details of tagging. Let's try to stay focused on what is the issue, not what isn't.

[dieterdreist]

Am 18.05.2015 um 08:34 schrieb Paul Norman [email protected]:

We need some way to indicate paved, unpaved, and possibly unknown.

see these options:

• colour of the casing
• linestyle of the casing
• intensity/faintness of the whole way

I have excluded colour and linestyle of the filling because that would likely become too much (confusion with tunnels etc)

I also excluded linewidth because this seemed not intuitive and difficult to communicate via a legend (because the widths already vary a lot along zoom levels and road classes)

The colour and linestyle distinction will probably need a legend to be understandable while the fainter whole way might eventually be confused with tunnels/covered ways

Transparency should be avoided because of complex intersections, bridge rendering etc. (or would require a major rewrite of the rules and new layers for the transparency to be applied to)

I could imagine something like a red casing or light grey casing (if red is too obtrusive) for unpaved roads, leaving paved roads as they are now. Problems could arise for colour blind people maybe?

[richlv]

casing/borders should be applied to paved roads, otherwise unpaved would stand out more. the opposite should be the goal.

[davidbannon]

On Mon, 2015-05-18 at 00:12 -0700, dieterdreist wrote:

We need some way to indicate paved, unpaved, and possibly unknown.
.....
I have excluded colour and linestyle of the filling because that would
likely become too much (confusion with tunnels etc)

if you look on the map key, more zoomed in, yu will see a grey dashed
line means "unsurfaced". I don't think I have ever seen this rendered
anywhere (?) but I think its a good starting point. Not the grey but the
dashed infill. For larger roads that get a casement the casement stays
intact and the infill becomes dashed in what ever colour the road needs
to be (according to its function).

Thats very intuitive to a map reader IMHO. And how printed maps have
traditionally been show here as well.

As we zoom out and the casement disappears its does start looking a bit
like tracks, byways and bridleways however.

One option is to vary the percentage of on/off with the dashing. Say 75%
coloured, 25% transparent would look quite different to the above. I
don't think we have 'byways' or 'bridleways' in my part of the world.
And few tunnels incidentally.

I could imagine something like a red casing or light grey casing (if
red is too obtrusive) for unpaved roads, leaving paved roads as they
are now. Problems could arise for colour blind people maybe?

Casing does seem to be very hard to see on some zoom levels already. A
light grey on a light grey background ? Hmm....

David

[pnorman]

if you look on the map key

We don't have a map key for openstreetmap carto really. The key on osm.org is not maintained by us, or by anyone.

One option is to vary the percentage of on/off with the dashing. Say 75%
coloured, 25% transparent would look quite different to the above. I
don't think we have 'byways' or 'bridleways' in my part of the world.
And few tunnels incidentally.

Could you provide an example as a branch, then we can see how it renders in different parts of the world?

[kocio-pl]

We don't have a map key for openstreetmap carto really. The key on osm.org is not maintained by us, or by anyone.

Although it's located on a Wiki and it's fresh, now we have detailed and maintained map key.

[davidbannon]

On Mon, 2015-05-18 at 19:00 -0700, Paul Norman wrote:

We don't have a map key for openstreetmap carto really. The key on
osm.org is not maintained by us, or by anyone.

Really ? The one that appears on osm.org ? Perhaps it needs to be
removed, or the link to it at least ? Mind you, it does look 'mostly'
right....

    One option is to vary the percentage of on/off with the
    dashing. Say 75%...

Could you provide an example as a branch, then we can see how it
renders in different parts of the world?

Me ? No Paul. As I have mentioned in the past, I don't have check in
access and that's good because I don't have the skills or expertise
necessary, I'd do a terrible job.

David

[gravitystorm]

Really ? The one that appears on osm.org ? Perhaps it needs to be removed, or the link to it at least ?

It's outdated. It was created years ago and hasn't been updated, but it's mostly right because most features still look the same as they did 7(!) years ago when it was last updated. I know it's a problem and I have a plan to fix the situation, but I'll leave it for other people to decide whether having an out-of-date legend is more helpful than not having one at all.

The 'unsurfaced' entry in the legend refers to a feature and a method of tagging that was removed a long long time ago.

I don't have check in access and that's good because I don't have the skills or expertise necessary, I'd do a terrible job

You don't need 'check-in access' (aka commit permissions) in order to help us with the stylesheet. You've suggested a particular rendering change, and what Paul is doing is encouraging you to try it out yourself. You might find it works great, or you might find 85% looks better, or you might figure out a better way to do it entirely, but trying it out in Tilemill and sharing the suggested code changes with us (aka making a pull request) is immensely more useful than writing suggestions in text boxes and waiting for someone else to try it for real.

And none of us had the skills or expertise - until we got started!

[kocio-pl]

I'll leave it for other people to decide whether having an out-of-date legend is more helpful than not having one at all.

If it was me, simply having a link for this Wiki page would do.

[ftrebien]

I like @joostschouppe 's proposal (fill dashing) because it would blend intuitively across various zoom levels. Up to level 8, unsealed ways could be rendered as a simple dashed line with their current colour. They would look like paths but I expect no confusion because paths only start showing at zoom level 13, have a darker neutral colour and are very thin. Things possibly worth changing (I hope I can try them on Tilemill soon):

• having a continuous (non-dashed) outline to improve clarity against similar backgrounds, such as: trunks beside vegetation, primaries beside commercial areas, secondaries beside farmland, tertiaries beside parking areas, and pedestrian and living streets beside residential areas
• having a completely filled dash (similar to "construction" ways) at zoom level 13 to improve readability of street names and for easier combination with access restrictions (particularly on residential and living streets)
• the dash would be filled with a slightly darker shade of the way's colour to convey the idea that the way is in subpar conditions (a lighter tint would cause confusion with "construction"); this effect could be achieved by an overlay, similar to how access restrictions are rendered
• gradually transition from transparent dash at zoom level 8 to filled dash at zoom level 13; or if a sharp transition is preferred (to simplify implementation), do so at zoom level 11

For simplicity, I think it's better to forgo a distinct style for "unknown" and consider "sealed" as default because it is usually more important to know (and therefore to map) when a way is unsealed. Even in heavily mapped areas such as London and Paris, the "surface" information is missing in many major ways. Making "unsealed" the default would thus annoy many mappers instantly, then they would probably just fill up the map with the imprecise "surface=paved" which is considered the default in most applications today anyway.

Regarding classification in places such as Brazil (where I map), I think local mappers will reconsider their classification criteria when unsealed major roads (such as trunks) get rendered distinctively. Most trunk roads in West Africa seem to correspond to national highways regardless of their physical conditions. If that's correct, it would be the same criteria adopted in Argentina, Bolivia, Peru (as mentioned earlier) and also in Canada: some trunk ways are unsealed, they are "trunk" simply because they're national highways, their "importance" is more strongly related to who has power over them than to what exactly they connect. Looks like we have adopted an unpopular idea in Brazil.

[joostschouppe]

@ftrebien, Ecuador and Chile are much closer to the Brazilian tagging and
I'm working on a proposal to change this in Bolivia too: trunk road only if
it is a paved road (with some exceptions allowed, see proposal here:
https://wiki.openstreetmap.org/wiki/Clasificacion_de_carreteras ), based on
an extension of the Highway Tag Africa (now available in Spanish here:
https://wiki.openstreetmap.org/wiki/ES:Highway_Tag_Africa ).

But I think we should keep that discussion in the latam (and maybe hot?)
mailing list, not in this thread.

[davidbannon]

On Mon, 2015-06-01 at 05:29 -0700, Joost wrote:
....

I'm working on a proposal to change this in Bolivia too: trunk road
only if
it is a paved road ....

Joost, I'd suggest thats maybe not a good idea. The highway= tag
describes the purpose or significance of a road and is not the tag
intended to show its condition. If its a "trunk" road, used to connect
major population centres, then it really should be so tagged.

While I share your frustration that 'condition' does not get shown on
the main osm map, you do see it on, for example OSMAnd.

.... keep that discussion in the latam ....

Ah, but its an issue outside of Latin America too Joost, we've seen
people from Russia, Asia showing a lot of interest. Australia is also
affected. Certainly Africa. Only really N.America and Europe that don't
have long unsealed roads.

David

[richlv]

at least in our corner of europe we have long enough roads with compacted surface so that having this on the map (and in the data in the first place) would be very, very useful.

but please, instead of discussing minor details of how it should look, please get all together on irc or someplace and get a rendering example together. even if you all agree that this or that would look marvellous, nothing will happen because there's nobody to implement it.
or, "somebody should do something about it" ;)

[ftrebien]

@joostschouppe I agree that this is a topic for the latam mailing list (which is recent and I didn't know of). However, I also agree with @davidbannon based on current assumptions of various OSM communities. At very low zoom levels, we need to have these important unpaved ways rendered, and if their class is downgraded, there's no simple way the renderer can decide when to render these ways. It surely can't render all tertiaries and secondaries at those low levels, that would look very messy. And even if there was a way to do it (say some complex topological analysis), the results would display anternating colour which would make the map look confusing. Some routing algorithms (those guided by road class) would also be affected by such class downgrading. I think having the rendering change subtly (continuous to dashed) is more intuitive and less messy and that's why I originally liked your proposal.

@richlv It would be nice to have a web interface to make such changes more quickly, and particularly to allow graphic designers to sidestep the technical issues. To get Tilemill running on my system (Debian Wheezy), I would need to update the libc libraries, which is a messy procedure. I'll soon upgrade to Debian Jessie and so I'll be able to implement and generate samples for the ideas we've been discussing. Meanwhile, I think new ideas should be welcomed, even if they're just opinions.

[matkoniecz]

Major problem is that there are multiple feature marked in a similar way, also typical markings on maps are similar:

• roads under construction
• tunnels
• proposed roads
  and goal is to add a new one,
• unpaved/paved status

It would be great to have style where each property would be immediately recognizable, or at least typical user would easily guess meaning of rendering.

Among styles used to depict important low quality roads on various map following methods are used:

• (1) lack of fill, only casing is displayed. But it works well on maps where most roads are OK, and only some are of low quality (typical for maps of Australia with roads across the outback). In areas where all or nearly all roads are unpaved results would be weird - roads render as thin double lines. Also, there would be problems with OSM data model, as rendering of crossings would be quite weird.
• (2) lack of casing or dashed casing - this style is currently used for tunnels. It would result in start of a very similar search for a new style for tunnels. Also, people used to the style would be highly confused by using of tunnel style with a new meaning.
• (3) dashed fill (normal road colour & special colour) - it is style that seems the most promising and examples below show how it may work.
• (4) new separate colors of fill/casing - changing only casing is not really noticeable and/or is ugly, changing colour of fill doubles number of road classes that should be distinguishable. What worse, unpaved and paved of the same class should be similar what is quite hard to achieve. This differentation is used really rarely, with Humanitarian style as the most prominent example.
• (5) display in style similar to current highway=track - this style is not working well for important roads of a low quality
• (6) dashed casing & fill (normal road style & empty space]) - this style works better for roads under contruction that would be moved to that style, as highway=contruction is currently using variant of (3)

Note that examples are generated based on real places but some are modified. Base road colors are also changed using one of possible new colour variations.

Markings for unpaved roads are 4,3 dashes, in color generated by line-color: mix(@unpaved-color, @normal-road-color, @unpaved-color-usage-ratio); formula with @unpaved-color set to #b78e8e and @unpaved-color-usage-ratio set to 20%.

Unfortunately road segmentation have some influence on rendering (see crossings and places where road is split into two separate ways), but I think that it is not a big drawback.

Note: I know that in this road colour scheme casing/shield colors need changes.

[ftrebien]

Awesome! :sparkles: I have no objection at that change, colours included, since it solves other open issues. Can you render an example with a tertiary going next to parking areas and also with unsealed living streets?

I think no changes would be required for tunnels, and also for proposed ways, which may simply copy the change you suggest for construction ways, combined with transparency (their current distinguishing characteristic).

Some people (not me) "might" object to having trunks exactly the same colour as motorways, so maybe a very slight colour difference would be welcome (just make motorways a little bit darker). This would also allow figuring out when classification is hopping between those two classes along the same road.

How about low zoom, would those unsealed roads turn into a dash or a dot pattern? (thinking about trunk/primaries in wide places like the outback or the Amazon rainforest, or tertiary/residential/unclassified roads at zoom levels 10-12) Considering that your dashes are pretty narrow, a dot pattern might make sense, and it would probably cause less confusion with administrative boundaries and other map elements at those zoom levels.

[ftrebien]

Well, there's also the (not very common case) of combining unsealed style with access restrictions such as access=destination, so maybe you could include that in an example as well. Most common case is highway=residential/unclassified with any access type (private, destination and permissive). Second most common is highway=living_street with access=private or access=destination. However, I still think it will work well. Combinations with tertiary are far less common. Not sure if highway=pedestrian is really part of our current scope since highway=path, highway=footway and highway=cycleway do not change style based on surface (people "actually" use path mostly for unpaved paths and the other two for paved ones, though not strictly so). Also, highway=pedestrian often is a previous paved street that allowed traffic and then became closed. TagInfo shows no combinations of that way type with any unsealed surface type.

[ftrebien]

How about rendering the text of highway reference numbers in black, or making the balloon's background a little darker, as in tertiaries? With the lighter colours, they get difficult to read, particularly on secondaries. Visible in the last sample, on ways Krakowska (reference 2121K) and Stanislawa Kmity (reference 774). Arguably in primaries too, but remarkably less so.

[pnorman]

How about rendering the text of highway reference numbers in black, or making the balloon's background a little darker, as in tertiaries?

Could you link to a git branch showing this so we can see?

Also, keep in mind, many roads don't have a ref.

[ftrebien]

@pnorman I actually refer to the images presented by @matkoniecz above. The last one in particular shows this more clearly. I agree this is not very important and I'd be fine to have them committed as is considering the value of representing unsealed ways, but I also think that people will soon file an issue pointing that out. And it's probably easy to fix (much easier than the awesome work @matkoniecz has done so far).

[ftrebien]

Just found out that the colour of highway balloons/shields is actually embedded in SVG files here. The road style only references those files from line 2084 on, no references to the shield's colours.

[alexandre-mbm]

Perhaps the dotted could be adopted without much change the current strong colors. I like them.

[matkoniecz]

@ftrebien Shield are generated by https://github.com/gravitystorm/openstreetmap-carto/blob/master/scripts/create_standard_shields script, with colour set there. Generated files are then copied to https://github.com/gravitystorm/openstreetmap-carto/tree/master/symbols/shields so colour changes are easy (modify create_standard_shields, run create_standard_shields, copy files).

[matkoniecz]

@ftrebien

Well, there's also the (not very common case) of combining unsealed style with access restrictions such as access=destination, so maybe you could include that in an example as well.

With current access styling, the same changed colour scheme:

https://cloud.githubusercontent.com/assets/899988/8395278/9d0e8cac-1d67-11e5-9aa7-1c0431d124ea.png
https://cloud.githubusercontent.com/assets/899988/8395281/9d0fa3f8-1d67-11e5-90bb-3b4b9958bccd.png
https://cloud.githubusercontent.com/assets/899988/8395279/9d0eb11e-1d67-11e5-8b18-cd571d45da6a.png
https://cloud.githubusercontent.com/assets/899988/8395277/9d0e3f7c-1d67-11e5-93b1-b1f210712e7f.png
https://cloud.githubusercontent.com/assets/899988/8395294/0cbb8618-1d68-11e5-9df8-a1ac963ed489.png
https://cloud.githubusercontent.com/assets/899988/8395300/58eebafa-1d68-11e5-81f1-6635346ba1c3.png

[joostschouppe]

Looks very good to me! Nice work, Mateusz.

I would suggest to keep the dashing at as low zoom levels as possible for
trunk and primary roads. For local roads it's only necesary at higher zoom
levels (the lower the classification, the later you need to know the
surfacing). The same would go for access information.

2015-06-28 7:34 GMT+02:00 Mateusz Konieczny [email protected]:

Well, there's also the (not very common case) of combining unsealed style
with access restrictions such as access=destination, so maybe you could
include that in an example as well.

With current access styling, the same changed colour scheme:

[image: surface unpaved highway primary access private way master - strong]
https://cloud.githubusercontent.com/assets/899988/8395276/9d078cf4-1d67-11e5-9c4e-1e49da8f2293.png
[image: surface unpaved highway residential access private way 41 4 44 5
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395278/9d0e8cac-1d67-11e5-9aa7-1c0431d124ea.png
[image: surface unpaved highway residential access private way 51 5 -0 1
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395281/9d0fa3f8-1d67-11e5-90bb-3b4b9958bccd.png
[image: surface unpaved highway residential access private way 53 2 -1 8
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395279/9d0eb11e-1d67-11e5-8b18-cd571d45da6a.png
[image: surface unpaved highway residential access private way 54 8 31 7
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395277/9d0e3f7c-1d67-11e5-93b1-b1f210712e7f.png
[image: surface unpaved highway residential access private way master -
strong]
https://cloud.githubusercontent.com/assets/899988/8395280/9d0f6550-1d67-11e5-9b3d-da79cd5e95e2.png
[image: surface unpaved highway residential access destination way master

• strong]
  https://cloud.githubusercontent.com/assets/899988/8395284/d3ca28aa-1d67-11e5-84d3-ec9633a32d89.png
  [image: surface unpaved highway residential access destination way 50 1 19
  9 16 16 master - strong]
  https://cloud.githubusercontent.com/assets/899988/8395294/0cbb8618-1d68-11e5-9df8-a1ac963ed489.png

—
Reply to this email directly or view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-116196348
.

[joostschouppe]

A good case to test rendering at low zoom levels would be the west of
Argentina, where you have a nice mix of paved and unpaved main roads - and
all roads are tagged properly.

2015-06-28 9:54 GMT+02:00 joost schouppe joost.[email protected]:

Looks very good to me! Nice work, Mateusz.

I would suggest to keep the dashing at as low zoom levels as possible for
trunk and primary roads. For local roads it's only necesary at higher zoom
levels (the lower the classification, the later you need to know the
surfacing). The same would go for access information.

2015-06-28 7:34 GMT+02:00 Mateusz Konieczny [email protected]:

Well, there's also the (not very common case) of combining unsealed style
with access restrictions such as access=destination, so maybe you could
include that in an example as well.

With current access styling, the same changed colour scheme:

[image: surface unpaved highway primary access private way master -
strong]
https://cloud.githubusercontent.com/assets/899988/8395276/9d078cf4-1d67-11e5-9c4e-1e49da8f2293.png
[image: surface unpaved highway residential access private way 41 4 44 5
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395278/9d0e8cac-1d67-11e5-9aa7-1c0431d124ea.png
[image: surface unpaved highway residential access private way 51 5 -0 1
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395281/9d0fa3f8-1d67-11e5-90bb-3b4b9958bccd.png
[image: surface unpaved highway residential access private way 53 2 -1 8
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395279/9d0eb11e-1d67-11e5-8b18-cd571d45da6a.png
[image: surface unpaved highway residential access private way 54 8 31 7
16 16 master - strong]
https://cloud.githubusercontent.com/assets/899988/8395277/9d0e3f7c-1d67-11e5-93b1-b1f210712e7f.png
[image: surface unpaved highway residential access private way master -
strong]
https://cloud.githubusercontent.com/assets/899988/8395280/9d0f6550-1d67-11e5-9b3d-da79cd5e95e2.png
[image: surface unpaved highway residential access destination way master

• strong]
  https://cloud.githubusercontent.com/assets/899988/8395284/d3ca28aa-1d67-11e5-84d3-ec9633a32d89.png
  [image: surface unpaved highway residential access destination way 50 1
  19 9 16 16 master - strong]
  https://cloud.githubusercontent.com/assets/899988/8395294/0cbb8618-1d68-11e5-9df8-a1ac963ed489.png

—
Reply to this email directly or view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-116196348
.

[imagico]

One styling option for unpaved roads would be a fine random grain pattern for the fill which might be relatively intuitive to indicate a rough road surface and can be well combined with dash patterns etc. to indicate other special properties.

I don't really like the dash pattern for surface type - it is fairly unintuitive IMO, it looks badly with strongly curved roads and intersections and its coarse structure adds a lot of noise to the map.

[matkoniecz]

@imagico - hm, I never thought about this one. How it may be done? Using line-pattern-file?

[imagico]

I am not sure if there is a reasonable way to do this with current mapnik without generating polygon geometries via ST_Buffer() within SQL.

[daganzdaanda]

Really great work @matkoniecz ! The dashes are doing the job without being too noisy.
(If a random pattern is possible, that's definitely worth a try, too)

I also like your recolouring of the roads. Though I would probably need to see a larger map area to get a better feel for it. The current (British Ordnance style) colours just get into problems with our many landuses and general busyness.

[Rovastar]

what about other ways. Footpaths, cycleways, etc. Are we having a solution for those that is the same? Or new rendering or not doing those?

[ftrebien]

@Rovastar Never seen any request for this, I wonder if there is a significant need to distinguish these cases. They could become dashed while retaining their current colour, but it might cause some confusion with highway=path. Maybe it's not a bad idea after all, as many paths are in inferior conditions compared to official/intentional ones (check combinations with surface on TagInfo). Another possibility is increase the dot pattern spacing. Would the rules to consider them unsealed/undesirable be the same as those for other highways? (this would probably require a separate discussion, perhaps with cyclists and people who map for accessibility)

[matkoniecz]

@ftrebien I though about displaying footways and paths using the same style, with different display for paved and unpaved. Footways would default to paved and paths to unpaved. But I am not really sure is it a good idea.

[ftrebien]

Maybe I can launch the discussion at the talk or at the tagging list, and see what people think/suggest. The idea of footway=paved and path=unpaved is what we use here in Brazil, but not all places do so. As far as I understand, footways and cycleways are paths that are intentional for pedestrians and cyclists, even if unpaved. Paths are for unintentional paths (such as places that pedestrians leave their marks on but that are not designed by the local government for pedestrians) or for paths that escape typical classifications (such as snowmobile paths). For instance, an unpaved/undeveloped sidewalk (right next to the road) would be represented by a footway, not by a path. So, colour could capture the idea of "intention" (red for pedestrians, blue for cyclists) and dotting/dashing could capture the idea of good/bad surface condition, just like dashing could do for roads. But I'm not sure if we should explore this deeply at this moment, maybe a different issue should be opened for that, then we can know better the general level of interest.

[dieterdreist]

sent from a phone

Am 30.06.2015 um 07:41 schrieb ftrebien [email protected]:

The idea of footway=paved and path=unpaved is what we use here in Brazil, but not all places do so.

if you deviate from the official documentation you create less useful data IMHO, I suggest you add explicit surface tags rather than relying on implicit defaults (if I got you right).

As far as I understand, footways and cycleways are paths who are intentional for pedestrians and cyclists, even if unpaved. Paths are for unintentional paths (such as places that pedestrians leave their marks on but that are not designed by the local government for pedestrians) or for paths that escape typical classifications (such as snowmobile paths).

"unintentional" ways can be marked with the additional attribute informal=yes

cheers
Martin

[kocio-pl]

@Rovastar There is already quite advanced proposition regarding new path rendering by @sb12 (in general, paved/unpaved problem is not touched here AFAIR), but it's apparently on hiatus now. However it would be great to coordinate it with new road rendering somehow.

[swaan]

It is quite obvious you can't have a great single style to rule them all.
Paved/Unpaved styling can be subtle on a default style but should be prominent in a travel style.

I really like how Regio styles their road atlas (=map for travelling):
Line width for road width/importance. Line colour for surface type: Red is paved major, Yellow is unpaved highly maintained (gravel), white is minor (unclassified) but maintained, black is for tracks and natural (compacted) surface roads.

I like it because whether I am on a bicycle, motorcycle, car or truck - I can make routing decisions very easily based on visual information. Sometimes you want to keep your car clean. Sometimes avoid=unpaved in GPS results in a huge detour to skip a few km of gravel roads.

[matthijsmelissen]

@matkoniecz I never noticed this style used by Google before. I'm not quite sure what it signifies, is it their way to represent paved/unpaved? I find it quite ugly to be honest, but it's interesting nevertheless.

[matkoniecz]

@math1985
Probably it is for unpaved (it is impossible to verify as Google disabled map editing). Yes, it is quite ugly and busy and it is working poorly in areas with many unpaved roads. Also, this style is currently used for tunnels. It would result in start of a very similar search for a new style for tunnels.

[matthijsmelissen]

@matkoniecz Do you see any feasible way to add the paved/unpaved distinction to the current road layout? (Not asking you to do it, just wonder if it's be possible.)

[davidbannon]

Hi Maths, not a superficial question !

Yes, its something man or woman could accomplish, given a suitable
commitment and cooperation from the guardians of the map. Please see
Navit or Osmand to see it done well.

Over the years, a number of people have proposed various models but it
turns out than none of us are have the mapmaking experience to turn that
into something acceptable to the afore mentioned guardians. The people
who do routinely work on the rendering engine are not as convinced about
the need as you and I, so are unable to put the effort in themselves.

One of the underlying problems is that a dashed casement is usually used
to indicate unsealed roads in those parts of the world where unsealed
roads are common. However, the public OSM map has used that style for
tunnels. Lets not get into an argument about the worldwide frequency of
tunnels v. unsealed roads.

Personally, I have taken my efforts elsewhere.

David

On 31/10/15 09:28, math1985 wrote:

@matkoniecz https://github.com/matkoniecz Do you see any feasible
way to add the paved/unpaved distinction to the current road layout?
(Not asking you to do it, just wonder if it's be possible.)

—
Reply to this email directly or view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-152665086.

[matkoniecz]

@math1985

Do you see any feasible way to add the paved/unpaved distinction to the current road layout? (Not asking you to do it, just wonder if it's be possible.)

Yes, I have still some ideas to test.

[ftrebien]

The new style looks really nice in my area (finally district boundaries are clearly visible! they're a mess here). Still, I'm hopeful that the unpaved styles can be included sometime soon, this looked really mature to me. It may not be the perfect solution (if such a thing really exists), but I think it is better with than without, it would help bring up new ideas and also encourage mappers to fix old problems in the data.

[BalooUriza]

On Sat, Oct 31, 2015 at 6:09 PM, davidbannon [email protected]
wrote:

One of the underlying problems is that a dashed casement is usually used
to indicate unsealed roads in those parts of the world where unsealed
roads are common. However, the public OSM map has used that style for
tunnels. Lets not get into an argument about the worldwide frequency of
tunnels v. unsealed roads.

Looking at http://www.openstreetmap.org/#map=19/35.21854/-97.48547 , I
noticed the dashed casements here for the first time, and wonder if we can
use a solid (but similarly faded) casement for tunnels where the road is
paved, and reserve dashed casements for unpaved roads. I bring this up
because dashed casements (or brown lines like tracks are rendered) are the
typical treatment for what (at least many US midwestern) people would
expect for unpaved roads (as, generally speaking in the midwest, unpaved
roads are far and away the norm outside of city limits and sometimes
within).

[drgweber]

Hi All

this issue is now open for over 3 years here, and has been requested 8 years ago elsewhere. A quick counting shows over 6 million objects with surface tags in the unpaved group.

Is there any hope to see this implemented, ever?

[kocio-pl]

Well, I don't have such hope, because we can't even agree how it should look like and I don't see anybody really wanting to write the code - @matkoniecz is assigned, but it doesn't look like he's the one to do it.

If there will be no further progress on this subject, I'm going to close this issue as wontfix in a few days.

[imagico]

I'm going to close this issue as wontfix in a few days.

Nah, closing is only an option if there is agreement that this should not be implemented in this style. The problem here is that so far no one has invested the time necessary to really test the various possibilities and develop a good solution for this (and i don't mean just a quick mock up but a real practical solution). Closing issues because so far no one has been willing to solve them would essentially communicate we do not want new developers solving problems we cannot solve ourselves.

The suggestion of a grain pattern for the fill for example has not been tested at all.

[AsgerFrank]

Hope of the map also becoming a cyclist's map would be lost then, as the ability to discriminate paved/unpaved is indispensable to a road or mountainbike cyclist, and is also most convenient to any cyclist.

[imagico]

But please keep the discussion focused on practical options to render paved/unpaved, the question if it makes sense to render this provided there is a good way how it can be rendered and an implementation for it is long settled i think.

[kocio-pl]

Closing issues because so far no one has been willing to solve them would essentially communicate we do not want new developers solving problems we cannot solve ourselves.

We can always reopen them and I'm happy to do that. I meant wontfix as a real conclusion of dead discussion, but now I think this would really send the wrong message. But if you want to discuss the problem, there's even no reason to close it.

[kocio-pl]

Hope of the map also becoming a cyclist's map would be lost then

It probably belongs rather to cyclist style.

[AsgerFrank]

Possibly. OpenCycleMap doesn't discriminate either.

[drgweber]

I understand that all of the discussion and suggestions about style & implementation here was in regard to the previous carto-style.

I think that the new style, rolled out October 2015, makes it easier to implement an unpaved style, at least for residential+unclassified+tertiary which could quite simply be rendered in brown instead of white. This would have hardly any issue in Europe but would have a huge impact elsewhere as all of the sudden all unpaved roads would become visible.

[imagico]

Rendering of paved/unpaved should not be limited to just a few road types and should not look like separate road classes, i.e. it needs to be intuitively clear that a secondary unpaved road is the same road class as a secondary paved road.

[drgweber]

I said "at least". The majority of unpaved roads seem to be in the category of residential/unclassified/tertiary so it seems to be a good place to get started.

[drgweber]

Another point is that the information of a road being unpaved is more important than the information of its category.

If you live in a region with a lot of unpaved roads, say South America, the first question anyone will ask is: is it paved? If it is not, no one will care what category it is, especially after a week of heavy rain you will simply avoid it like the plague even if you have to add hundreds of km to your journey.

[richlv]

osm.org style is said not to be for public use but for mappers. if somebody with more skill than me could add a hack for this, that would be great. just make it add a slight yellow-brown tone to the road.

what, there will be edge cases when something will look a little bit not perfect ? whatever. we lived for many years with invisible trunk roads in forests and nothing terrible happened. showing paved-ness status on the map should do wonders to mapping this important bit of info.

also, definitely applies at least to a part of europe. it is a very important fact in latvia, for example, for motorcycle riders :)

[kocio-pl]

Does anybody have an idea how should it be rendered? This is a blocking problem.

[richlv]

just colour them #9D9D40, no matter the classification :)
give the amount of time spent on discussing this, getting anything in will be great.

[HolgerJeromin]

This would render most small residential same as some wide primary roads in Africa and would make the map useless for trip planning. :-(

[drgweber]

This is a screenshot from Osmand when the option to show surface tags is turned on. Not my preferred solution but very helpful nevertheless. In this case brown is ground, blue is paved, black is asphalt if I remember correctly.

[davidbannon]

In my part of the world, unsealed roads are rendered as dashes, either
casement or infill. Width and colours indicate purpose/importance.

OSMAnd puts a dash down the middle, its too bold and tries to indicate
too many classes but its an attempt. My own "private" OSMAnd render
displays all unsealed the same, much more usable most of the time.

My choice would be to dash (or dot) the infill and don't try to display
any more then the binary [sealed|unsealed].

I would be very disappointed to see this ticket closed .....

David

On 04/12/16 07:02, kocio-pl wrote:
>

Does anybody have an idea how should it be rendered? This is a
blocking problem.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-264662054,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF__MAiKENKGVSoSACBmQPqIzUsCyRr4ks5rEcrNgaJpZM4A4-bU.

[PauloCarvalhoRJ]

To put it simple: unpaved roads not visually distinguished from the paved ones is a gross cartographic error. Shame on you if you close this ticket despite all the evidence and people saying otherwise. You don't need to believe me. Take ANY MAP, printed or digital, they ALL distinctively show unpaved roads. This is one key reason that killed my enthusiasm with the OSM project.

[kocio-pl]

Please don't get it emotional. I treat the tickets as a development tool - lack of a ticket does not mean there's no problem, closing doesn't mean we don't want to hear about it.

Yet this discussion is broken currently. It's just repeating how important it is to have this issue resolved, but that doesn't fix anything or help anyone. I'm inclined to lock it for a few days if participants will keep on insisting that it should be fixed, but not even trying to figure out how should it be done.

This is not a discussion forum, we need to have some conclusions - 164 comments makes it hard to even reload this page. Please discuss whatever you like on forum (like here) and come back here with some solution to test. Just showing how it's done in OsmAnd doesn't move things forward - we need to discuss how to do it here.

[joostschouppe]

@kocio-pl
There are plenty of ideas of how to do this. But your question isn't "who has an idea", your question is, "who is willing and able to make a proposal that is ready for merging". Unfortunately, us people with an opinion haven't got the time or the skills to do that.

Whatever happened to @matkoniecz 's proposal? I don't think it was flawed and I actually assumed this would get implemented during the big road style shake-up. Not sure what happened there?

[kocio-pl]

Maybe a Wiki page with a review of proposed solutions would be good for a start? It would be a _big_ step forward for me and it doesn't require any special skills, just some time and will to extract essential things out of a long thread.

We could discuss things like "I like 1, but 5 b) variant is also acceptable for me". Writing a code would be next step.

[matkoniecz]

If there will be no further progress on this subject, I'm going to close this issue as wontfix in a few days.

Wontfix is for things that are confirmed to be unfixable bugs (or to be more exact - unfixable without introducing even worse problems).

Wontfix is not for long standing bugs requiring significant work to investigate/fix/discover that there is no good way to fix them.

So in this case closing seems to be a poor idea.

Given massive amount of comments here it may be desirable to open a new issue that would summarize everything discovered so far, linked this ticked and close it.

[kocio-pl]

Given massive amount of comments here it may be desirable to open a new issue that would summarize everything discovered so far, linked this ticked and close it.

IMO the hardest part is summarizing. Is anybody here ready to do it?

[davidbannon]

kocio-pl, I sincerely wish you were right in saying hard part is summarizing. For the record, the request predates this ticket although that history seems to have been lost. There are some quite confronting decisions to make but I strongly agree that a Wiki page (on OSM) would be a great start. We'd need to address -

1. What tag is used to define paved unpaved ? ie unpaved is show when surface=[unpaved; dir;gravel....] or track=* or several others....
2. How to render it given that most people who are familiar with unsealed roads like a variation of the dashed model and dashes mean tunnels to much of the existing rendering community.
3. Who can implement it, given a decision ? 'Mappers' are out there mapping and don't have the skills or access. The existing custodians of the map don't see unpaved roads as important.

Some sweeping generalizations that are not in any way meant to offend anyone but we do need to understand the underlying problem.
I am more than willing to start an OSM wiki page if people feel they could support that model. I believe we could solve point 1 and 2 pretty quickly.
In any case, thanks kocio-pl for your interest!
David

[pnorman]

What tag is used to define paved unpaved ? ie unpaved is show when surface=[unpaved; dir;gravel....] or track=* or several others....

This isn't blocking us, we can work it out when we have a style. The cartography is the current problem.

The existing custodians of the map don't see unpaved roads as important.

No, we don't see an acceptable way to render them.

From mhy perspective the only way I see for someone to advance this issue is for them to propose a pull request implementing a style that they think works. It doesn't need to be perfect, but this then allows people to see how it looks in a variety of situations and see where it works and doesn't work.

[davidbannon]

Thanks Paul. If you could please have a look at my point 3 in previous
message ?

I am sure you are not saying "learn to do a pull request to gravitystorm
or drop the subject" ?

Last time I looked, that would involve installing postgress, an large
carto plugin, gravitystorm itself, and learning what is, to us, a whole
new language. Forgive me if I have some of that wrong, I don't
understand that process, most of the people involved don't.

The overall OSM project is one that welcomes input from a huge number of
people, I don't think its appropriate to put that sort of barrier up
Paul. especially given the arguments presented.

Incidentally, I have tried installing the then stack, I got about half
way through with what little time I could find and discovered you had
moved over to gravitystorm ....

And I also disagree that hacking the code comes first. "We" need agree
on what the end product should look like, in the past, most proposals
have been rejected because they resemble existing features.

David

On 05/12/16 11:29, Paul Norman wrote:
>

What tag is used to define paved unpaved ? ie unpaved is show when
surface=[unpaved; dir;gravel....] or track=* or several others....

This isn't blocking us, we can work it out when we have a style. The
cartography is the current problem.

The existing custodians of the map don't see unpaved roads as
important.

No, we don't see an acceptable way to render them.

From mhy perspective the only way I see for someone to advance this
issue is for them to propose a pull request implementing a style that
they think works. It doesn't need to be perfect, but this then allows
people to see how it looks in a variety of situations and see where it
works and doesn't work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-264744260,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF__MK1s6MkA3rUoXuC1YjehXoQQTOMAks5rE1rTgaJpZM4A4-bU.

[SomeoneElseOSM]

David,

And I also disagree that hacking the code comes first. "We" need agree on what the end product should look like, in the past, most proposals have been rejected because they resemble existing features.

Unfortunately, without a familiarity with the variables that the "roads" code deals with now (things like road class, bridges, tunnels etc.) and without a familiarity with the variables that you can tweak in the code (colour, fill, casing etc.) and how those things work together, it would be difficult for anyone to provide a suggestion such as the one at https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-116145329 . It's easy to use words to try and describe a solution, but without actual example code that someone can use to render a problem area that they're aware of, there's no way to see how any proposed solution would work everywhere.

The other advantage of producing some example code is that it forces you to at least consider the answers to some of the more difficult questions (e.g. what tags count as paved and what as unpaved?)

I'm not especially familiar with the current state of this style (it's not really very useful where I live) but would be happy to try and help with getting more people to the point where they can play about with it and contribute to it in the future. I'm very much aware that while we have lots of "how to use OSM" examples and there are "how to" guides such as those on https://switch2osm.org/ , I'm not aware of any that give a "soup to nuts" example of making a change to an OSM Carto style, either this one or any other.

There's some dependency information over at https://github.com/gravitystorm/openstreetmap-carto/blob/master/INSTALL.md - does that help, or is more information needed? If there are specific questions to be answered or problems to be solved then I'd suggest asking over at help.openstreetmap.org, since the answers will surely benefit lots of other people. If more general, then maybe start with a list post or an OSM diary entry saying what you've tried and what you're stuck at?

[pnorman]

Thanks Paul. If you could please have a look at my point 3 in previous
message ?

I've looked at it, but I think this is just rehashing https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-66413051, and andy's https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-66427800

Paul, do you honestly require people to go off and build a complete TileMill install and then understand the style sheet before they can contribute to this discussion ?

Nobody is obliged to install Tilemill in order to contribute to the discussion, but...

No, of course not. Not without the help of the people experienced with the stylesheet.

... please do not place obligations on other volunteers to do work that you are unwilling to do yourself. Everyone here who is 'experienced with the stylesheet' was once in the same position as you - that is, 'not experienced with the stylesheet', but they invested time and effort to develop new skills.

---

Unfortunately, without a familiarity with the variables that the "roads" code deals with now (things like road class, bridges, tunnels etc.) and without a familiarity with the variables that you can tweak in the code (colour, fill, casing etc.) and how those things work together

Yes, it's unfortunate that this is in the roads code, which is the most complex part of the style with the desire to get all sorts of complicated layering right. If/when we get a PR with changes, I expect the maintainers to have to rework parts of it to fit in with all the other code, but that's fine - we know how to do that.

---

About the only idea I can find here that I consider worth testing with an implementation is @imagico's suggestion of a grain pattern, which may not be possible to implement in a reasonable way.

For my part, I'm not doing a test implementation in the near future, as my top road priorities are all to do with simplifying the roads query and MSS, and is all post schema change. Because of this, I'm unsubscribing from this particular issue.

[imagico]

About the only idea I can find here that I consider worth testing with an implementation is @imagico's suggestion of a grain pattern, which may not be possible to implement in a reasonable way.

It is likely that this can be done with SVG line patterns in Mapnik 3 but you are probably going to need to generate a separate pattern for every road width that exists on any zoom level for that. The pattern currently used for sand beaches could be used as blueprint.

The suggestion of this design idea was not arbitrary by the way, what would likely work for such an approach is that most unpaved roads in the world are in low latitude regions and due to the variable scale of the mercator projection roads are rendered particularly wide in these areas which makes structuring the fill color to transport additional information an obvious method.

No matter if using that approach or another - this would not be easy work and the main difficulty is not to get started working on this style in the first place. But if you are technically apt and willing to invest a significant amount of time this is entirely feasible to do. And no one expects you to come up with a merge-ready solution at once. The first step would be simply to produce something that can be tested and evaluated regarding general feasibility.

[davidbannon]

Thanks SomeoneElseOSM, thats a pretty reasonable response. I had a look through the dependencies list you suggest and agree that part at least appears better documented than last time I played in this space. But, as you say, whats missing is a bit of a walk through once its all installed. I guess thats going to be a bit of an effort to produce but perhaps it would be used a lot wider than just this issue ?
I am not sure I can find the time/diskspace/bandwidth any time soon. But I do feel more positive than last time I copped a serve from Paul ! :-)
The real question is just how likely is it anyone can find a solution that does not conflict with existing styles ?
David

[boothym]

In the iD editor the unpaved roads have a dashed outline, not sure how it would transfer to osm-carto but this seems to be the code: https://github.com/openstreetmap/iD/blob/20406f81ca055def378395337296b9baba90f06b/css/map.css#L805

[kocio-pl]

The problem is complicated (with tunnels having dashed outlines and recent change of access rendering as dashed filling), that's why I still think we should start with a list to see a big picture.

[davidbannon]

Folks, we really need to stand back and look at this objectively. The fact is the is a limited number of distinct ways things can be depicted on a map. There are quite possibly unlimited things to depict. Clearly, this means some things cannot be depicted.
So, prioritize what is depicted ? On what basis ?
David

[mboeringa]

One consideration I haven't seen mentioned up to now, is the fact that almost everybody nowadays travels with the help of a routing app... Those apps can take care of the aspect of paved versus non-paved, and avoid non-paved routes if instructed to.

Honestly, _who in this thread doesn't own one?_ (or a mobile phone potentially capable of hosting one) and who doesn't use it anytime you need to go somewhere unknown?

Even in the middle of Africa or some desolate area, mobile phone usage is rife if you can judge the news. Even if you don't have coverage, if you have pre-loaded data in a routing app, you can still use your phone's GPS to make your way.

So, how necessary is the display of non-paved roads in the map??

[drgweber]

Even in the middle of Africa or some desolate area, mobile phone usage is rife if you can judge the news. Even if you don't have coverage, if you have pre-loaded data in a routing app, you can still use your phone's GPS to make your way.

So, how necessary is the display of non-paved roads in the map??

A map that renders unpaved roads as if they were paved is wrong on the most basic level. We have been asking for many years simply to get it right.

We are not asking any special favour but to simply respect the fact that there are many more roads in the world that are unpaved (estimates are they outnumber paved ones by 10 to 1).

The lack of unpaved rendering is being a pain for mapping. Its difficult to convince people not to map unpaved roads as highway=track. We always have to correct a lot of this. On the other hand its difficult to get information about roads lacking the surface=unpaved tag without opening a whole region in JOSM.

One needs to understand that mappers, especially new mappers, have a very strongly relation with the main map they see on openstreetmap.org. What they don't see rendered they tend not to map or else they use workarounds like using highway=track for any unpaved roads. I suspect the same applies to app developers, what they don't see on the map they tend not to put in their apps. In particular no app makes distinction of unpaved roads, except Osmand and even Osmand is not very good at it.

Which brings me to the question: have you ever used a phone map in the middle of Africa?

[richlv]

we're talking about a map for mappers, remember ? :)
showing this information prominently on the map will get this detail mapped more.
as for users, a quick glance at a map showing you this info can help to decide which route to take - if a gravel route is 1/3 of the asphalt route, it might make sense to take it.

so no, routing has no impact on the need to show the paved status.

i guess the disconnect between users understanding the need for this and those not understanding it could be attributed to the region - if you live in a region with significant amount of gravel roads, you'll get it :)

regarding the rendering decisions... i'm good with anything. it will be better than the current "nothing", which has been discussing back and forth for years. getting anything in will allow to test it and improve it.

[kocio-pl]

I'm inclined to lock it for a few days if participants will keep on insisting that it should be fixed, but not even trying to figure out how should it be done.

General discussions about roads rendering are always welcome, but rather here. This ticket is about looking for something very specific: how could we render paved/unpaved roads in osm-carto style.

I will unlock this conversation in a few days, please remember to keep it on topic.

[kocio-pl]

If we talk about importance in some parts of the world, where paved may not be so obvious, I think this feature may be better supported by the HOT style:

https://github.com/hotosm/HDM-CartoCSS/issues/26
https://github.com/hotosm/HDM-CartoCSS/issues/104
https://github.com/hotosm/HDM-CartoCSS/issues/141
https://github.com/hotosm/HDM-CartoCSS/issues/232
https://github.com/hotosm/HDM-CartoCSS/issues/249

[dieterdreist]

2016-12-14 17:23 GMT+01:00 kocio-pl [e-mail]:

If we talk about importance in some parts of the world, where paved may
not be so obvious, I think this feature may be better supported by the HOT
style:

this is a property that is always important. Unpaved roads are not limited
to the areas where HOT is working. Besides motor vehicle traffic this is
also very important for cyclists and important to pedestrians when the
weather is wet. Clearly the HOT style should support this as well, but it
is no argument to not support it here in the general map style.

[kocio-pl]

This is all what routing software is designed for, not general map style, which may include that information, but is not a "transportation" style anyway. But yes, the main reason against is that we still don't know how should it be deployed here.

What about the list of conceptions then? Does anybody care enough to really do it?

[davidbannon]

On 15/12/16 03:39, kocio-pl wrote:
>

What about the list of conceptions then? Does anybody care enough to
really do it?

Please, could you eplain what you mean by "list of conceptions" ? I
certainly care .....

David
>

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-267084160,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF__MNxfV0hv0xDAlAs0uIvHLCIBNTvKks5rIBuygaJpZM4A4-bU.

[kocio-pl]

List of what rendering solutions have been proposed (as I said here), so that we could easy evaluate them and compare.

[Ircama]

It is likely that this can be done with SVG line patterns in Mapnik 3

As a very quick test, have just prepared a trivial png image with some grain pattern (similar to beach.png) and have put the following at the end of the ::fill section of road.mss:

line-pattern-file: url('symbols/unpaved-road.png');      

It roughly works.

The image size has to be tuned for different zooms and possibly an alpha channel or similar transparent filter should be used to avoid overlapping the road colors.

This indeed needs available time for investigation, development and testing as @imagico commented, but maybe someone can try developing a valid code.

[imagico]

Pattern for beach by the way is:

http://www.imagico.de/map/jsdotpattern.php#x,128,jdp59980;g,2.25,16,16;rx,250,2,8,8;rx,250,2,8,8;s,jdp58799;s,jdp49103;rx,250,2,8,8;rd,0,0,1,scree,0.1,5,10,0,jdp55873,9a9a9a,fff1ba;

I suppose you can cut strips from that as SVG in various widths for the different road widths. I don't think you can color line pattern SVGs from within Carto/Mapnik so you need a separate SVG for every road type as well.

[davidbannon]

Thanks Ircama, one picture worth 1000 words hey ?
Worth mentioning that we need show sealed status when well zoomed out too. For eg -
http://www.openstreetmap.org/#map=9/-22.7002/136.0204
Shows the "Plenty Highway" in Central Australia. Orange line going east west. I mention this because people need to be using this sort of zoom level when planning trips, its at this stage people assume its good road. The sand approach is not going to translate to single lines I guess ?
The old model of dashed lines in some way seems only possibility, is it appropriate to use single dashed lines when zoomed out and the quite neat sand when there is an infill ?
David

[pnorman]

is it appropriate to use single dashed lines when zoomed out and the quite neat sand when there is an infill

No, you don't want to use such radically different representations at low zoom and high zoom.

[joostschouppe]

I agree that radically different presentations should be -avoided- , but
maybe we can think about something to make the transition less radical. I
have seen many "no's" without qualification in this discussion. Please
don't say "no, because problem", but "no, unless you solve problem".

This map changes rendering of buildings quite radically from one zoom level
to the next, and I don't think that's a problem at all:
https://opentopomap.org/#map=17/50.79463/4.32337
https://opentopomap.org/#map=16/50.79463/4.32337

Dashed at low zoom levels works. It doesn't at high zoom levels because of
all the conflicts with access and tunnels. But actually, the rendering at
high and low zoom levels convey two different meanings.

At low zoom levels, they help you understand the basic structure of the
road network. Only a devision between paved and unpaved is needed. It helps
mappers do their work, as they have a general idea of the paved and unpaved
roads in their region.

At high zoom levels, they help you understand the fine grain of the roads:
here difference between sand, dirt, cobbles, paving stones, concrete etc
all become relevant. It helps mapping, as people will want their highway to
show as annoying-concrete-slab, or their city center as pretty in cobbles.
And I'm sure people will find it fun to try and make special textures work
within this style, so it might help you attract new contributors.

[davidbannon]

Well, jumping on Joost's bandwagon, there obviously must be a transition
from where a road is rendered as casement and infill to where its just a
single line. That in itself is quite a change. IFF that change happened
at a zoom level where the one we are talking about also happens, it
might not be too bad.

As I hinted somewhat earlier, I suspect there are no really good
solutions available, what we are looking for is something thats acceptable.

That said, Joost, I note your interest in trying, at high zoom levels,
to render more than just sealed/unsealed. Wow, that could be quite a
task.....

David

On 16/12/16 22:07, Joost wrote:

I agree that radically different presentations should be -avoided- , but
maybe we can think about something to make the transition less radical. I
have seen many "no's" without qualification in this discussion. Please
don't say "no, because problem", but "no, unless you solve problem".

This map changes rendering of buildings quite radically from one zoom
level
to the next, and I don't think that's a problem at all:
https://opentopomap.org/#map=17/50.79463/4.32337
https://opentopomap.org/#map=16/50.79463/4.32337

Dashed at low zoom levels works. It doesn't at high zoom levels because of
all the conflicts with access and tunnels. But actually, the rendering at
high and low zoom levels convey two different meanings.

At low zoom levels, they help you understand the basic structure of the
road network. Only a devision between paved and unpaved is needed. It
helps
mappers do their work, as they have a general idea of the paved and
unpaved
roads in their region.

At high zoom levels, they help you understand the fine grain of the roads:
here difference between sand, dirt, cobbles, paving stones, concrete etc
all become relevant. It helps mapping, as people will want their
highway to
show as annoying-concrete-slab, or their city center as pretty in cobbles.
And I'm sure people will find it fun to try and make special textures work
within this style, so it might help you attract new contributors.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-267571367,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF__MElqqnfmoZW3_sY75Du47sCwok8tks5rInD1gaJpZM4A4-bU.

[RobJN]

I think dashed lines at zoom 9 is fine. The existing dashed lines for footpath/track/etc don't show at that zoom (they come on at zoom 13 by which point roads have a width to infill).

[kocio-pl]

I'm happy to see real discussion about solution of this problem. I suggest to open new issue at some point, to make it easier to reload web page and to have short summary about proposed design (for example "Render paved/unpaved as dotted areas and dashed lines").

Typically this is what happens on PR tickets, but:

• with this problem it can take some time before the code will emerge and
• tickets are just the tools for managing team work, so don't hesitate to use them as needed.

[StyXman]

I quickly hacked a dashed casing version, using 2x highway width cased + highway width uncased, here's a preview:

Tunnels and bridges are not covered yet, but it seems that for this being really useful, we would need either more contrasting or thicker casings.

[StyXman]

Notice there's a bridge there. I don't think bridges should make much of a problem, as they 'naturally' will have a hard surface. Does anybody know bridges with soft/'unpaved' surfaces? Tunnels are still a problem, tho, unless we can assume their surface can be guessed from the context (the roads leading to it are unpaved).

[HolgerJeromin]

Wildlife crossing bridges are covered with grass or ground. But as they are wide they are probably in OSM normal areas with tunnels/covered ways underneath.

[StyXman]

I'm trying to find examples of real world data. The one I used is here:

https://www.openstreetmap.org/#map=15/64.2950/-21.6595

I picked up a couple more from the thread (which I didn't finish reading yet, it's really long), but if you could provide more... Unluckily my rendering/testing db only covers Europe, maybe I could import a Brazilian state?

[joostschouppe]

Hi Marcos,
I think Argentina or Chile would also be good places to import. Many
important roads that are unpaved, and pretty good tagging.

There's plenty of unpaved bridges: http://overpass-turbo.eu/s/oD2
And unpaved tunnels: http://overpass-turbo.eu/s/oD3

[StyXman]

hmm, I can do .ar, I should be rendering that soon...

[drgweber]

Hi
we've been actively working in Minas Gerais, Brazil, to add the unpaved roads. The region around Ouro Preto has many of those, another interesting region to look at is this national park.

I guess many bridges may have surface=unpaved as leftover from initial road mapping. In my experience these bridges are mostly concrete or wood. Sometimes they get so covered in mud that they appear to be unpaved. Another example.

[StyXman]

Ok, I got nice list of examples in .ar, I should be able to provide example images soon.

[StyXman]

Ok, first what mostly works: unpaved tertiary wit bridges and tunnels, z19-z12:

[StyXman]

Secondary + Minor, z19-z12:

[StyXman]

Residential + Tertieary + Secondary, z19-z12:

[StyXman]

I have more, but I think I spammed the thread enough.

Notice that most of these sshots have almost no landcover info, ways are almost the only thing present. That's why I would like examples in places more mapped.

[dieterdreist]

sent from a phone

On 26. Apr 2017, at 09:27, Marcos Dione [e-mail] wrote:

Does anybody know bridges with soft/'unpaved' surfaces?

yes, there are, e.g. with pebbles

[StyXman]

Last two sshots, with secondary/tertiary showing rendering at low zooms:

I'm preparing the PR now.

[drgweber]

This all looks very good!

I have no suggestions for Argentina, but here are some locations in Brazil with more land coverage:

• http://www.openstreetmap.org/#map=13/-22.8534/-44.4491
• http://www.openstreetmap.org/#map=12/-22.3812/-44.5928
• http://www.openstreetmap.org/#map=13/-19.8773/-40.1689

hope this helps

cheers

[StyXman]

Brasil imported. Some work will be needed to thicken a little the casings. I'll try to do some tomorrow.

[StyXman]

I'm still trying to make this work. For whatever it's worth, the Cycle Map renders some highways with dashed casings:

https://www.openstreetmap.org/#map=15/-31.3785/-64.3086&layers=C

It doesn't seem to be a matter of paved/unpaved, but it gives an idea of its looks. I will try and see what Ideas can be grabbed from that style.

[StyXman]

They're tracks.

[imagico]

As mentioned in #2045 i put up a script to convert jsdotpattern SVGs into Mapnik compatible form which also allows cutting strips of a specified width from a pattern which is the most important prerequisite for implementing the grain pattern idea discussed above.

[sommerluk]

I’ve tried out the idea with the beach-like fill pattern. (Just testing, so I was simply using the mangrove pattern). Implementation as described by @Ircama at https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-267445951 and I get this:

The pattern is not only visible at the road itself, but much larger. Does anyone understand why?

[mboeringa]

One thing that seems to be missing in this thread, is that I am pretty sure that the wish to display unpaved roads as e.g. voiced by @davidbannon , is not so much for large scale (e.g. >1:5k) rendering as presented here with the "dot patterns", but on the contrary for small scale rendering of the major roads capturing large areas of a country.

There is little use in knowing that a tiny stretch of road is paved in the town you are currently in, if you subsequently get stuck in the mud 100km down the road... It is also not much of use to know the paved status in a town itself, if you can simply back up your car, and drive to the next crossing 100m down the road to get to your destination over a paved road.

Almost all the examples of official maps and use cases presented here seem for the scale range of 1:100k to 1:1M, where you need to make a judgment if it is safe to go down a particular main road from town A to B across a desert or large swath of tropical forest.

For these use cases, I think @StyXman's original broken line pattern proposal is more appropriate than any dotted pattern that can only work at large scale.

[joostschouppe]

@mboeringa you are absolutely correct. The problem with this thread is that this point has been made above. As has the point been made above that this thread is so big, we keep making the same points, and hence we should make a wiki page, close this issue, and start over. I was going to repeat that point, but then I thought: I'll just make that wiki page real quick. There you go.

The page is very limited and ugly, but I would like to invite anyone who cares about this issue to improve upon it. If you want to add stuff but are even less of a wiki expert then I, feel free to contact me through my OSM profile.

[mboeringa]

@joostschouppe

The ultimate conclusion of this observation is also that any rendering proposal, might limit itself to tertiary, secondary, primary and trunk roads only (motorways inherently are always paved), or maybe even only secondary, primary and trunk roads

This might help to reduce the cartographic challenges of developing a suitable style, while still providing much of the benefits.

In addition, although probably a bit more controversial a statement, the display of paved/unpaved might be limited to the scale range of 1:100k - 1:1M only if there is a wish to keep cartographic display clutter at larger scales and / or smaller scales to a minimum.

[StyXman]

What about trunks? I found some tagged as unpaved in Spain, but maybe it's a tagging error (either in the unpaved or trunk status).

[mboeringa]

What about trunks? I found some tagged as unpaved in Spain, but maybe it's a tagging error (either in the unpaved or trunk status).

Sorry, forgot to mention the trunks, updated the last post to include them.

[imagico]

@sommerluk - line patterns work differently than polygon patterns in Mapnik, they are rendered along the line (see the cliff pattern for how this works) in the width of the pattern itself. The beach pattern image is 64 pixel high so it is rendered as a line pattern in 64 pixel width.

I introduced a tool to generate SVG patterns with a certain width in https://github.com/gravitystorm/openstreetmap-carto/issues/2045#issuecomment-299564551

Such general questions can by the way be well asked as a new issue so they don't get buried in an old thread like here and others who might run into the same problem in the future can find them more easily.

@joostschouppe - thanks, that is a good idea. I would suggest to everyone who has ideas on rendering unpaved roads but who does not want to go into practically implementing them here and dealing with the various problems this creates to present their ideas there. This can probably be quite useful, especially for other style developers seeking ideas who do not have the constraints we have here.

[joostschouppe]

@imagico well, yes, but the ambition should really be to close this huge thread and start over. Hence the Wiki article is only about rendering paved/unpaved in openstreetmap-carto. It might be inspiring to others, but it is focused on this particular carto issue.

It should ideally contain all the concrete proposals we've had here, plus ideas mentioned here that have not been elaborated. So it would be like an executive summary of this thread, providing approaches to test to a mostly developer crowd in a new thread here. Then the discussion in the new thread can be about "well, I tried X but it didn't work", and not about "how on earth have we not done this yet" :)

[imagico]

We definitely do not want to start this topic all over again. What we need is people actually getting to work on specific implementations and dealing with the practical problems - both design wise and technically. @StyXman has done a good first step here but he will already be able to tell you that he immediately ran into problem he had not anticipated when he started this. This is what you need to expect!

So for brainstorming ideas the wiki is a good place, for working on an actual implementation open a pull request (which does not need to contain a finished solution right away). Beyond that i really don't think there is much to discuss on this matter - either here or in a new issue.

[joostschouppe]

What I'm stating is the exact opposite of starting again. It is finally summarizing all the pro's and cons, all the opinions, so as to clarify what are the options to a wider community. In implementing this, surely some sacrifices will have to be made. If there is a clear community opinion on what are the best things to sacrifice, that will make it easier for developer to try and choose approaches.

Yes, the wiki would be for brainstorming, if needed. Because all the pieces of the puzzle are in this thread. The new Issue would be for discussing tests of practical implementation only. A pull request might come out of that, but I don't think we're quite there yet.

BTW, this idea is not mine but was formulated in response to @kocio-pl 's comment, back in December 2016

I think when an Issue is about to celebrate it's fourth birthday, maybe it's time to try a different approach.

[systemed]

Noting that there's still enthusiasm for this:

https://lists.openstreetmap.org/pipermail/talk-us/2018-February/018368.html
https://lists.openstreetmap.org/pipermail/talk-us/2018-February/018369.html

(Cartographically @StyXman's dashed lines are still the best solution yet proposed, I believe. The Ordnance Survey has a neat solution to the potential tunnel confusion by simply omitting the main stroke for tunnels, so that the dashed casing is all that appears, but that wouldn't be trivial in Mapnik. But dash length - i.e. one shorter, one longer - would seem an adequate compromise.)

[mboeringa]

Implemented in my personal ArcGIS Renderer for OpenStreetMap in development.

Example of Iceland at 1:500k scale:

[kocio-pl]

Doesn't it look like a construction on a highway?

[mboeringa]

Doesn't it look like a construction on a highway?

Well, this is just my personal style, so I can do with it what I want. My style is far from a copy of carto, and I use other styling for construction.

[kocio-pl]

Of course, I was just asking.

What styling do you use for road construction? Maybe rendering paved/unpaved roads is more important for people than construction (it sounds sane for me) and we could follow your choice.

Statistics:

• highway=construction - 126 874 uses (many of them are probably temporary)
• highway=* + surface=unpaved - 3 692 235 uses (many of them are permanent probably)

[mboeringa]

What styling do you use for road construction?

A bit difficult to explain, but it is more like a classic topographic map tunnel symbology, so no fill, just outlines. But I use a special dashed line symbol for the outlines to make it clearly distinct from tunnel.

[kocio-pl]

Could you post an example rendering?

[mboeringa]

Could you post an example rendering?

I think you guys can come up with your own ideas ;-)

Besides, I only render construction for the major road types to avoid clutter.

Maybe rendering paved/unpaved roads is more important for people than construction (it sounds sane for me) and we could follow your choice.

Well, certainly, if tagged kilometers of road is a good measure, paved/unpaved probably beats construction by 100:1...

[kocio-pl]

It also is less important what category is a road that you can't ride (because it's construction) than the one you can ride... :smile:

[StyXman]

I think I can implement something like @mboeringa 's style. I'll give it a shot at noon.

[kocio-pl]

Great! :100:

Given that your idea was abandoned half a year ago (https://github.com/gravitystorm/openstreetmap-carto/pull/2621#issuecomment-326695166) and parallel @sommerluk try was in practice suspended with some general notes (https://github.com/gravitystorm/openstreetmap-carto/pull/2640#issuecomment-330036914), it might be better to try from the other perspective. It also looks like an easier and more visible approach.

[StyXman]

Ok, so I did two versions, one with white dashes like @mboeringa , another with same-color-as-road. Here are some examples with primary:

• Same color:

• White:

In general it's easy to implement, it's all I could do during lunch. I think that for osm-carto, I would go for the white version, because the casings are so thin, they're barely noticeable at ZLs 12 and 13.

Another version would be with white dash, but not stepping over the casing.

The dash length should be tweaked too.

Finally, lower zooms where the highway is just a line (no casing), we fall back to dashed line. More on that soon.

3083 created.

[Slawek234]

I do not know if such a solution that is present used in the ID editor was taken into account for paved and unpawed roads. It seems very interesting.

https://s13.postimg.org/8di6e1kpz/Clipboard01ee.jpg

[StyXman]

Another version, with lighten 10% instead of white:

I like it much better that the white version. Notice it is not stepping on the casing. I'll do other types too later.

[ypcyc]

Did my comment help? :)

[andrzej-r]

I am just joining this discussion. Apologies if this has been covered before.

I am not a fan of using dashed lines for roads, rivers, footpaths etc. - anything people may want to _follow_. Boundaries of any sort or disused roads are fine, aesthetics permitting.

Current rendering of footpaths is a good example, in congested areas they can be difficult to track visually. I would rather have toned down colours but continuous lines.

As for the proposal, if you want to keep dashes/segments (I agree they look cool) perhaps make the line edges darker and reduce contrast between segments so that the segments are just about noticeable.

[StyXman]

secondary lighter:

This one is subtler than the previous one, and I started thinking about what to do with tertiary, which is white. Maybe I'll go for darken instead...

[andrzej-r]

Actually, the latest version looks pretty good - edges are continuous and of the same colour as other roads of the same category, so darkening them up is not a good idea. The segments are still a bit too bright imo, lightening them up by 5% (instead of 10%) would be enough for differentiating them from other roads, while making them look more continuous.

[Slawek234]

I would use a different method to differentiate the surface. Which I suggested here https://s13.postimg.org/8di6e1kpz/Clipboard01ee.jpg
The dash on the road suggests that something is wrong with the road.
1.Maybe it's under construction (this is often for road under construction or closed for traffic)?

1. The surface on the road and path is always continuous along the entire length and width.
2. I think that this pattern of road would be great for signing access

What is wrong with this proposal?

The color of the road unchanged, only the edge of the road would have a notch, it would be notched.
If the outer line were thicker the road would be better visible.

In addition, what about the roads services, residental, unclassified from now they will be colored?

[StyXman]

@Slawek234 those look good against black, but they will be barely noticeable against the basic white. See my next images.

[StyXman]

tertiary darken 10 @Z12, 7 after:

I agree that @ZL12 it's barely noticeable, but the road already had that problem without the dashing.

[peterisb]

I'll aggree with position that dashed lines is not good solution. Looking on the dashed lines first association is - attention this road is under construction, disused and closed or planned. This is association comes from topographic maps.

[ftrebien]

@peterisb Could you provide a reference for that? I've searched for topographic maps on Google Images and found many different uses of dashed lines. This one for instance uses a pair of dashed lines for unimproved or 4-wheel-drive trails.

[Slawek234]

I like the type of corrugated pipe Mainly due to corrugated edges.

[ftrebien]

Considering that:

• dashed filling conflicts with construction
• dashed casings pollute busy places like cities (as in the first example of this issue)
• textured filling produces an overall effect similar to a change in colour
• the class of a way should remain recognizable even if it is unpaved
• it is important to distinguish unpaved ways from nearby paved ways at various zoom levels
• it is important to distinguish long unpaved roads from other long paved roads at low zoom levels
• important roads are usually paved before other nearby roads
• lower-class ways (residential, tertiary, secondary) change style significantly at zoom level 12

Here's another idea to try:

• make low-class unpaved ways that are drawn with a light shade (residential, tertiary and secondary) slightly more brownish at all zoom levels
• make high-class unpaved ways that are drawn with a dark shade (primary, trunk) slightly lighter at high zoom levels and dashed at low zoom levels

Using WebAIM and a multiply overlay in GIMP with the colour for tracks, I arrived at these colors which I think would be interesting at high zoom levels:

• #f9bdaa for unpaved trunk
• #fce0ba for unpaved primary
• #e8e4a3 for unpaved secondary
• #d0c9c5 for unpaved pedestrian
• #e4dfd6 for unpaved living street
• #f5f0e6 for unpaved tertiary and residential

And at low zoom levels, #b0aa9f for unpaved secondary and tertiary.

[BalooUriza]

The examples above, I'd have assumed construction=minor instead of surface=unpaved just from the looks.

[peterisb]

@ftrebien for unimproved or 4wd trails dashed is OK. Dashed is not OK for other higher class roads in normal use - secondary, tertiary, unclassified etc. Here are some symbology examples (yes some of them are dashed also in normal cases):

USGS roads without pavement - https://nationalmap.gov/ustopo/images/US_Topo_Map_Symbols.pdf
USGS roads with pavement and related features (from here comes dashed examples) - https://pubs.usgs.gov/gip/TopographicMapSymbols/topomapsymbols.pdf
Symbology in soviet military maps - http://www.lib.berkeley.edu/EART/pdf/soviet.pdf

Also is important to remember - do we want see OSM symbolized by default as topographic map, I believe that not exactly.
Symbology by pavement for common use seems important only for secondary, tertiary and unclassified roads, but not for all types (maybe I'm wrong). All higher class roads, I believe, are paved and can stay unchanged or symbolized without pavement feature. Classify all lower class roads by pavement will be too complex for map reading. In such case we need only 3 extra symbols, maybe 3 changed and save dashed versions for extra features.

[StyXman]

All higher class roads, I believe, are paved and can stay unchanged or symbolized without pavement feature

Not necessarily so true in the 'third world'. I wouldn't even make this assumption for world wide cartography.

[Slawek234]

It looks interesting

Contrary to what I had previously thought, I did not find too many examples of dashed lines for roads under construction or planned. There are many tagging schemes. I found only this.

[kocio-pl]

Here's another idea to try:

I understand why so many ideas are coming out of the blue now, but let's be realistic - one person can test his own idea and change it a bit, but not all of them. They will fall into oblivion soon if nobody else will try to make competitive PRs and test how they behave.

Trying different set of colors for roads is relatively easy:

• install Docker environment
• if you want more automatic way, modify road-colors.yaml and run scripts/generate_road_colours.py which produces road-colors-generated.mss
• if you want full control, just modify road-colors-generated.mss

[StyXman]

Trying different set of colors for roads is relatively easy

I agree, but in this case we're talking about different styles.

[kocio-pl]

I was relating directly to a color changing proposition, so you can make a quick rendering test. Of course it might be just a first step toward making other changes too.

[Adamant36]

It would be cool if there was a way to tell different surfaces of unpaved. Having different spacing for the dashing when it comes to gravel vs dirt like in the picture Slawek234 provides is a good idea.

[davidbannon]

cool if there was a way to tell different surfaces of unpaved

I agree but think thats the domain of a more specialised app. Too many different things you are trying to show here. My interest in this is driven by safety. There have been several incidents where lives have been lost as visitors set off down an unsuitable road that is boldly drawn across a continent like Australia, some even called 'highway'. Just marking it as unsealed should be enough to alert people that they need to look into it further before setting off.

[StyXman]

In the case in which the casing is modified, we could do a ranking system like in the different types of paths.

[ftrebien]

How about replacing the dashes with dots for particularly bad surfaces, such as surface=earth? Also, some people have suggested (and I agree) that surface=compacted, despite being unpaved by definition, is actually not bad for travel at all, maybe that value wouldn't deserve any special representation.

[StyXman]

is there an IRC channel, or any other form of IM, for cartocss? I'm trying to complete the patch and I'm having problems defining the dashes for low zooms. This in particular does not work at all:

index 0a6c71a..451788e 100644
--- a/roads.mss
+++ b/roads.mss
@@ -1257,10 +1257,15 @@ tertiary is rendered from z10 and is not included in osm_planet_roads. */
     [feature = 'highway_primary'] {
       [zoom >= 8][link != 'yes'],
       [zoom >= 10] {
         line-width: @primary-width-z8;
         line-color: @primary-low-zoom;
+        // unpaved markings for zoom >= 12 are defined later as a new attachment
+        [int_surface = 'unpaved'][zoom < 12] {
+          line-dasharray: 8,2;
+        }
         [zoom >= 9] { line-width: @primary-width-z9; }
         [zoom >= 10] { line-width: @primary-width-z10; }
         [zoom >= 11] { line-width: @primary-width-z11; }
         [zoom >= 12] {
           line-color: @primary-fill;

[kocio-pl]

is there an IRC channel, or any other form of IM, for cartocss?

Unfortunately we use no other tools than what GitHub offers, but we could use just general OSM IRC channels.

I'm trying to complete the patch and I'm having problems defining the dashes for low zooms.

That means you need somebody more advanced in coding than me anyway.

[SomeoneElseOSM]

For dashes I've always borrowed from the existing "dashes" code in the style - the railways stuff in particular has lots of examples. Are you looking at changing the casing or the fill? If the former, have a look at how tunnels are handled; if the latter the "multiple lines" used to represent a railway at zooms >= 14 might be helpful.

[StyXman]

The dashing itself is not difficult, and I'm only touching the fill. What I don't understand is why it's not working. The relevant XML it generates for roads-low-zoom is:

<Style name="roads-low-zoom-fill" filter-mode="first">
  <Rule>
    <MaxScaleDenominator>1500000</MaxScaleDenominator>
    <MinScaleDenominator>750000</MinScaleDenominator>
    <Filter>([feature] = 'highway_primary') and ([link] != 'yes') and ([int_surface] = 'unpaved')</Filter>
    <LineSymbolizer stroke-dasharray="8, 2" stroke-width="1.4" stroke="#f3c380" />
  </Rule>
  <Rule>
    <MaxScaleDenominator>3000000</MaxScaleDenominator>
    <MinScaleDenominator>1500000</MinScaleDenominator>
    <Filter>([feature] = 'highway_primary') and ([link] != 'yes') and ([int_surface] = 'unpaved')</Filter>
    <LineSymbolizer stroke-dasharray="8, 2" stroke-width="1" stroke="#f3c380" />
  </Rule>
  <Rule>
    <MaxScaleDenominator>1500000</MaxScaleDenominator>
    <MinScaleDenominator>750000</MinScaleDenominator>
    <Filter>([feature] = 'highway_primary') and ([link] != 'yes')</Filter>
    <LineSymbolizer stroke-width="1.4" stroke="#f3c380" />
  </Rule>
  <Rule>
    <MaxScaleDenominator>3000000</MaxScaleDenominator>
    <MinScaleDenominator>1500000</MinScaleDenominator>
    <Filter>([feature] = 'highway_primary') and ([link] != 'yes')</Filter>
    <LineSymbolizer stroke-width="1" stroke="#f3c380" />
  </Rule>
</Style>

To me it looks ok, but then I'm not sure how <Rule>s are applied, if first match wins; or if the last two versions overwrite the others. Unluckily Mpanik's doc does not say anything about it.

[PauloCarvalhoRJ]

Maybe it needs to update/re-render the tiles in cache.

[StyXman]

I'm using my own setup to render my modifications; it's the same setup I use for my own style, and the same I used for the examples before.

[urbalazs]

+1 for the first post. Paved and unpaved residential streets must be rendered in different styles.

[matkoniecz]

@urbalazs Please use reactions ( https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/ ) instead of +1 comments.

It will not be displayed as activity for everybody following ticket and may be used to list most upvoted tickets.

[kocio-pl]

@sommerluk I've created new milestone for this issue, since I strongly prefer clean, upstream implementation based code, but it will mean version bump to v5.x (we will need Mapnik 3.0.2x once it's released - see https://github.com/mapnik/mapnik/pull/3980). Is it OK for you?

[StyXman]

Just for your info, I implemented dashed casings in my own osm-carto based style:

http://dionecanali.hd.free.fr/~mdione/Elevation/#8/-31.449/-64.581

It kinda works because my style is aimed on making roads more contrasting for in-car routing. For this I'm using both darker colors and thicker casings. Still, some of the dashing looks ugly (primary/secondary looking like sausages from ZL12). I plan to tack this at the mapnik level, but I really hadn't had the time to start reading the docs to see how to proceed. If anyone is interested, please go ahead :)

[matkoniecz]

Reopening as PR closing this issue was reverted - see https://github.com/gravitystorm/openstreetmap-carto/blob/master/CHANGELOG.md#changes-11

See #3399 for a current problem