[OSM-dev] proposal to kill areas

Chris Morley c.morley at gaseq.co.uk
Sat Jul 22 08:58:42 BST 2006


Etienne wrote:
 >
 > As it stands at the moment, areas are identical to ways.  I've found
 > that it is quite feasible to treat ways as areas and have them render
 > properly.

 > There's no real need to even tag them with area=true as this is
 > implied by presence of an area like tag (eg amenity=parking).  That
 > said, some clients may like to generically identify all areas and
 > treat them in a particlar way (ignore them, process them first, or
 > whatever).

 > The SVG rules about how a polygon is filled are quite complex, but
 > seem to be fairly comprehensive and deal with all the boundary
 > conditions (like areas with holes in etc).  All that osmarender does
 > is pass this burden to SVG and let it work out how an arbitrary
 > polygon should be filled - I doubt that we can invent, or need to
 > invent, anything better.

Areas are currently represented by list of contiguous segments. As far
as I can determine (http://wiki.openstreetmap.org/index.php/XML_Schema)
this list was envisaged as ordered, the segments having the right
direction, and the list being closed: the 'from' of the first
segment being the 'to' of the last segment.  I think Osmarender 
currently makes some or all of these assumptions (and causes me 
problems). This is not the same as normal ways which can be non-ordered.

There was some short discussion in the Talk forum on about 9 June about 
difficulties with this: if there there are 3 adjacent areas the 
direction of the segments is incompatible and you need some additional 
feature to use this model.

In fact, the information on the area can be transmitted in an unordered
list of segments with random directions, without closure. So the
area structure with lists of segments could work, but would require a 
sorting process every time it was rendered, which is messy.

The obvious way to represent an area is an ordered list of nodes.

- This always represents some sort of area (with 3 or more nodes) and 
errors can be easily seen when rendered. The current method can be 
ill-formed.

- Is the simplest representation, with least processing (e.g. close to 
SVG), no involvement of zero-information constructs like segment 
direction, no additional concepts like reversed direction.

- It uses about half the storage - however, not a big issue in the near
future.

- Although am not familiar with the inner workings of the database and 
API, I guess its implementation would be close to the current method - 
using node ids rather than segment ids.

The representation of areas needs to be decided definitively now and 
rules laid down. The issue is simple, technical, non-political and 
timely - an achievable test for communal decision taking.

Chris


 >On 7/20/06, SteveC <steve at asklater.com> wrote:
 >>
 >> There are only 4 areas in OSM and osmarender treats certain tagged
 >> ways as an area. I figure it'd make the server simpler and make
 >> client area support simpler if 'area=true' on a way made it in to an
 >> area.
 >> Functionally, if they were working, an area is identical to a way
 >> already.
 >
 >> Thoughts?





More information about the dev mailing list