What does "surface" mean for parking areas?

While mapping a parking area, I’ve found a situation that I’m not sure how to tag properly. There’s this parking area which has asphalt for service ways, but the parking spaces use a paving_stones surface. What should I use for the surface tag of this parking? I’ve used paving_stones but now I’m unsure if I should comprehend asphalt in that tag (and make it surface=asphalt;paving_stones.

Tag the parking spaces with surface=paving_stones, don’t add surface on the parking area.
BTW, trees don’t grow well on asphalt!

that seems strictly preferable over surface=paving_stones if surface key is present

1 Like

Why not? It seems like removing valid information to me.

1 Like

In this case, it’s best to tag the actual features separately.

If the parking spaces themselves are paving stones, tag those areas with surface=paving_stones. For the service/driving lanes, use surface=asphalt on the relevant ways.

Using surface=asphalt;paving_stones on the whole parking area can be confusing, so mapping each part by its real surface gives more accurate data.

3 Likes

This is what I’ve done (except for the parking spaces since I’ve not mapped them yet), but I was asking for the general area, that’s the element that I’m unsure how to tag.

And @emmarose77 and myself did answer this specific question.
You could have a pattern with the paving stones, like here (not suitable for mapping!). Background information: the pattern is due to the name of the parking, and the name is due to a previous usage (here at 3:17). In fact it is not paving stones, but anti slip painting (same video, 3:31):

You shouldn’t mix values if they aren’t mixed in reality. You could have dirt;gravel for instance.

if parking is partially paved with asphalt and partially with paving stones then surface=asphalt;paving_stones is OK as surface is mixed in reality

Map the parking area with surface=paving_stones (after all, that’s the surface you actually park on), and the highway=service ways with surface=asphalt.

This is of course ideal and could even handle different surfaces on different parking spaces. But given that most parking areas don’t have individual parking spaces mapped (but many do have the service ways mapped!), my suggestion gets the same result for parking areas mapped at a typical level of detail.

No, using a semicolon just makes the tag almost completely useless. Is the western half asphalt and the eastern half paving stones? Is it striped? Are the parking spaces asphalt and the aisles paving stones – or the other way around? We have no clue whatsoever.

4 Likes

this is preferable over tag being wrong

surface=paved is also viable

parking aisles are parts of parking

1 Like

The surface is correct. There are features with a different surface inside the parking area (the service ways), but those are explicitly mapped with their own surface, which would naturally be understood to overwrite the parking area’s overall surface value.

And importantly, this mapping allows data consumers to correctly understand the situation on the ground, without requiring the parking area to be mapped at a level of detail which is beyond the vast majority of parking areas in the database.

I don’t disagree. But if they have a different surface from the one used for the parking spaces, it would definitely be a very useful convention to define the surface you actually park on as the “main” surface of the parking area.

2 Likes