[OSM-dev] proposal to kill areas
immanuel.scholz at gmx.de
Sat Jul 22 14:03:40 BST 2006
> > I think the "simplicism" that Steves sees in traiting ways and areas
> > equally is by accident and not a fundamental one.
> This is a problem with the API and the implementation not the
> specification of areas (personally I'm agnostic as to whether you want
> them to be a subtype of way or not).
Areas are clearly not a "subtype" in the terms of the liskov's
substitution principle (The meaning in almost any OO-language). This is
because you cannot just replace any occourences of "way" with "area" and
expect anything to have the correct behaviour.
Beg to all: Please don't fall in the classic square/rectangle - pit. ;)
> Exactly the same thing is true of
> segments - currently, the segments returned for a given bbox includes
> any segment that has at least one node inside the bounding box.
> However, this is not correct, since there is the possibility that a
> segment may run through a bbox, but have no nodes inside it (e.g. a
> road segment starting outside-left the bbox, and ending
> The API should be returning this segment.
Yep. This is a known bug. It isn't fixed and it is more likely, that the
definition of "map request" will be changed to something very strange
than this get fixed into the current server ;-).
There was a proposal how to "fix this a bit" some time ago, but never
got into code.
> Areas are no worse in this regard, though are more likely to cause
> problems because segment sizes are usually small, and areas are
> probably bigger (e.g area of 'outline of UK' for example).
Areas are MUCH more likely to be skipped out by requests, as the example
from 80n shows. Segments are usually extremly small, whereas areas can
also be used for things like "germany".
Now we discuss about whether or not a request should return objects,
whose describing data is not within the bounding box. This is
independent of how the area should be laid out, except that it may be
faster to implement correct requests with an data structure describing
areas as node-lists.
More information about the dev