[OSM-dev] Relation bounding boxes

[Frederik Ramm]

Hi,

Matt Amos wrote:
> what is the bounding box of a relation?

I like your idea 1 best:

> 1) adding or removing nodes or ways from a relation causes them to be
> added to the changeset bounding box. adding a relation member or
> changing tag values causes all node and way members to be added to the
> bounding box. this is similar to how the map call does things and is
> reasonable on the assumption that adding or removing members doesn't
> materially change the rest of the relation.

One could of course put in arbitrary amounts of magic and handle this 
differently based on the type of relation but I don't think we want to 
go there; the API has never looked at the semantics of data until now 
and it should probably stay that way.

People will use bounding boxes to monitor changes in an area. The 
question we must ask is: What constitutes a change to an area, and on 
which side do we want to err?

We'll never be perfect; there will alway be things that change the map 
in an area but are not noticed by simple bbox tracking. (Example: 
Imagine you're tracking a bounding box sized 5x5 miles on an insland. 
Someone breaks the coastline just outside your bounding box: Your area 
gets "flooded" without having changed.)

Your concept "adding or removing nodes or ways from a relation causes 
them to be added to the changeset bounding box" boils down to viewing 
relation membership as a quality of the way/node, much like Potlatch 
presents it to the viewer. As you correctly say, this will only cause 
trouble if adding something to a relation in location A will somehow 
change the quality of another relation member in location B. I am 
struggling to find an example of that; it would be far fetched at the 
very least.

I suggest that we make it possible for the client to *extend* (not 
reduce!) the bounding box, perhaps through a POST request to the 
changeset object. If we have that functionality and if we should ever 
encounter relation types where the above is true, then a well-behaved 
editor could use this method to increase the bbox in that special case.

The bit "adding a relation member or changing tag values causes all node 
and way members to be added to the bounding box" sounds sensible too.

Make sure that your code does not blindly assume each relation to have a 
bounding box though; it is possible to have relations with ONLY tags and 
no members. This is rarely used but there are use cases for it, e.g. 
creating a placeholder member of another relation or complex tagging. 
It's not supported by any clients but it might come in handy one day.

> 2) any change to a relation causes all its members' bounding boxes to
> be added to the changeset, recursively. this might be the case if we
> consider tag values to "cascade" onto members recursively (superways).

One-deep superways are already adequately covered by your proposal 1; 
I'd say we tackle nested relations once they start to get widely used. 
It is not something that desperately needs to be done now, it would not 
require waiting for 0.7 should we decide to change the logic some time 
later.

Here, too, we could count on client support. Remember that the 
server-side bounding box code is only there as some sort of minimum that 
works even for clients that don't know about bounding boxes. A 
cooperative client could have detailed information about what kinds of 
relations it works with and whether or not a change in a certain 
relation warrants the extension of the bounding box.

I'm for erring on the side of "too small bounding box" rather than 
making them too large, and then allowing the client to increase it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"