[OSM-dev] proposal to kill areas

Chris Morley c.morley at gaseq.co.uk
Sat Jul 22 13:45:04 BST 2006


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

Yes,sorry, I should have said ways do not have to be contiguous. Areas 
do, so thinking that you can simplify things by *always* treating them 
the same could have dangers.
> 
> 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.

Well the area drawn by the path with nodes A B C D is not the same as 
that drawn by the path A C B D  The sorting I meant was to determine 
that A was connected to B and not to C
> 
>     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.

Attached is a little osm file with three adjacent areas which doesn't 
render properly with osmarender2 (using msxsl).

If one of the segments (id=-15) is reversed, it does render ok, which 
shows I don't quite understand how osmarender is working. The point is, 
though, that, at present, segment direction is critical - and it 
shouldn't be something you have to think about in connection with areas. 
It will be possible to make osmarender work properly (with the 'sorting' 
mentioned above). But if you are going to make changes to the way areas 
are represented, shouldn't you consider the one (list of nodes) which is 
most natural and likely to have fewest complications in the future?

Chris

> 
>      >On 7/20/06, SteveC <steve at asklater.com <http://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?
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: area-test.osm
Type: text/xml
Size: 1617 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20060722/77cf23d1/attachment.xml>


More information about the dev mailing list