In plain English, āmaterialā would tend to refer to something manufactured, like glass or plastic or brick, while āsubstanceā would tend to refer to something more raw, like limestone or wet cement. But material and substance already have more specialized meanings in OSM anyways.
I suspect these tags would still creep in because mappers in some cases would be more familiar with the kind of rock than with the way itās laid. For example, the floor of a highway=corridor may be surfaced in slabs of polished marble. A mapper might regard that as a distinct surface because itās so slippery. But if a subkey is more correct, the mapper may not discover it on their own without a helpful editor field.
@Minh_Nguyen You are probably the right mind to have answers for a broader subject than creating wiki pages mostly just to deprecate tags: This topic here reminds me of another one I took part of the discussion. I had the idea, to make possible some kind of autodiscovery for consumers of data by chaining in key/value pairs.
I guess, that has inspired me to tag surface=rock; rock=granite for the scramble linked above. When a consumer reads key=value, it can look, if there is a key with the same name as the value, and use it to learn further details. Is that comprehensible?
When there is a path with surface=rock; material=granite, how to know, that the material applies to the surface? It might instead apply to the handrail/whatever other attributes there are?
Yes, a human who looks at the raw tags and sees this combination would know exactly what you mean. I think editing/rendering/routing software would be unlikely to do this kind of traversal automatically for any arbitrary value. For one thing, it could lead to some pretty unexpected results in other ambiguous cases:
building=schoolamenity=schoolschool=secondary (Built as a secondary school or now functioning as one?)
building:material=rockwall:material=rockrock=granite (Just one, or both?)
We normally cope with these conflicts by documenting when iterative refinement is expected, but not by expecting it to occur universally. I guess this is similar to the challenge with using unrelated keys like surface and material together. The most predictable version of iterative refinement relies on subkeys, like surface=granitesurface:fragment_size=* etc. (Iām making this up.)
Anyways, my point is that surface=granite most likely refers to different things depending on the kind of feature. A granite-surfaced highway=corridor is very likely to be surface=paving_stones (which luckily comes with several subkeys), but the common term for that would be āgranite surface platesā or just āgranite surfacingā. Since granite is such a durable material, the slabs can get as large as concrete plates (concrete:plates), but the tagging is so different that users may not know about these options.
Like others here, Iām not very concerned about determining the mineral composition of a crushed rock surface.
I think that touches on something, that concerns OSM tagging a lot: Some tags are introduced by people that care about a certain aspect, from a particular position, and later get used by people, that do not care about that aspect, having no connection to the POV of the tag creators.
Some might wonder, why Yosemite granite looks so much different than LĆ¼sener Fernerkogel granite? (Fernerkogel is surface=rock;rock=gneiss;gneiss=granite; while Yosemite has surface=rock;rock=granite)
In the end, its all gravel? The challenge to replace paved/unpaved with something more specific a lost endeavour?
PS: How about surface=paved;paved=rock;rock=granite vs. surface=unpaved;unpaved=rock;rock=granite?
I would not go so far - even if pebblestone/gravel differentiation that someone attempted failed there is still reliable distinction (I hope) between sand and compacted
Well taken, but surface=rock says nothing about whether it is paved or unpaved rock. Of course, there are the keys tracktype|smoothness but how reliable is that?
In my mind, paving_stones requires multiple blocks arranged in some kind of pattern. If the entire surface is made from a single piece, that value doesnāt fit.
Think to have come across something that was called concrete slabs or plates, so went to search. Well openstreetmap+slabs and one of the top results in bing was Tag:surface=paving_stones - OpenStreetMap Wiki although āslabsā is not mentioned once in that wiki page.
With paving_āstonesā I think (dare I) of a format that can be easily handled by one so we certainly could do with a paving_slabs or paving_plates to express that dimension as seen above of the polished stone steps.
I also wonder, why we have material=*andpaving_stone:material=*. Why should I use something like paving_stone:material=concrete over material=concrete?
In theory, these steps donāt have a separate surface, as they are just a big chunk if granite, so material=granite would be correct. But after looking at this more closer, it seems that material and surface have a lot of overlapping which makes it confusing. Actually, the surface should better describe the structure of the surface than the material, unless the material of the surface differs from the main material. So something like surface=flat for my case, paired with material=granite? I find this all very confusing.
Iām guessing because proponents wanted all paving_stone:*subtags to neatly fit under same hierarchy?
But after looking at this more closer, it seems that material and surface have a lot of overlapping which makes it confusing
Yes. But you could have steps made from granite, while the surface is for example anti-slip rubber. Or a bridge with metal construction but with wooden planks, etc.
But I do think paving_stones people are taking that details mapping somewhat to the extreme (Iām not making those up):
surface=paving_stones
paving_stones:shape=squarish_octagon
paving_stones:pattern=interleaved
paving_stones:length=20
paving_stones:width=25
paving_stones:colour=#56544c
paving_stones:orientation=45
paving_stones:material=granite
But I guess, whatever makes people happy is good
But now I want 3D renderer which will take all those into account!
but how reliable is that?
