On 7/20/06, <b class="gmail_sendername">Nigel Magnay</b> <<a href="mailto:nigel.magnay@gmail.com">nigel.magnay@gmail.com</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;">

On 20/07/06, Etienne <<a href="mailto:80n80n@gmail.com">80n80n@gmail.com</a>> wrote: > I'm not sure that the constraint that the start and end should be the same > node is either necessary or always appropriate.

<br>><br>> Consider that you are mapping just one side of a large lake.  The need to<br>> join up the two loose ends creates an artifact in the database that is not<br>> true.  They will eventually join up but you may not be able to complete the

> task all in one session. > Wouldn't you just keep those as segments until you had mapped the area, and then create the way (area) at that point? Or create a way for 'lake edge', and gradually expand it until it was an area?

</blockquote><div><br>It may never happen if part of the lake shore was in a restricted area.  That shouldn't have to prevent describing the rest of it.<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;">

> Additionally, when serving up content within a bbox there may well be areas<br>> that are only partially within the bbox.  Incidentally, Osmarender/SVG seems<br>> to cope with this situation quite well (not sure whether this is by accident

<br>> or design).<br>><br><br>Actually, it's worse than that; for a given bbox area there may be<br>areas whose segments don't even intersect the bbox, but should be<br>displayed rendered (for example, displaying a section of map that's

<br>inside a large forest area).</blockquote><div><br>In that case I guess you wouldn't be able to see the wood for the trees :-) <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;">

> Etienne<br>><br>><br>> On 7/20/06, Nigel Magnay <<a href="mailto:nigel.magnay@gmail.com">nigel.magnay@gmail.com</a>> wrote:<br>> ><br>>  IMO - Sounds to me like an area is a subclass of way, with the

<br>> constraint that the start and end node must be the same. The API<br>> should enforce this, but it doesn't neccesarily require separate<br>> storage.<br>><br>> On 20/07/06, Immanuel Scholz < <a href="mailto:immanuel.scholz@gmx.de">

immanuel.scholz@gmx.de</a>> wrote:<br>> ><br>> > > There are only 4 areas in OSM and osmarender treats certain tagged ways<br>> > > as an area. I figure it'd make the server simpler and make client area

<br>> > > support simpler if 'area=true' on a way made it in to an area.<br>> > ><br>> > > Functionally, if they were working, an area is identical to a way<br>> > > already.<br>> > >

> > > Thoughts? > > > > I am not very happy with an area defined as it is currently. > > > > The problem I see is, that there are too many possibilities to specify an > > ill-formed area.

> > > > I have no problem with deleting the 4 areas (probably test areas anyway?), > > skip out the area feature from the server for now and maybe reopen the > > brain storming for a different data structure solution.

<br>> ><br>> > Even if the current data structure is kept, I dislike the idea of<br>> > specifying an "area" as a parametrized kind of way.<br>> ><br>> ><br>> > Ciao, Imi<br>> >

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

http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br>> ><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>><br>><br></blockquote></div><br>