sfkeller at gmail.com
Tue May 6 19:42:33 BST 2008
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
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"
<tag k="created_by" v="an_application"/>
<tag k="a_tag" v="a_value"/>
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), "22.214.171.124 Coding of surfaces and tessellations (p.89) and "Appendix
C (informative) A small example Roads (p.100).
2008/5/6 Karl Newman <siliconfiend at gmail.com>:
> On Tue, May 6, 2008 at 1:25 AM, SteveC <steve at asklater.com> 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
> So, I'm sure I'll be shouted down, but I'll gladly listen to reasoned
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev