On 7/22/06, <b class="gmail_sendername">Chris Morley</b> <<a href="mailto:c.morley@gaseq.co.uk">c.morley@gaseq.co.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Etienne wrote:<br> ><br> > As it stands at the moment, areas are identical to ways.  I've found<br> > that it is quite feasible to treat ways as areas and have them render<br> > properly.<br><br> > There's no real need to even tag them with area=true as this is

<br> > implied by presence of an area like tag (eg amenity=parking).  That<br> > said, some clients may like to generically identify all areas and<br> > treat them in a particlar way (ignore them, process them first, or

<br> > whatever).<br><br> > The SVG rules about how a polygon is filled are quite complex, but<br> > seem to be fairly comprehensive and deal with all the boundary<br> > conditions (like areas with holes in etc).  All that osmarender does

<br> > is pass this burden to SVG and let it work out how an arbitrary<br> > polygon should be filled - I doubt that we can invent, or need to<br> > invent, anything better.<br><br>Areas are currently represented by list of contiguous segments. As far

<br>as I can determine (<a href="http://wiki.openstreetmap.org/index.php/XML_Schema">http://wiki.openstreetmap.org/index.php/XML_Schema</a>)<br>this list was envisaged as ordered, the segments having the right<br>direction, and the list being closed: the 'from' of the first

<br>segment being the 'to' of the last segment.  I think Osmarender<br>currently makes some or all of these assumptions (and causes me<br>problems). This is not the same as normal ways which can be non-ordered.</blockquote>

<div> 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).

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There was some short discussion in the Talk forum on about 9 June about<br>difficulties with this: if there there are 3 adjacent areas the

<br>direction of the segments is incompatible and you need some additional<br>feature to use this model.</blockquote><div><br>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. 

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In fact, the information on the area can be transmitted in an unordered<br>list of segments with random directions, without closure. So the

<br>area structure with lists of segments could work, but would require a<br>sorting process every time it was rendered, which is messy.</blockquote><div><br>No sorting is required to  render using SVG. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.

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

<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- It uses about half the storage - however, not a big issue in the near future.

<br><br>- Although am not familiar with the inner workings of the database and<br>API, I guess its implementation would be close to the current method -<br>using node ids rather than segment ids.<br><br>The representation of areas needs to be decided definitively now and

<br>rules laid down. The issue is simple, technical, non-political and<br>timely - an achievable test for communal decision taking.</blockquote><div><br>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.  

<br><br>Can you show me any examples where it doesn't work please?  I'll try to make them work.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Chris<br><br><br> >On 7/20/06, SteveC <steve at <a href="http://asklater.com">asklater.com</a>> wrote:<br> >><br> >> There are only 4 areas in OSM and osmarender treats certain tagged<br> >> 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?

<br><br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">

http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br></blockquote></div><br>