[OSM-dev] Area support

[Stefan Keller]

2008/7/9 Jochen Topf wrote:
> Having "real" areas would make the handling quite a bit more practical.

Agreed. An area (or polygon) simply is a basic geometry type; it's a fact in
practice and computational geometry.

The actual XML encoding of ways never really was according to best practices
and will not scale. This is because even for ways we have to read in all
nodes until the end of the stream/file before any way can be created. Now,
when we misuse (application oriented) relations to encode areas, processors
are again forced to read in *all* relation instances before any area can be
instantiated... Can't we do that better? (the crazyness would be complete
when one would 'consequently' encode areas *and* ways as partially ordered
relation instances which would point to nodes).

I would take this discussion as a chance to enhance the OSM/XML encoding:
Ways should be encoded with nodes (coordinates) embedded, and areas
(polygons) ought to be encoded with one way as outer boundary and zero or
more inner ways (boundaries) - embedded. I would even differentiate areas
which overlap and areas which don't (but this is more on the conceptional
and application modelling level and makes no difference in the encoding).
Look on the simplicity and usability of such an XML encoding below...
Stefan

Example of a enhanced OSM data encoding of an area and its boundaries
(ways) as proper property types:

  <area id="4304746" timestamp="2008-03-25T21:31:01+00:00" user="anonymous">
    <tag k="landuse" v="water"/>
    <tag k="created_by" v="JOSM"/>
    <tag k="natural" v="water"/>
    <tag k="name" v="Lake of Zuerich"/>
    <geometry>
      <outerboundary>
        <way>
          <node lat="47.23439" lon="8.82187"</node>
          <node lat="47.23411" lon="8.82362"</node>
          ...
        </way>
        <way>
          ...
        </way>
      </outerboundary>
      <innerboundary>
        <way>
          <node lat="47.23411" lon="8.82111"</node>
          ...
        </way>
      </innerboundary>
      <innerboundary>
        <way>
          <node lat="47.23499" lon="8.82199"</node>
          ...
        </way>
      </innerboundary>
    </geometry>
  </area>

2008/7/9 Jochen Topf <jochen at remote.org>:

> On Wed, Jul 09, 2008 at 02:55:27PM +0200, Frederik Ramm wrote:
> > > No, we could continue to use multipolygon relations for that.
> > >
> > > I just wanted to point out that our existing primitives are "simple"
> ones: no compound objects, no holes, only one single coherent object. The
> new area primitive would be different from that (which of course is not
> necessarily an argument against it).
> >
> > You are right, but proponents of a proper area type also rightly say
> > that it is slightly inelegant to use relations on an upper level
> > (combining ways into routes etc.) on one hand and on a very basic
> > geometry level (putting holes into areas) on the other hand.
>
> Having "real" areas would make the handling quite a bit more practical.
> At the moment you can't read the ways sequentially and just do something
> with all the areas in there bit by bit. You always have to go through
> all of the ways and then all of the relations just to find out that most
> areas have no relation but are simple and you could have just used the
> way.
>
> Currently there are two ways of modelling an area, one for areas without
> holes, one for areas with holes. This makes handling it always a bit more
> difficult. Say you have a relation pointing to all parking lots belonging
> to a soccer stadium. Some of the parking lots have holes, some don't. So
> you have
>
> relation(all parking lots) +--> some ways (amenity=parking) --> some nodes
>                           +--> some relations (multipolygon) --> some ways
> (amenity=parking) --> some nodes
>
> Also to decide whether a way is a linestring or an area you have to look
> at the tags. If you have unknown tags, you can't decide what it is. If
> you had a distinct area type you can, say render areas you don't
> recognize in a default color or so.
>
> Jochen
> --
> Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/ +49-721-388298
>
>
> _______________________________________________
> 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/20080709/416747d9/attachment.html>