Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render paved/unpaved #110

Closed
joakimfors opened this Issue Aug 9, 2013 · 271 comments

Comments

Projects
None yet
@joakimfors
Copy link

joakimfors commented Aug 9, 2013

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

This comment has been minimized.

Copy link

lxbarth commented Aug 23, 2013

+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:

screen shot 2013-08-23 at 10 12 05 am

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

@skorasaurus

This comment has been minimized.

Copy link

skorasaurus commented Aug 23, 2013

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

This comment has been minimized.

Copy link

mibmib commented Sep 5, 2013

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

This comment has been minimized.

Copy link

ftrebien commented Nov 11, 2013

+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

This comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Nov 11, 2013

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

This comment has been minimized.

Copy link

richlv commented Nov 11, 2013

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

@ftrebien

This comment has been minimized.

Copy link

ftrebien commented Nov 11, 2013

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

@joakimfors

This comment has been minimized.

Copy link
Author

joakimfors commented Nov 11, 2013

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

This comment has been minimized.

Copy link
Contributor

tyrasd commented Nov 11, 2013

@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

This comment has been minimized.

Copy link

davidbannon commented Dec 31, 2013

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 comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Jan 1, 2014

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Jan 2, 2014

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

This comment has been minimized.

Copy link
Owner

gravitystorm commented Jan 3, 2014

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

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Jan 3, 2014

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

@dieterdreist

This comment has been minimized.

Copy link

dieterdreist commented Jan 3, 2014

Am 03/gen/2014 um 13:43 schrieb math1985 notifications@github.com:

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

long list

@vincentdephily

This comment has been minimized.

Copy link

vincentdephily commented Jan 3, 2014

+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

This comment has been minimized.

Copy link

richlv commented Jan 3, 2014

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

This comment has been minimized.

Copy link
Contributor

Rovastar commented Jan 3, 2014

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

This comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Jan 3, 2014

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

This comment has been minimized.

Copy link

richlv commented Jan 3, 2014

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

This comment has been minimized.

Copy link

ftrebien commented Jan 5, 2014

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

This comment has been minimized.

Copy link
Contributor

Rovastar commented Jan 5, 2014

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

This comment has been minimized.

Copy link

ftrebien commented Jan 6, 2014

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

This comment has been minimized.

Copy link
Owner

gravitystorm commented Jan 7, 2014

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

This comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Jan 7, 2014

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

@ftrebien

This comment has been minimized.

Copy link

ftrebien commented Jan 7, 2014

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

This comment has been minimized.

Copy link
Collaborator

matthijsmelissen commented Jan 7, 2014

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

This comment has been minimized.

Copy link

ftrebien commented Jan 7, 2014

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

@dieterdreist

This comment has been minimized.

Copy link

dieterdreist commented Jan 7, 2014

2014/1/5 ftrebien notifications@github.com

  • 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

This comment has been minimized.

Copy link

ftrebien commented Jan 7, 2014

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.

@StyXman

This comment has been minimized.

Copy link
Contributor

StyXman commented Feb 23, 2018

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

This comment has been minimized.

Copy link

Slawek234 commented Feb 23, 2018

It looks interesting rrooaddds

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.
Scan-180222-0002reer

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

kocio-pl commented Feb 23, 2018

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

This comment has been minimized.

Copy link
Contributor

StyXman commented Feb 23, 2018

Trying different set of colors for roads is relatively easy

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

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

kocio-pl commented Feb 23, 2018

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

This comment has been minimized.

Copy link
Contributor

Adamant36 commented Feb 26, 2018

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

This comment has been minimized.

Copy link

davidbannon commented Feb 26, 2018

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

This comment has been minimized.

Copy link
Contributor

StyXman commented Mar 1, 2018

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

@ftrebien

This comment has been minimized.

Copy link

ftrebien commented Mar 2, 2018

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

This comment has been minimized.

Copy link
Contributor

StyXman commented Mar 30, 2018

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

This comment has been minimized.

Copy link
Collaborator

kocio-pl commented Mar 30, 2018

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

This comment has been minimized.

Copy link
Contributor

SomeoneElseOSM commented Apr 2, 2018

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

This comment has been minimized.

Copy link
Contributor

StyXman commented Apr 2, 2018

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

This comment has been minimized.

Copy link

PauloCarvalhoRJ commented Apr 2, 2018

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

@StyXman

This comment has been minimized.

Copy link
Contributor

StyXman commented Apr 2, 2018

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.

@pnorman pnorman reopened this Jun 29, 2018

@urbalazs

This comment has been minimized.

Copy link

urbalazs commented Jul 4, 2018

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

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

matkoniecz commented Jul 4, 2018

@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

This comment has been minimized.

Copy link
Collaborator

kocio-pl commented Aug 31, 2018

@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 mapnik/mapnik#3980). Is it OK for you?

@StyXman

This comment has been minimized.

Copy link
Contributor

StyXman commented Jan 4, 2019

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.