Better support for large bbox

[Mashin6]

It often happens that someone edits objects on different continents thus creating a huge bbox. Osmcha just shows empty bbox in those cases, which makes it impossible to find were the edits happened. The graphical representation of changed objects should be appropriately upscaled to ensure visibility.

[grinapo]

[This may be a backend problem, please tell me if I shall open an issue there, too.]

Based on recent unhappy osmcha users I would like to propose a very specific solution.

There is a filtering feature on large BBox, namely bbox size bound; so we already have a feature to select problematic bboxes.

1. It would be useful to have "check within actual bboxes" function, which would select the actual bounding box on the large (out of bounds) bbox dataset and would only select the changeset if there is real local data present. This way overlapping large bbox with no local data would be hidden.
2. For the purposes of display it would be good if it was possible to select "use current bbox only" which would restrict every display (tool) to the current / selected bbox, including achavi. For a huge bbox overpass usually timeouts while a huge bbox changeset with a limited bbox query works well.

The first would help people not to see large bbox changesets which doesn't change anything locally, the second would make it easier for them to verify those which do.

First is probably one additional round on matching changesets and one additional postgis select; the second is probably a bbox parameter for the specific tools.

(The issue #416 may be related/duplicate.)

[Lee-Carre]

Relevant comment from a different issue:

We can't do it because we don't store all features in our database (it would be much more complex and expensive to query changesets considering all its features).

[grinapo]

Is the database schema/content documented somewhere? This is a problem for a few users and would be nice to find a good solution for them, even if it would involve some extended processing (like querying overpass for those small number of large-bbox edits, if there isn't local data stored). Since large bbox edits are required for some tasks this is really something shall be fixed, if possible.