Since I’m learning Overpass QL, I thought, “Why not give it a shot?” I quickly built up a query to find fences drawn over areas of different kind, and here’s one of the them:
I loaded them into JOSM and ran the validator. And yes, the validator generated a warning that there were two ways with same position.
According to the wiki, here’s how they suggest tackling it:
A closed way tagged with two feature tags, one of which is usually a linear feature such as barrier=hedge and another which represents an area such as amenity=school. In this case it is ambiguous if the barrier is meant to represent an area or a line, and for all properties it is unclear to which feature they belong. In such a case you may consider making a separate relation for the barrier=hedge and for the amenity=school, make the closed way a member of both relations and transfer the tags from the way to the relevant relation.
So, now I’m wondering how you would solve this. Is the wiki’s way the best option (which is a bit intimidating for me), or can we resolve it in a simpler way? Maybe draw a slightly larger area and put the fence inside it? Or how about drawing a fence with gaps for gates?
Yes, it’s not. JOSM is only giving a warning, which means: double-check that this is really what you want!
I’ve seen this tagging from time to time, and it’s actually very simple: the hedge goes on the way and the way is put into an MP (which by definition is an area). But since the MP then only contains a single, closed way, I consider this “tagging for the validator” and remove it. If you know that your solution is semantically and technically correct, don’t shy away from JOSM .warnings.
time, and it’s actually very simple: the hedge goes on the way and the way is put into an MP (which by definition is an area). But since the MP then only contains a single, closed way, I consider this “tagging for the validator” and remove it.
it’s only sometimes in the beginning a single outer way, not rarely you can split it into more ways because properties are changing or there are holes in the way (which require removing or changing tags but not deleting the way segments as they are needed for the multipolygon)
Oh, that is less problematic (though I do not see it being superior to using multipolygons with single outer way - such multipolygons are also fully valid, and both are a bit annoying)
In the case of a pitch (which is always an area) and a fence (which is always a line) , then had that been an error it would have been an error on Josm’s part trying to combine two items with fundamentally different geometries.
However, a warning seems reasonable - if you are happy that what you did is correct, just ignore the warning.
The Fix: Cut the fence on top of the pitch outline in 2. Same with the fence of the previous topic top of the retaining wall, cut it in 2. All Sea of Tranquillity. It’s only with the 100% outline overlay of 2 features all is said to be wonky.
That’s not really a “fix” though - it’s just causing a warning not to appear. What is mapped is essentially just that same as when the warning did appear, it’s just a bit more complicated.
the problem was with cases like barrier=hedge amenity=school that got rendered as a giant hedge area
yes, and these cases still persist, even more as carto doesn’t highlight them anymore as problematic. Carto developers say they aim at supporting mappers and community consensus and encourage reasonable tagging, so showing a problem where there actually is a problem, was reasonable, wasn’t it?
I consider adding a barrier=* to an existing feature to be mapper error. Before, this error was shown so it could easily be spotted and corrected, but now we are left with a situation where barrier=hedge cannot render as an area. And the mappers are not informed about their mapping mistakes.
Edit:
Let me explain why this presents a problem beyond the interpretation of whether something is an area or a line. All tags can be categorized into two main groups: main tags (e.g., barrier, amenity, natural, man_made) and attribute tags (e.g., color, surface, width, height). If a feature has multiple main tags, the attribute tags cannot be linked to a single main tag.
For example, if there is an artwork that is 3 meters tall, you would use “tourism=artwork” and “height=3”. However, if there is also a fence around the artwork, adding “barrier=fence” to the artwork area would imply that both the artwork and the fence are 3 meters tall.
There are two problems here. One is undeniably a data problem - in the real world, there are two objects (a school and a hedge) and in OSM there should also be two objects, not least because some other tags may apply to one and not the other.
However, as I showed it’s perfectly possible for a renderer to apply a set of rules that work in most cases (“if a hedge tag is added to an object that can be an area, assume the hedge is actually linear, else assume that an area hedge actually is an area”), and it’s a shame that OSM Carto chose not to do that.
That’s why barrier=hedge + area=yes is one of the few exceptions similar to highway=pedestrian+area=yes are not flagged by QA, albeit latter gets rendered as area, the former still as linear in Carto, appearing there to be some hard “this is linear, period” rule.
There are two problems here. One is undeniably a data problem - in the real world, there are two objects (a school and a hedge) and in OSM there should also be two objects
while I agree with this particular suggestion, it is not the only possible interpretation, because it is us who say what a thing is. We could also have a fenced off school as a single object, like in
amenity=school
fenced=yes
That was more common in the very early days of OSM, using e.g. the “abutters” key.
However, in your “fenced” example, “fenced” is just an attribute of the school - there’s only one object there, not two. Using two objects allows us to say things about both the school and the fence.
