[MapProxy] MapProxy - WMS feed from MapProxy renders tiles with different scale when compared with OSM on MapServer

[andrew kovacs]

The client I am using is built off of the NASA WorldWind client app.  Based
off of some of the forums from NASA I can see some of the resolutions that
are being requested:


*Level 0, Tile delta 36", 512 pixels, resolution 0.0703125 (=36/512)*Level
1, Tile delta 18", 512 pixels, resolution 0.0.03515625 (=18/512)
Level 2, Tile delta 9", 512 pixels, resolution 0.017578125 (=9/512)
Level 3, Tile delta 4.5", 512 pixels, resolution 0.08789063
*Level 4, Tile delta 2.25", 512 pixels, resolution 0.04394531*
Level 5, Tile delta 1.125", 512 pixels, resolution 0.02197266
Level 6, Tile delta 0.562", 512 pixels, resolution 0.001098633
Level 7, Tile delta 0.28125", 512 pixels, resolution 0.000549316
Level 8, Tile delta 0.140625", 512 pixels, resolution 0.000274658
*Level 9, Tile delta 0.0703125", 512 pixels, resolution 0.000137329*


I tried using the initial resolution and converted to metres using the
mapproxy-util scales tool but the results did not prove anything useful.

Also, I can see the config file that gets generated on my client side when
accessing the WMS from MapProxy (I have attached it).  I also have attached
the config file that gets generated when I access MapServer directly.

>From what I can see, the configurations are very similar but the "number of
levels" are different.  Accessing MapServer gives me 20 levels (and the
data looks correct) and MapProxy gives me 18 levels (and does not look
correct).

I attempted to force the grid to use 20 levels in MapProxy, but my
understanding was 20 levels was the default anyways.  I also changed the
file size to 512 and format to jpeg, but it didn't seem to change the
appearance of the tiles.

Any help going forward would be appreciated, I can provide more info if
needed.

Thanks!

Andrew










<?xml

On Tue, Aug 26, 2014 at 2:39 AM, Oliver Tonnhofer <olt at omniscale.de> wrote:

> Hi,
>
> On 19.08.2014, at 19:00, andrew kovacs wrote:
> > I am having some trouble figuring out why my cached images in MapProxy
> are a different scale than the source images on MapServer.  I have an OSM
> cache generated on MapServer and I can query this service directly from my
> client.  The WMS feed produces clear images which are the correct scale for
> my map extent.  However, when I request the WMS feed through MapProxy, the
> tiles that are generated (from the same source as the initial request) the
> scale appears to be off.  The images that are generated at the client level
> are not clear.
>
>
> You need to configure MapProxy to have a cache level with the same
> resolution that your client requests to get the best results. For example:
> If your client requests a 5m/px resolution but MapProxy has only cache
> levels for 4m/px and 8m/px, then it will take the 4m/px and resample that
> to the 5m/px resolution. You can change the resampling method to get better
> results, but it's still resampled.
>
> You can add a debug source to your layer to see which resolution was
> requested by your client. But this will only work if your client makes
> requests at fixed scales. If that's not the case, then check out the
> res_factor and sqrt2 option.
>
>
>
>
> Regards,
> Oliver
>
> --
> Oliver Tonnhofer  | Omniscale GmbH & Co KG  | http://omniscale.com
> OpenStreetMap WMS and tile services         | http://maps.omniscale.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20140908/f3458ef0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MapServer-osm.xml
Type: text/xml
Size: 1278 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20140908/f3458ef0/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MapProxy-osm.xml
Type: text/xml
Size: 1315 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20140908/f3458ef0/attachment-0001.xml>