[OSM-dev] proposal to kill areas
c.morley at gaseq.co.uk
Sat Jul 22 08:58:42 BST 2006
> 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
> 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
> 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
- 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
- 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.
>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
>> Functionally, if they were working, an area is identical to a way
More information about the dev