[RFC] Feature Proposal – surface=laterite

General talk Tagging general discussion
, ,
81

“We’ve always been doing it this way”, while spurious on its surface[note the pun] is actually a very pertinent argument when considering possible changes in an established and widely used system, such as ours. Because any possible improvement in the core model must be weighed against the cost of changing the entire toolchain. Any system or culture sufficiently established eventually becomes pretty resistant to change, for better or for worse. So, any improvement would better not be breaking (major) things around.

In real life, I’m the principal author (and now a “gatekeeper”) of data model of a huge software package. In my young days, I was recklessly “improving” the model at dismay of developers and customers alike, who had to bear the brunt of change management. Now I know better: want a new feature? – well, here’s your workaround.

1 Like
82

Punnage absolutely always gets my support. :smiley:

I do think that it’s important not to let one set of renderers to dominate change control. OTOH they might engage with change. Anyway, as I said, I think that ship has sailed and sunk (subsurface? :slightly_smiling_face:).

As to datamodels, some of what you can do or not may be down to alternatives. Arrogant I know, but how many other highway datasets exist, especially free ones? Perhaps there is more freedom to change than some think.

In a previous life I worked for a small GIS company. The interal data model made network tracing very rapid. Far faster than the big names where the data was really a picture of a network. Unfortunately the big names could afford loss leaders… Good fun time though.

Telling clients a work around is at least better than telling them to find their own.

83

Though I perhaps never ever will be in a position to map a surface=laterite, I followed along this topic with quite some interest. From what I observe, the proposal underwent some minor changes. I further observe that there are conflicts that cannot be solved by talking, only voting will be able to get to a decision.

One thing I am still a bit uncertain, if this has been addressed sufficiently, is mappers: There is too much talk about routing, i.e. consuming the data. Especially recently. Personally, I understand surface=laterite as a sibling to surface=asphalt or surface=gravel. It is a convenient shortcut and from what I read in the proposal remarkably precise at telling ground truth.

1 Like
84

They will need to implement additional support for any *=laterite tag, regardless of the tag key. They also parse a lot of other tags to make decisions about routing penalties.

Implementation details of routing engines shouldn’t drive tagging schema decisions, expressiveness and usability of the tagging schema should be the deciding factor.

6 Likes
85

Agreed on both. The primary case is mapper expressiveness: one tag, field-observable criteria, and a term mappers across 16+ countries use without prompting. Routing benefits are a bonus, not the foundation.

surface=laterite works like surface=asphalt or surface=gravel: a direct, precise shortcut for what you are standing on. That is what the tag is for.

1 Like
86

I also think that the proposal is ripe for a vote and that it will pass.

4 Likes
87

I’d also say so, I did not look at the wiki discussions though. From what I learned here, the proposal will face a surface=petals, image below,

surface petals
surface petals720×540 174 KB

not that I intend to ever propose such for mapping :slight_smile:

2 Likes
88

I think it should be a main surface value because it may apply to a huge number of roads (far more than, say, surface=ice or surface=salt).[1] It would be especially useful in soil type transition areas with an alternating mix of clay-rich and clay-poor dirt roads.

  1. Notably, most laterite roads are in areas that are not densely mapped, but many are near areas that are densely populated. ↩︎

1 Like
89

The RfC opened 19 May so a vote can start no earlier than 2 June. I’ll open the ballot then and post here when it’s live.

2 Likes
90

If I let you have that, then commonness alone still don’t explain the logic in not using surface= =granite , or =paving_stones (+ paving_stones:material=brick ) vs =brick
=compacted + *material=laterite* won’t be uncommon either. Then there are some laterite bricks.
So I believe there should be more principles than squeezing every large number of occurrence in surface=

91

By that logic, surface=wood and surface=metal should not exist either. But they do, because they are both easily identifiable by non-specialists and have clear practical implications.

surface=paving_stones is easily identifiable, but it is not specific enough to describe all its practical implications. Ideally, it should have been split long ago into at least two subtypes:

  • artificial “stones” such as concrete block pavers, which usually have good grip even when wet;
  • natural stone paving, which is often much more slippery due to a smoother top.

This is also distinct from surface=sett, which usually has a rougher top, is less slippery, but is harder to walk or cycle on.

One could further distinguish porous from non-porous natural stone, since they behave differently in wet conditions. Beyond that, specifying the exact geological stone type adds little practical value and may require specialist knowledge.

