Merge BBox/Bounds/ProjectionBounds classes

[simon04]

Conceptually, all are rectangles of coordinates. However, each class completely different and compatible functions and constructors.

This is a simple data class for "rectangular" areas of the world, given in lat/lon min/max values.

A BBox represents an area in lat/lon space.

In contrast to a Bounds object, a BBox can represent an invalid (empty) area.

… "rectangular" areas of the world, given in east/north min/max values.

Use case: I'm just trying to get the area spanned by a collection of primitives for #19381. After half an hour I'm just confused… :(

[GerdP]

I also wondered, but I did bother to merge them. Both are used frequenty, also in many plugins.
Maybe LoadAndZoomHandler.zoom(Collection<OsmPrimitive> primitives, Bounds bbox) is close to what you need?

[stoecker]

I'm pretty sure there is a reason we have different classes. They have semantic differences.

[stoecker]

I'm just trying to get the area spanned by a collection of primitives

Should be simple:

b = new BBox();
for(prims) b.addPrimitive(..)

[GerdP]

reg. #19381 you probably have to do more when it comes to deleted objects. A deleted way/relation has no nodes/members and thus will return an invalid bbox.

[simon04]

I stumbled across this again via #20613:

org.openstreetmap.josm.data.osm.QuadBuckets often invokes org.openstreetmap.josm.data.IQuadBucketType#getBBox which always returns a new BBox (e.g. in org.openstreetmap.josm.data.osm.Way#getBBox) since BBox is mutable causing plenty of useless allocations just for the purpose of testing org.openstreetmap.josm.data.osm.BBox#bounds(BBox). Only rarely, the returned object is mutated.

Following the concept of the org.openstreetmap.josm.data.osm.I-interfaces, we should introduce an IBBox or IBounds interface without mutating methods. Alternative suggestions are welcome :)

[simon04]

In 17703/josm:

see #19399 - Extract interface IBounds