[OSM-dev] proposal to kill areas

Etienne 80n80n at gmail.com
Sat Jul 22 09:18:06 BST 2006


On 7/22/06, Chris Morley <c.morley at gaseq.co.uk> wrote:
>
> 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.


Ways *are* ordered lists.  There is no requirement by the database schema
for ways to be a contiguous list of segments.

There is no requirement for a way to be closed in order for it to be
rendered as an area (using Osmarender/SVG).


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.


The SVG spec discusses this in quite a lot of detail.  The only requirement
is a polyline (a way in OSM terms).  It does not have to be contigouous, and
it does not have to be closed.

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.


No sorting is required to  render using SVG.

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.


Steve's  proposal was simple.  Drop Areas and use Ways that are suitably
tagged.  Osmarender has an implementation of this using SVG as a proof of
concept.

Can you show me any examples where it doesn't work please?  I'll try to make
them work.

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?
>
>
> _______________________________________________
> 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/20060722/05eee67e/attachment.html>


More information about the dev mailing list