Why not simply use paving_stones:material=*? In practice, when mappers must choose between main surface=* values, they tend to examine the surface more carefully. Only about 0.4% of surface=paving_stones uses currently have paving_stones:material=*, so for the overwhelming majority of the roughly 4 million uses, we still can’t determine whether the surface is artificial or natural stone, even though this has important implications for grip and usability in wet weather.

Similarly, material=laterite would obscure laterite and make large scale mapping harder. If it does not occur in your area, you can simply ignore it. I mostly ignore surface=ice and surface=salt because they do not occur where I map.

surface=granite alone does not clearly describe practical implications. If it refers to smooth granite paving stones, then its practical properties are the same as other smooth natural paving stones. If it refers to exposed granite rock, then its practical properties are essentially those of surface=rock.

So the real question is whether laterite road surfaces are both easily identifiable by local people and associated with distinct practical characteristics.

From the feedback I received, the answer appears to be mostly yes. My own area does not have this surface type, so I asked several mappers from regions in Brazil where it occurs. They immediately recognized it and showed strong interest in the proposal. That suggests to me that it has real mapping value.

4 Likes
92

it depends on the surface finishing how slippery these pavings are. The surfaces can be treated to be very slippery (by polishing them), both concrete and natural stone, or they can be treated to provide good grip (flamed granite, brushed sandstone, riven slate). Generally, you shouldn’t put wall tiles on the floor ;-)

93

But that didn’t stop people from doing it sometimes ;-) In OSM, we only describe, we don’t judge. Data consumers judge.

A quick image search didn’t find any concrete block pavers with a polished finish. Treated natural stones seem to have a bit more grip than usual, but I don’t think that makes much difference. If what really determines the practical implications is the finish, then instead of dividing paving_stones by material or porosity, it would be by finish. In any case, that’s a separate topic.

1 Like
94

Yes, how slippery a surface is can be measured and there are technical standards for it, but it’s not something a typical mapper can measure with their smartphone, so such a tag likely wouldn’t fit well in our system.

95

I don’t see what “logic” are =wood and =metal trying to compare? They aren’t at the same level. In particular for your argument, =wood isn’t as “easily identifiable” as before now with all the synthetic lookalikes, and it’s not totally “clear practical implications” for most needs.
You are exaggerating the effect of naming or format. Most users add =paving_stones alone because they don’t have more time or want, don’t know, or don’t care. Editing software aren’t heavily pushing to ask this in their valuable time either, not to mention many won’t be aware of their difference by looking at presets and the GUI alone. You are ascertaining this is caused by surface= vs paving_stones:material= without any reasoning or evidence. Is all the other paving_stones:*= not being prevalent caused by them not in surface=paving_stones:* too?
*=laterite* is a possibility for both =compacted , and =paving_stones / =artificial_stone vs =natural_stone_paving , that should tie together. “Real mapping value” isn’t diminished by where it’s added.

96

Without conducting laboratory soil analyses, I can only classify beach sand as sand; other types of sand (of different colours) are probably accidentally grouped together into dirt/earth quite often. Laterite, on the other hand, appears to be composed of much finer particles. The most characteristic sign seems to be the cracks that form when it dries. The problem is, of course, that every soil type is a mixture. When in doubt or in an edit war, those involved can use always this test, applying a 30% clay content threshold to the result.

97

I do not understand why this is so complicated. Dirt by definition is something not in a place where it ought to be. So laterite on the floor of my flat is dirt. You sure this applies to road surfaces the as well?

1 Like
98

Delving deeper into the digressions on representation, why, oh why, do we map stop signs with the highway tag if they aren’t highways? And what about oneway=-1? Why do we map biergartens as amenity=biergarten and not amenity=beer_garden? Why highway=living_street exists if all residential streets are meant for living? There must be a deeper reason behind all this mystery!

99

That is a special kind of residential and it has its own traffic sign, wel at least in the Netherlands where there is also a legal max speed of 15km/h.

100

Thank you all for the thorough discussion and the feedback that shaped this proposal. Voting is now open:

https://wiki.openstreetmap.org/wiki/Proposal:Surface%3Dlaterite#Voting

Voting runs 2026-06-02 00:00 through 2026-06-15 23:59 (UTC).

2 Likes