Splitting beach into dog-access sections - edit sanity check

Hi all,

Could I just get a sanity check that an edit I’ve made is the correct approach?

I split Scarborough South Bay beach (which was one large area) into two smaller areas and added the appropriate dog=* access tags to those areas. I also added the original tags to each area (i.e., natural=beach, surface=sand, tidal=yes) but did not add the name tag. I then combined the two areas with a multipolygon relation, which I tagged as type=boundary and name=South Bay (the name of the original area).

Is that correct? Or should I have taken a different approach?


Seems like there’s no clear consensus about how to detail beaches at the moment (I asked a similar question for nudist beaches here: Do we need more subdivisions?)

1 Like

England and by name Scarborough made international news last weekend. You may want to add a tag along the line of hazard=health since sewage is apparently wholesale dumped in open water by the operators and make sure the dog does not go cavorting along the water line and ingest some of the salty H2O. /OT

Excellent question, and I’m not sure what the best answer is!

One alternative might be to keep the two parts of the beach as now, and if necessary adding a place=locality node for “South Bay” beach to replace the relation (although there is already a node for the bay here, somewhat confusingly also called “South Bay”**).

** for the benefit of anyone not familiar with the area, the name “South Bay” is used to refer to both the beach and the bay (and the general area, actually), although they are of course different things.

1 Like

There was a long thread on the Tagging list back in December 2020 about a similar problem — how to name a collection of wet areas which have different types in OSM but are considered a unit for naming purposes. I don’t think anything came out of that, except me implementing “cluster by some tags when some other tags are the same” in my renderer. (I found the thread by checking the dates in my Git log…)

Here is a solution which I do not like, and which I write down only so that people can tell me why it is wrong, which I would love, because I do not like it!

Any user of OSM data will need a complete set of tag/value combinations that they intend to use. You cannot just “take data as it comes”, because without knowing the tags, you cannot even know whether, for example, a way represents a linear feature or an area. To gather this knowledge, you need to read the entire Wiki and mailing list archive, and figure out which contradictory bits to ignore.

Hence, any user can also make a decision on a case-by-case basis about which things to merge when adjacent objects happen to share some tags and values. For example, if two adjacent natural=beach have the same name, they can be considered as a unit for labelling purposes.

It does (seemingly?) work to just map the beach & dog area separately over the same area:
Way: 553680482 | OpenStreetMap &
Way: ‪Palm Beach Beach‬ (‪594795760‬) | OpenStreetMap

1 Like

Splitting natural=beach is fine. That would be needed if there are different surface= as well. You can use leisure=beach_resort for the entire thing including swimming area (if enclosed) and land-side facilities.
Of course conceptually, that doesn’t exactly represent the beach land itself, but it’s close enough. The presence of the same name= does it implicitly. boundary= could be a solution eventually to explain how it’s defined, although beaches may not be as regulated as =forest .