[OSM-dev] 0.6

Brett Henderson brett at bretth.com
Wed May 7 02:06:21 BST 2008

Being fairly intimate with the issues involved in trying to split files 
into bboxes and polygons I'd love to see a polygon concept.  Currently 
it is almost impossible to split osm files into tiles suitable for 
devices such as a garmin.  I've created a pgsql schema which will 
provide the basis for splitting nodes and ways more effectively but 
polygons are impossible without resorting to complex and constantly 
changing tag analysis.  As for creating too many new osm types, I think 
the advantages of this outweigh the bad.  We already have a node which 
represents a single point, a way which represents a line, and a polygon 
type would be a natural progression with another dimension added.  
Unless we start modelling 3D objects we then have a complete set of 
primitives for 2-dimensional modelling.

Just my 2 cents.


Stefan Keller wrote:
> 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), 
> " <> 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 
> <mailto:siliconfiend at gmail.com>>:
>     On Tue, May 6, 2008 at 1:25 AM, SteveC <steve at asklater.com
>     <mailto: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 <mailto:dev at openstreetmap.org>
>     http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
> ------------------------------------------------------------------------
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev

More information about the dev mailing list