<div>I'd like to backup Karl's proposal and make it concrete: Besides the lack of a precise definition of what is a valid area I too propose to introduce an real and distinct primitive data type, called 'area' (or 'surface' or 'polygon'). </div>
<div> </div>
<div>Currently (v.05), the wiki says in <a href="http://wiki.openstreetmap.org/index.php/Data_Primitives">http://wiki.openstreetmap.org/index.php/Data_Primitives</a> : "Area: There is no data primitive for Areas. A closed way becomes an area by tagging it with the appropriate keys for areas. (natural=water for example)"</div>
<p>The data primitive 'area' would be encoded similar to a way and can have several ways forming one outer boundary (=closed like now, of course) and zero, one or more inner boundaries (being ways forming a 'closed' inner boundary), like this:</p>
<p> <area id="8007396" visible="true" timestamp="2007-09-26T19:07:16+01:00" user="a_user"><br> <wy ref="59907908"/><br> <wy ref="59907909"/><br>
<wy ref="59907910"/><br> ...<br> <tag k="created_by" v="an_application"/><br> <tag k="a_tag" v="a_value"/><br> </area></p>
<div>For inspiration how others have defined precisely such areas - called surfaces there - you can perhaps have a look at the "INTERLIS 2.3-Reference Manual" (1.2 MB pdf) here <a href="http://www.interlis.ch/interlis2/download23_e.php">http://www.interlis.ch/interlis2/download23_e.php</a> (I admittedly have been involved there). This document is public domain! These are the chapters of interest: "2.8.13 Surfaces and tessellations" (p.50), "<a href="http://3.3.11.13">3.3.11.13</a> Coding of surfaces and tessellations (p.89) and "Appendix C (informative) A small example Roads (p.100).<br>
</div>
<div>-- Stefan<br></div>
<div class="gmail_quote">2008/5/6 Karl Newman <<a href="mailto:siliconfiend@gmail.com">siliconfiend@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">
<div class="gmail_quote">On Tue, May 6, 2008 at 1:25 AM, SteveC <<a href="mailto:steve@asklater.com" target="_blank">steve@asklater.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Without reference to the ongoing debate or the changeset stuff,<br><br>is there anything else that should be put in 0.6? Probably a good idea<br>
to talk about it now.<br><br>Best<br><br>Steve<br></blockquote></div><br></div>Well, it's probably too big of a change for the next API change, but it would be nice to get a native polygon primitive. I understand it used to exist but was removed because nobody was using it. (!) It would be nice to have this because it would allow us to deal with polygons in a generic way without having to know which tags on a way indicate a polygon. It also allows us to enforce that the polygon be closed (last node == first node). I'm thinking specifically of tile cutting where a polygon needs to be managed differently than a simple line. Without a specific polygon type, any tool dealing with them will have to be updated to track changes in polygon tagging. This doesn't strictly need a new primitive; it could be accomplished by requiring a tag such as "polygon=yes" or whatever on a way which should be designated as a polygon. However, that method doesn't really allow us to enforce polygon-ness (closed way) at the API. Also, there wouldn't need to be a mandatory changeover; data could be migrated over time.<br>
<br>So, I'm sure I'll be shouted down, but I'll gladly listen to reasoned arguments.<br><br>Sincerely,<br><font color="#888888"><br>Karl<br></font><br>_______________________________________________<br>dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br>
<br></blockquote></div><br>