gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.55k stars 822 forks source link

Render paved/unpaved #110

Closed joakimfors closed 2 years ago

joakimfors commented 11 years ago

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 commented 11 years ago

+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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

+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 commented 11 years ago

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 commented 11 years ago

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

ftrebien commented 11 years ago

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

joakimfors commented 11 years ago

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 commented 11 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

matthijsmelissen commented 10 years ago

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

dieterdreist commented 10 years ago

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 commented 10 years ago

+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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

ftrebien commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

dieterdreist commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

Am 07/gen/2014 um 21:02 schrieb ftrebien notifications@github.com:

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

+1 here.

matthijsmelissen commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

matkoniecz commented 10 years ago

It would make unpaved more prominent that paved.

ftrebien commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

"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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

+1 davidvannon

Rovastar commented 10 years ago

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

PauloCarvalhoRJ commented 10 years ago

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.