<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 7. Feb. 2020 um 11:26 Uhr schrieb Christoph Hormann <<a href="mailto:osm@imagico.de">osm@imagico.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I currently tend towards a broader solution of dropping rendering of all <br>
barrier tags on polygons.</blockquote><div><br></div><div><br></div><div>great, this would make it very clear that there is indeed some problem with the tagging. Although I guess carto would get a lot of flak for a decision like this.<br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This would <br>
open a path for the various solutions already discussed - like <br>
introducing a new tagging scheme for indicating a polygon to <br>
be 'enclosed by a barrier'</blockquote><div><br></div><div><br></div><div>there is for example fenced=yes, currently used 4841 times (even applicable to nodes)</div><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> or by strictly adhering to 'one feature, one <br>
OSM element' without implicit tagging of barriers.</blockquote><div><br></div><div><br></div><div>adhering to 'one feature, one OSM element' and supporting fenced=yes on polygons isn't a contradiction. Implicit tagging is ok, it's explicit tagging of more than one thing on the same element, which creates the problem. "fenced=yes" doesn't say this is a fence, it says this has a fence around it. The problem with this approach is that it slows down the adding of details, because if you want to add the height of the fence you would either have to make it its own object at this point, or resort to new tags like fence:height=x<br></div></div><br></div>