[OSM-dev] 0.6

Stefan Keller 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"
    <wy ref="59907908"/>
    <wy ref="59907909"/>
    <wy ref="59907910"/>
    <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), " Coding of surfaces and tessellations (p.89) and "Appendix
C (informative) A small example Roads (p.100).
-- Stefan
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
> time.
> So, I'm sure I'll be shouted down, but I'll gladly listen to reasoned
> arguments.
> Sincerely,
> Karl
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080506/7a02aeb2/attachment.html>

More information about the dev mailing list