Render paved/unpaved #110
Comments
|
+1 This is an important request as the absence of a style for unpaved roads leads to many roads being tagged as Example: Residential areas in Managua, Nicaragua. Brown solid and dashed lines are |
|
One alternative to not having this included in the OSM-Carto is to use HOT's HDM Carto Styling |
|
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. |
|
+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) 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... |
|
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. :) |
|
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: |
|
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? |
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. |
|
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? |
|
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
as the tracktype scale is intended to be a complete list from 1-5, I think
add me to this list. grade2 is slightly worse than grade1, and grade1 is |
|
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. |
Pointless over engineering with #4137 that didn't go anywhere. The discussions essentially been dead since then. Neither is really that surprising. |
|
Nine years since I have been involved in this discussion ! And I still say it needs to be addressed. In 2018 we came across a young Danish couple who had taken a contract to deliver a hire car to Alice Springs, theirs for a few days as payment. They looked on the map, found the Plenty Highway and allowed a day to drive it. They passed us in a mad panic trying to make their deadline. Then we caught up to them, had to fix their car because no one can hurry on a road like that. They could, just as easily been killed. They were using OSMAnd. Not OSM's fault but an example of what happens. Davo |
|
This style currently renders road tunnels with dashed outlines: e.g. https://www.openstreetmap.org/#map=17/42.54502/1.72976 We would have to find a different tunnel rendering to use dashes for unpaved roads. |
|
"We would have to find a different tunnel rendering to use dashes for unpaved roads." What about just the lighter road color without the dashes for tunnels? I'm pretty sure I've seen some road maps display tunnels like that. Google Maps renders them as light grey. Either way, there's zero point in over complicating things and dashes don't intuitively mean "tunnel" anyway. |
|
How about a dashed fill color ? Something similar to this:
Note: I experimented with this style in my own OSMAnd renderer so not directly related to Carto but you get the point. |
|
The current highway=construction is quite similar to that suggestion: |
Tertiary and residential roads are white ( Also, to use dashes would require changing the end-caps to be square instead of round, or solving mapnik/mapnik#3982 first. See comment above #110 (comment) |
|
I strongly believe that "unpaved" visualization has much higher priority than highway=construction (for which style can be changed to something new). |
Exactly. It's nice to cover as many tags as possible for the renderer but unpaved conditions are a lot more common than construction sites, and a major source of tagging conflicts (using track instead of the appropriate highway classification) How about simply making the construction dash color red, and keeping it black for unpaved roads? |
|
I agree this is still an important issue, is clearly relevant on a global level, could support a lot for correct road classification (prevent tagging for the renderer classification). |
|
It's been almost 10 years since my first comment here! And this issue continues Trac issue 1447 where it was first asked in January 2009, so now the issue is 13 years old. Carto has long been biased towards highly developed areas, where construction and living streets are common and unpaved roads are uncommon or so well maintained that differentiating them is irrelevant to local users. I think this is largely because the majority of early Carto maintainers were people who lived in these areas. On most other popular commercial digital maps, new ways under construction are rarely shown, old ways being fixed or rebuilt are usually represented as a blocked road (often dashed in white and red), and living streets are indistinguishable from other residential/unclassified roads. The popular maps that distinguish between paved and unpaved do so with a color change, usually to a light shade of gray, sometimes to a light shade of brown. What I believe would work in Carto:
Regardless of whether such a suggestion attracts any interest, I think it's important to consider the context in which these ways usually appear. Unpaved primary and trunk roads exist primarily in very remote rural areas, not built-up cities. The situation is more or less the same for unpaved secondary roads, with occasional unpaved secondary roads in a built-up urban suburb in some areas. Unpaved tertiary roads may be more common near city centers in some areas, while unpaved residential roads are quite common in many cities. Unclassified unpaved roads are quite common in rural areas in some developed countries, while unclassified unpaved roads are not as common in cities due to definition (although local practice may vary, they are sometimes used as a kind of "quaternary" road where functional hierarchies are adopted by the local community; but if treated as residential ways, it should work well). In these contexts, dashing might make urban rendering a little too busy. |
Sorry if I wasn't clear. What I meant was what about continuing to render roads lighter when they go through tunnels, but just get rid of the dashes. Same goes for residential roads. It's already clear by how they are rendered without the dashing that the road goes through a tunnel. My guess is that how people know the roads in the picture goes through a tunnel is the color of the roads being slightly different for the portion that goes through the tunnel, not the existence of the dashes. Which is why Google renders them that way. |
Road tunnels are also desaturated however, so for example at these locations you can tell the motorway is in a tunnel despite the dashed outlines being barely visible (especially at z16 as well): https://www.openstreetmap.org/#map=17/55.86673/-4.27143 https://www.openstreetmap.org/#map=16/53.8032/-1.5470 It would be interesting to see a rendering of road tunnels with solid outlines or dashed outlines which are different to the proposed unpaved rendering (perhaps longer dashes?). (Just noticed the above post is saying something similar...:upside_down_face:) |
That's a good idea indeed. |
Not Tertiary, unclassified, residential and services. These are just white, or very light gray. The dashed casing is the only clear sign of a tunnel:
|
I would not recommend the use of any shade of blue. We render The most reasonable suggestion would be to unify the rendering of
What about
We try to make it clear that similar renderings are for similar features. I do not think that "like tunnels but without dashed casing” is a good idea, because an unpaved road is not similar to a road in a tunnel. Also, in that case we could not show if the surface of a road in a tunnel is unpaved or paved. |
|
I'd like to add another voice to the chorus saying that the paved/unpaved distinction is more important than rendering roads under construction. If something needs to shift out of the way to make room for paved/unpaved, then losing construction or giving it a new treatment seems like an appropriate course of action. In my rural part of America more than 60% of our road miles are unpaved, a critical distinction in many seasons. As others have noted, not rendering this distinction encourages poor highway tagging practices. In the Americana style we are currently using dashed fill to identify unpaved surfaces, a treatment often seen in American cartography (though this treatment is currently being debated). This treatment may or may not be the best fit openstreetmap-carto, but I wished to point it out as an example. I personally like that this treatment is very similar to the regular highway style, but "slightly broken" as unpaved roads are often experienced as just a little less-than paved ones in practice. Note that there is real usage listed in this Americana PR of |
But highway=living_street areas are far less common in the world than unpaved ways, and so are polygonal water features (except swimming pools). Besides shades of gray, the red-yellow hues are all used for other significant purposes. What about light purple, light green, light aquamarine?
This is a solution, but I think it might displease both pedestrian- and car-centric users as one is interested in where they can walk safely and the second is interested in where they can drive efficiently.
I wouldn't worry too much about aeroways as the context is usually enough to infer what the shapes mean. I agree that pedestrian squares are better rendered in grey, so it makes sense for pedestrian streets to be grey as well.
But tunnels with an unpaved surface are usually short and directly connected to unpaved roads, so the context should make it clear. Tunnel rendering is particularly important for large vehicles (trucks, buses), which are also interested in avoiding unpaved roads when possible. Anyway, these are just suggestions. I believe that dashing is another feasible solution, but it doesn't seem to be getting us anywhere. |
I mean what about The unpaved runway is often the only visible feature of the aerodrome, in the common case of a grass strip in a remote area like Alaska or Papua New Guinea.
I mean, how will we distinguish unpaved vs paved in this case, based on your other suggestions?
Please look at the previous work done on this issue. The dashing has issues even if it were not used for tunnels - see #110 (comment), #110 (comment), #110 (comment), and #110 (comment) - even so it might be an option if we do not find another solution. |
That looks nice, but overall it is a very simple road style. It appears Americana is only using 3 fill and casing colors for road classes. This style currently uses 7 fill colors for the main street and road classes, so it will be much more complex to do something similar. Also your unpaved style is only visible higher zoom levels >z12. More importantly we currently use a similar pattern for See #3579 and #2595 for previous improvements to |
|
sent from a phone
On 8 Jun 2022, at 19:25, ftrebien ***@***.***> wrote:
The most reasonable suggestion would be to unify the rendering of living_street and pedestrian, which I have already recommended
no, this is not reasonable, a pedestrian highway is closed for regular (motor)vehicles, a living street is more or less a residential street with a particularly low speed limit
|
Please comment on #3961 |
Going by the image provided by adamfranco it looks like the Americana style does exactly what I suggested and I doubt anyone is confused by it. So I think your putting more emphasize on the existence of the dashed cashing to tell when a road goes through a tunnel then it deserves. |
|
In openstreetmap-americana, we're exploring under-construction roads in issue ZeLonewolf/openstreetmap-americana#212 and PR ZeLonewolf/openstreetmap-americana#215. So far under-construction road styling is an unsolved problem for us as noted by @jeisenbe above. Our desired approach is to render unpaved roads with a dashed fill and solid casing (which we've implemented as noted by @adamfranco above), and under-construction roads with a combined dashed fill and casing. We have so far not been able to render under-construction roads with this desired treatment for technical reasons, namely that dual carriageways need to be merged at lower zooms to avoid the dash patterns overlapping in an unattractive way. However -- in a world where carriageway merging is a solved problem, fully-dashed casing and fill is quite distinct from an alternating fill on a solid casing. For a cased road (where both case and fill exist), a full break in the line treatment tells the under-construction story quite nicely. Whereas, single or double-line dashes (where it's just a thin line and no casing/fill) are quite recognizable as trail or trail-like (i.e. osm-carto's current treatment of path/footway/cycleway and the unpaved values of track) This is a long way of saying that I think an alternating fill pattern could work for indicating an unpaved road, however, the current styling for under-construction roads would likely need to change to a more dramatic break in pattern to avoid confusing between them. Under-construction road paper map sample: Unpaved road, two-track trail, single-track trail digital map sample: |
|
My initial "simple" suggestion years ago was to use highway=track color representing compacted\gravel road as outline for existing highways colors (today when I tried to recreate it I decided it's too contrast so I used lighter version) + make dashed lines similar to constructions, but with longer dashes: |
Yes, but how important is it to render aeroways as unpaved? This issue is mainly about ways used by ground vehicles (and, dare I say, pedestrians too; it would be in their interest to know which paths are unpaved). To me it doesn't seem to make sense to discard a solution because it doesn't work for corner cases. Maybe unpaved ways can be rendered in light brown? Or maybe it's a case where texturing would work fine. If colour consistency is required across all modes of transport, one should first ask why airways are represented in the same colour as pedestrian areas (it's probably because the two rarely exist next to each other and can be understood from context; the rare combination is tolerable, just like other rare colour collisions in the current style).
I proposed using the living street light gray colour for unpaved ways (of the lower classes currently represented in white: service, residential, unclassified, tertiary) and changing the living street colour to something else (maybe light grayish yellow like parking lots, where there is also a regular conflict between drivers and pedestrians, with pedestrians also having priority; maybe light cyan, like Crayola baby blue: #E7FEFF, which I don't think anyone would mistake for water; or light purple, like periwinkle: #CCF), while pointing out that living streets are not distinguished in most other commercial maps (they're rendered white like other local ways). The justification for this is that unpaved ways are more numerous. Also, living streets tend to appear close to pedestrian ways, and the shade difference is often too small to ensure that the two can be clearly distinguished (at least for me). Also, pedestrian ways tend to appear in city centers, while unpaved ways tend to appear in their surroundings and in remote areas, meaning the two rarely appear together, hence the slight difference in their shades would rarely have a practical impact if colour assignment is done this way. A light shade of brown might work if carefully chosen, but I think there are greater risks: it would make unpaved tertiary ways less distinct from primary ways and service ways less distinct from tracks (although the practical impact of the latter would be limited), Texturing as proposed earlier is likely to affect the overall shade of the way, making it darker (then white becomes light grey, the yellow shade of secondary ways becomes a darker golden yellow, and so on), and does not transfer well to lower zoom levels (especially for unpaved trunk and primary ways). But dashing applies well to all zoom levels if the tunnel style is changed, for example, by using a faint undashed casing. |
Indeed, thats necessary. But, just as a thought experiment, we should consider how the (stupidly extreme) cases work. Suppose we failed to mark tunnels in the same way we currently fail to mark unsealed roads ? Someone drives along and says "wow, we are entering a tunnel, I did not expect that". In most cases, the journey would continue. There may be a very few corner cases, trucks carrying dangerous loads, wide loads, people who suffer from claustrophobia. But few. On the other hand, by not marking unsealed roads, we present some drivers with a stark, often unpleasant choice. Do they continue, hoping its only short( after all, its not marked on the map), risking perhaps an unsuited vehicle, unstable weather, lacking suitable skills ? Backtracking is not always possible given time or fuel constraints. To be clear, I would be the last to suggest we no longer mark tunnels, but, unsealed roads should, IMHO, be prioritized. And most of the parts of the world where unsealed roads exist in vast quantities, dashed in some form, is what people expect. Davo PS: I live on an unsealed road. |
|
A small reminder that colour of the casing is also used to denote paved/unpaved. Maybe that is easier to adapt into OSM carto. |
and others
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?
The text was updated successfully, but these errors were encountered: