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').
Currently (v.05), the wiki says in http://wiki.openstreetmap.org/index.php/Data_Primitives : "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)" 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: <area id="8007396" visible="true" timestamp="2007-09-26T19:07:16+01:00" user="a_user"> <wy ref="59907908"/> <wy ref="59907909"/> <wy ref="59907910"/> ... <tag k="created_by" v="an_application"/> <tag k="a_tag" v="a_value"/> </area> 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 http://www.interlis.ch/interlis2/download23_e.php(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), "3.3.11.13 Coding of surfaces and tessellations (p.89) and "Appendix C (informative) A small example Roads (p.100). -- Stefan 2008/5/6 Karl Newman <[EMAIL PROTECTED]>: > On Tue, May 6, 2008 at 1:25 AM, SteveC <[EMAIL PROTECTED]> wrote: > > > Without reference to the ongoing debate or the changeset stuff, > > > > is there anything else that should be put in 0.6? Probably a good idea > > to talk about it now. > > > > Best > > > > Steve > > > > 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. > > So, I'm sure I'll be shouted down, but I'll gladly listen to reasoned > arguments. > > Sincerely, > > Karl > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
