[OSM-talk] Bounding box

[Nick Hill]

In reply to the thread;


The selection of the bounding box size is based on the need to keep the OSM 
responsive by ensuring one user will not deny, either accidentally or on 
purpose, resources which would otherwise be used effectively by having a 
responsive and reliable server.

Not all workflows which have developed with a system without bounding box 
constraints will work equally well with bounding box constraints. So workflows 
will need to adapt. But at least with a working reliable server, a smooth, if 
modified, workflow is possible. Whereas before, no workflow at all was possible 
for some/much of the time. Moreover, a more responsive system will enable new, 
perhaps more efficient workflow methodologies. For example, if you downloaded 
the whole city as each locality request was slow, and you wanted to get as much 
editing done as possible before hitting the upload button because uploads were 
so slow, the new configuration could obviate the need to download the whole city 
in the first place and enable you to start editing much faster, and commit your 
changes more regularly, avoiding so much data loss when the client crashes.

The bounding box constraint is not based on the longest side of a box. It is 
based on the area of the box. It is therefore possible to select a box 3 degrees 
wide and 0.03 degree high. There is therefore no practical limit to downloading 
n-s or e-w features.

I generally avoid downloading whole cities when editing. I prefer to download an 
area  slightly larger than I am editing as I don't edit a whole city at once. I 
tend to edit a locality. Every workflow is actually a collection of workarounds.

If I see a problem, I will naturally evaluate possible fixes based on my work 
flow methods. I have noted the problems the changes will make to some work 
flows, and perhaps we can fix that eventually.