[webmap-discuss] WMS Requests: Rounding BBOX

[Allan Doyle]

On Sep 21, 2006, at 06:32, Christopher Schmidt wrote:

> On Thu, Sep 21, 2006 at 12:20:01PM +0200, Steven M. Ottens wrote:
>> Christopher Schmidt wrote:
>>> Today, an OpenLayers user asked me why we weren't rounding BBOX  
>>> values
>>> in our tiled image requests, since it was causing problems with his
>>> reverse proxy caching to have OpenLayers not do so. The primary  
>>> reason
>>> this isn't done at the moment is that I couldn't pick a good  
>>> value to
>>> use :)
>>>
>>> 6 decimal places seems to be a generally good value to cut-off at  
>>> when
>>> working in degrees: that gets you down to half-meter accuracy (I
>>> think?). Does anyone have any other thoughts on this? How have you
>>> addressed rounding BBOX requests in your own applications?
>> 6 decimal places for lat/long is fine. I don't think we need to be  
>> able
>> to give bounding boxes in mm on lat/long systems anyway. But 6  
>> decimal
>> places for projected ones is a bit overkill. Can you make sure that
>> those bounding boxes are rounded in a more sensible way?
>
> What is sensible? I know that I can implement it in OpenLayers, but
> there needs to be some kind of agreement on what makes sense... the
> problem being that what makes sense for you or I doesn't make sense  
> for
> everyone.
>
> For systems using meters, usually two decimal places is overkill...  
> but
> there might be someone working with extremely large scale cad drawings
> (1:10, or 1:100) where webmap clients make sense... and that 1 cm
> difference could be major.

> Should rounding be based on the current scale? I think that's the only
> way to make sure that requests are never going to lose precision which
> is neccesary for correctly displaying the map -- otherwise, when  
> you get
> into 1px = 1unit, you'll run into problems with most any rounding...
Let's not forget that by the time you have 1cm resolution, while it's  
nice to have cacheability and tiling, you're at a point of  
diminishing returns. The higher the resolution, the less likely you  
are to wind up working in an area that's already cached. Also, at  
such high resolutions, I could envision setting up local caches/tiles  
when needed.

So maybe there's a step function rather than a specific  
rounding:scale ratio that's maintained.

This again seems to be a case that favors a "simple" and an  
"extended" version. The simple version can be good to 1cm or 10 cm  
and most mashup-level things will be perfectly happy. Even 1m seems  
overkill for all but 1% of use cases.

	Allan

>
> Does anyone have use cases where rounding has played an effect?
>
> I know that when I was first working with ka-map, I actually did see
> rounding have an effect. THe ka-Map tiling engine rounded scale  
> requests
> to the nearest integer. Since ka-Map requires you to enter fixed  
> scales,
> this had never been a problem: but when you try to combined OpenLayers
> and ka-map, it did become a problem -- rounding scale to the nearest
> integer caused errors that could be as high as half a tile as the tile
> got further and further from the geographic meridians. So, I'm aware
> that these things do matter... but not sure at what point they matter.
> Rounding the scale to four decimal places brought any such differences
> to being invisible -- but is that enough for bounding boxes?
>
> -- 
> Christopher Schmidt
> MetaCarta
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webmap-discuss-unsubscribe at mail.osgeo.org
> For additional commands, e-mail: webmap-discuss-help at mail.osgeo.org
>

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org