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. Brett 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), > "3.3.11.13 <http://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] > <mailto:[EMAIL PROTECTED]>>: > > On Tue, May 6, 2008 at 1:25 AM, SteveC <[EMAIL PROTECTED] > <mailto:[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] <mailto:[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 > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
