<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 18, 2021 at 11:18 AM Martin Koppenhoefer <<a href="mailto:dieterdreist@gmail.com">dieterdreist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 18. Jan. 2021 um 16:54 Uhr schrieb Kevin Kenny <<a href="mailto:kevin.b.kenny@gmail.com" target="_blank">kevin.b.kenny@gmail.com</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"><div dir="ltr"><div>One thing that works wihtout wreaking any violence upon the data model is to break the fence into two or more pieces and tag each piece with `barrier=fence`. Then create a multipolygon with the lines as outer ways and hang the description of the area off of that. </div></div></blockquote><div><br></div><div><br></div><div>I am already doing this, you do not even need to break the fence, the minimum requirement for a multipolygon relation is a closed outer way, one way is ok. It has the advantage that you can have as many attributes on the fence as you like (e.g. "height"), and it remains always "clean" and not ambiguous as with mixed objects. The actual situation is that they often have no additional attributes, so "fenced=yes" could replace them (although the ones without attributes might get them in the future, while those indirect "fenced=yes" objects have a higher probability to remain simple). <br></div></div></div></blockquote><div><br></div><div>Without breaking the line, you have the issue that there are certain linear features that can also be area features (or for which area semantics have been requested) such as hedges. Breaking the way ensures that the feature cannot be misinterpreted as an area just because it's a closed way.</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"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The lines are simple linear features, so no data consumer has a problem with them, and virtually all data consumers understand how multipolygons work, so that doesn't cause a problem either.</div></div></blockquote></div><div><br></div><div><br></div><div>Yet there are many voices who do not like multipolygons, some time ago there was even a thread on User:Germany which suggested they were a disease. I can see how such a structure makes things slightly more complex and that as simpler solution with a property would be preferable - as long as it hasn't side effects.<br></div></div></blockquote><div><br></div><div>As long as there are features with holes, there will be multipolygons. As long as we have them, there is minimal harm in using them. Mappers will need to learn them sooner or later.  In my arrogant opinion, the largest single problem with multipolygons is that several editors don't really handle them competently. I can work with them with ease in JOSM - and used to do so in Meerkartor - but struggle with them in iD and never even tried in Potlatch. This could, I concede, be my ignorance; it could be that iD has better multipolygon features that I don't understand and haven't troubled to try to learn. I'm fairly satisfied with editing in JOSM. It's ugly, but it does what I want to do, and I don't insist on beauty.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>