Would this be a good usage of `landcover=concrete`?

As shown in the above image, there are these sorts of traffic islands in a parking lot. They are essentially just a raised area of concrete bordering the parking section. I was thinking of mapping their area with landcover=concrete, but I see that tag has very few uses, so I’m not sure:

Other parts of the parking lot are structured like the following:

For these, I typically just map the features present within the island — eg flowerbeds, grass, paths, etc., but I’m not exactly sure what to do when it’s just concrete.

How about area:highway=traffic_island?

3 Likes

Maybe, but I’m not sure if all cases of these fit the usage of that tag.

Why do you think they don’t?

1 Like

I would use surface=concrete

I cannot imagine situation where landcover=concrete would be better or needed

(I know that some people argued that surface must not be used as sole tag, even temporarily - which is not rule that makes sense, or must be obeyed or is even applicable in this case)

7 Likes

It’s exactly relevant here though. surface= is commonly used on amenity=parking as its main surfacing. It doesn’t mean the area is entirely covered by it, as shown by this question. Format-wise, it should not be used as both attribute and feature, which is why landcover= would be cleaner.

A drawback of both surface=concrete and a hypothetical landcover=concrete is that they suggest flat concrete surfaces, and fail to describe that these concrete elements are raised.

Maybe some kind of barrier=* with material=concrete and height=* would be more descriptive?

(Not sure if you were being sarcastic or not @Tordanik; assuming not)

I map the barrier=kerb way to show this.

1 Like

One factor favoring =traffic_island is indeed they are often raised, especially surface=concrete here. Logically kerb= can be added if it needs to be explicit.

No, I was not being sarcastic.

I was approaching this from a 3d rendering point of view. In that context, it would be easy to render a barrier=block (or some more suitable value) with a height=* tag, but significantly more challenging to derive a surface’s relative elevation indirectly from the fact that it is surrounded by barrier=kerb ways.

Still, with the kerbs the information is at least theoretically available in the database.