[OSM-dev] proposal to kill areas

Immanuel Scholz immanuel.scholz at gmx.de
Sat Jul 22 13:51:44 BST 2006


Hi,


>         You will not get the "area" returned, because a way does not
>         need to be 
>         returned in this case.
> 
> So if you request a tiny bbox of a small part of a village, in a
> forest, in the Borough of Medina on the Isle of Wight would you expect
> to get the area that describes the forest, and an area that describes
> the borough and an area that describes the whole coastline of the Isle
> of Wight and an area that describes the boundary of the whole of the
> EC?  

Of course. This is the only correct answer for a request to get all
objects in a specific bounding box.



> This is an extreme example, but you get the idea.  If you are
> interested in something that is wholly *inside* an area then you
> probably don't need the area.

You are speaking of specialized request that return only those objects
that the server thinks a client might currently want. This is a great
performance optimizing extension to any API.

But this type of request is a "nice to have" to reduce traffic for
clients, when the result does not need to be complete. In the same
category are requests that merge nodes together which are too close to
differentiate anyway or that just skip unimportant roads by
big-scale-requests.


But no matter how many such conveniently requests you provide, you have
to have a way to get to all the data for offline clients like JOSM, that
try to keep an consistent cache of the data. Denying objects in requests
is critical to offline editors, since users could start enter objects
for whose they think they are not there. Doubled entered objects
conflicts are very hard (if not impossible) to detect automatically.

(Online editors does not suffer that much from this issue, since the
user usually chooses an appropriate view which then usually includes
area boundaries anyway..) 



>         In fact, this example shows nicely, that areas are NOT ways,
>         since areas
>         are planear objects while ways are not. 
> 
> Agreed, but the only information needed to *describe* an area is
> exactly the same as that needed for a way.

No. Ways can contain spaces, can be (currently) in strange and
non-contiguous segment order etc. On the other hand, areas have an
inside and an outside.



> "give me all ways with tag natural=forest that this point is within" -
> its an identical problem.

This is not possible, since a point cannot be within a way, except you
mean exactly on the line. 

If you are speaking of the latter, then the problem even get worse,
since now you have the same procedure signature but different technical
meaning!


Ciao, Imi.







More information about the dev mailing list