Slipperiness is condition-dependent, not a fixed surface property, wet asphalt is slippery, dry asphalt isn’t, so a static tag can’t really capture it; that’s better handled in the description of each surface value.
On the hazard angle:
The sign restriction is there for a reason: hazard=slippery maps a physical warning sign, not a surface property. Removing it would conflate two different things, and we’d end up tagging wet-weather behavior on every smooth surface.
Agreed, and as mentioned above, I think a lot of suggestions here are problematic because they’re not verifyable on the ground. hazard=slippery is very subjective and might depend on wetness, weather, temperature and other conditions. That should be only mapped when there is a warning sign, not as a surface attribute.
The exact particle material of a resin-bound surface is also hard to tell. Deciding between glass, marble, rock, plastics, or maybe even mixtures of these will in many cases probaby require removing particles from the resin and analysing them in some kind of material laboratory. Not something you can usually do during a survey, maybe unless you have a lot of experience with these materials.
We should keep it somewhat simple. One main question that remains to be answered is how I should tag the material in my original post. I don’t think discussions about slipperiness help here, unless you want me to bring a water bucket and test the slipperiness of that path myself, and even then it would be hard to measure/quantify. Should I wear specific shoes?
I agree, as the wiki clearly states hazard=slippery is for “A signed area or stretch of roadway which is slippery”.
Uh, why do you think so? They should not be much harder to distinugish then their non-bound counterparts (e.g. surface=pebbles vs. surface=plastic) – and we do not pick parts of the surface to analyze in a lab, even when they’re not bound by resin.
I agree it should be kept as simple as possible – but not any simpler. In other words, the new value should bring some benefit. If the same new value for the surface behaves completely differently for two different OSM elements, then there is no benefit to marking it any more specific then surface=paved (in fact, it would only bring confusion so should be avoided IMHO).
The main reason why we have different surface=* values at all, is because they behave differently when you drive/cycle/walk on them. If the data consumer can’t discern any information how the surface might behave based on its surface=* value, then it is not worth tagging it at all.
This is why I proposed two separate values for two very differently behaving variants of resin bound surfaces, as explained in [RFC] Proposal: surface=resin_bound - #9 by Matija_Nalis and other posts.
Usually most people are able to see that surface=unhewn_cobblestone is likely to be slippery, while surface=chipseal is not likely to be slippery, even without carrying buckets of water and special shoes.
Thus, they wouldn’t make a mistake of marking one as the other.
All I am suggesting is the same consideration for those newly proposed value(s).
Can you tell if the material on the photo of my first post is white pebbles or marble or milky glass or hard plastic? I certainly can’t.
Again, unhewn cobblestone and chipseal can be distinguished super easily by looking at it.
Exactly my point: if it looks and behaves the same, then the exact material is not really important (although, for those knowing and wishing to record it, there does exist surface:material=*)
Conversely, if it looks and behaves completely differently, it should have different surface=* tag (which is the core of my suggestion why two tags are needed instead of one)
And surface made of rough-edged (e.g. crushed/chipped gravel) resin-bound material is equally easily distinguished from surface made of polished and round (e.g. round pebbles, molded plastic spheres etc.) resin-bound material by either looking at it, or (even better) dragging your feet across it (or trying braking on your bicycle or whatever).
I’m completely okay with surface:resin-bound-pebbles and surface:resin-bound-gravel or something equivalent to that, so that we can store different particle types.
Rather than splitting by particle type, what about surface=resin_bound_rough vs surface=resin_bound_smooth?
surface=* is what routers actually consume, so the split should track what changes routing behaviour (grip, rolling resistance), not what the material happens to be.
Rough vs smooth is field-verifiable by looking or dragging a foot across it, same as Matija’s point in #25, and it resolves the “can’t tell pebbles from glass from plastic” problem in #22/#24 without needing to identify the aggregate at all.
I guess, but it’s not that easy to define where the line is between smooth and rough. For example the particles on my example surface aren’t perfectly spherical and aren’t super smooth. Definitely rounder than gravel would be, but also not extremely slippery. Maybe roughly comparable to smooth asphalt, although it behaves completely differently when wet since the water can drain between the particles.
Fair point, and that’s reason enough to drop the rough/smooth split: most resin-bound aggregates sold commercially are smooth (rounded pebbles, glass, plastic granulate), rough/crushed ones are the exception, so go with plain surface=resin_bound for the common case and let smoothness=* carry the exception, same as it does for every other surface value, rather than inventing a hard cutoff inside surface=* itself.
Adding my support as a playground mapper. I’ve used things like surface=rubber before.
One simple tag would be great. In my mind, I have a definition of gravel vs fine_gravel vs compacted, but I bet that my definition is not universal and that others waver on this. A little vagueness in a tag is okay.
please do add surface=resin_bound
The only problem is there is unfortunatelly no backwards compatibility to recognize it as paved subtype
That’s true of every new surface=* value until data consumers add it, it’s not specific to resin_bound.
The surface=laterite proposal ran into the same gap after approval, and the fix wasn’t a tagging workaround, it was opening PRs against iD, routers, and renderers directly so they’d pick up the new value. Same path applies here once this has a proposal page: get it approved, then push support requests to the editors and consumers people actually use, rather than trying to solve backward compatibility inside the tag itself.
With a rendering hat on (creating maps covering UK and IE) I just occasionally look at taginfo and add newly popular values. I last did this a few months ago, down to a usage of 73.
yeah, but right now I’d like to use this new resin_bound value, but for that I’d have to remove a paved value mapped by someone else.
He might file a report against me claiming he was solving a reported issue(s) from consumer service(s) map.
A moderator has to decide eighter this or the other.
This is not very provessional. I do know much in this community isnt for the sake of our ease, but yeah, just saying this is a problem.
It would have been very good if OSM started to automatically keep two or more values internally for the same tag.
Only one value is mappable and the other is a group type, here it would have been paved or unpaved
Data consumers who don’t recognize the new surface value would fallback to the second present one - paved.
Well, this proposal might not belong in this forum, so if anyone fro the developers care, think about those implementations for the sake of prefessionalism.
One could map it as surface=paved + material=resin_bound, though. That would be both record the details, and avoid disrupting existing data consumers.
no, material of the bridge is metal ;)
True; in that case, there is surface:material=* instead, which is (somewhat unsurprisingly) about material of a surface.
and such nonsense would be ignored
they could also file nonsense report about someone making number of edits divisible by 13 as well and it would make as much sense
this is entirely and completely offtopic in this thread
I do similar for iD tagging schema, see popular unsupported values of major keys · Issue #2605 · openstreetmap/id-tagging-schema · GitHub
though thresholds I use are much much higher - at least for now, as popular values get processed