Closed joakimfors closed 2 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:
Residential areas in Managua, Nicaragua. Brown solid and dashed lines are highway=track
where they should be highway=residential + surface=unpaved
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.
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
+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.)
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.
for the record, "paved/unpaved" is not suggested, as, technically, compacted is paved, too... better use specific surface tags like asphalt, concrete, compacted...
For rendering we could consider "compacted" as paved too, if that's how it's viewed in most countries.
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. :)
@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.”
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
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
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?
If we're going to render unpaved roads differently, I'd prefer to use the surface tags and keep tracktype for tracks.
Would you prefer to only render surface=unpaved, or keep a long list of unpaved values?
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
+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.
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
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.
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.
for an example render see http://balticmaps.eu/?lang=lv&draw_hash=goiujv¢erx=553766¢ery=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
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
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.
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.
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.
Good point. I imagines thinner dashes for unsurfaced roads than for tunnels, but it might still be problematic.
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.
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.
I see. Well, maybe the guys at the design list can help us figure out the best solution for the general user.
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".
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.
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).
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.
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.
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.
+1 here.
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?
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
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.
Perhaps adding a 2px/3px brown solid border to the ways?
It would make unpaved more prominent that paved.
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:
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.
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.
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.
"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.
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.
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.
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.
+1 davidvannon
Yes we understand that paved/unpaved is not dependant on road classification.
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.
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?