<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 6:54 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">sent from a phone<br>
<br>
> On 31 Dec 2020, at 05:59, Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>> wrote:<br>
> While it's obvious to a human when looking at the rendered object, it's rather difficult to write software to interpret this clearly: an object is supposed to be an area or a line, not both<br>
<br>
<br>
but technically osm2pgsql could create a line for fenced=yes (as if<br>
there was an overlapping new way tagged with barrier=fence) and a<br>
polygon for the thing that is fenced, or is this not possible<br>
currently?<br></blockquote><div><br></div><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.  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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>