Global Mapper v26.0

A WMS/Wrong SRS issue for V11.B3

vax
vax Global Mapper UserTrusted User
edited August 2009 in Bug Report
Hello,

I tried to access a WMS data source using latest B3 of v.11. WMS data source (and GM) return an error of type INVALID SRS given : SRS must be valid for all layers.

After close examination of GM's HTTP GET request it seems that GM issues a SRS=EPSG:4326. The bounding-box parameter is also in EPSG:4326 coordinates.

The WMS data source invloved delivers data in the EPSG:32635 reference system, it also expects an SRS=EPSG:32635 and the corresponding BBOX coordinates. I tried to enter WMS&SRS=32635 in the service name edit box but this not affect the GET request at all.

Maybe it's good to mention, that QGIS connects to the same WMS source without a problem.

Comments

  • global_mapper
    global_mapper Administrator
    edited August 2009
    Can you provide the URL for the WMS data source so that I can give it a try?

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • vax
    vax Global Mapper User Trusted User
    edited August 2009
    Hi, I sent all the details in a private message as this WMS URL is not public.
  • global_mapper
    global_mapper Administrator
    edited August 2009
    I took a look and found the issue. The WMS source is reporting that EPSG:32635 is available, but not reporting a bounding box in that projection, so the default lat/lon (EPSG:4326) projection is used (typically all WMS servers support that, but I guess not this one). I have updated Global Mapper to just calculate unspecified SRS boxes itself so now your data source works. I have placed a new build at http://www.globalmapper.com/global_mapper11.zip with the change for you to try. Simply download that file and extract the contents into your existing v11.xx installation folder to give it a try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • vax
    vax Global Mapper User Trusted User
    edited August 2009
    Thanks a lot, now it works.

    There is a strange thing - a scale drawing is downloaded with each tile, at the lower-left corner of the tile. Can this be avoided as the image gets overcrowded with scales ?

    Another issue - GEOTIFF/jpeg export of loaded WMS data works very slow. Export of all data visible on-screen seems to re-download WMS data instead of just exporting the already downloaded WMS contents. All this takes a lot of time, for example a piece 5000 x 5000 UTM meters and sample spacing 1 m takes a mere 1 hour and frequently crashes my computer.

    Best regards,
    vax
  • global_mapper
    global_mapper Administrator
    edited August 2009
    vax,

    The little scale drawing is coming from the WMS server itself as part of each tile that Global Mapper downloads. Typically there would be a different layer listed on the WMS with different styles, but I'm not seeing any for the 'orthophoto' layer. You might need to contact the provider of the WMS server to see if there is a way to turn that off.

    When you are viewing WMS data you are just downloading from whatever zoom level is appropriate for your display. So if you export the same area as displayed but at a different (usually much higher) resolution, Global Mapper has to download the data again for the export so that it can get the data at an appropriate resolution for the export.

    When you do your export, are you using a spacing of 1m x 1m or using the default for this source, which pops up as 0.1m x 0.1m? I would expect an area of 5000m x 5000m downloaded at 1m resolution to download pretty fast (maybe 10 minutes given how slow this server is), but at 0.1m by 0.1m you are talking 100 times as much data to be downloaded and it could take forever.

    When your computer crashes, are you getting an error message?

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • vax
    vax Global Mapper User Trusted User
    edited August 2009
    Hi Mike, thanks for helping me :-)

    it's a bad news about this annoying scale drawing, I hoped there's some kind of a WMS client command that can turn it off.

    About the slow export - when observing the final image (jpeg export), it seems that GM has downloaded 96 tiles on the X and the same number on the Y axis, thus resulting in almost 10 000 tile downloads (I judge the tile count thanks to the same annoying scale drawing).

    My settings were 5000 x 5000 UTM meters, sample spacing of 1 m, resulting in a jpeg of size 5000 x 5000 pixels.

    As I saw GM downloads WMS tiles of size 512 x 512 pixels and a jpeg of size 5000 x 5000 pixels should be constituted of approx. 10 tiles x 10 tiles = 100 tiles. Instead of that I see 10 000 tiles. I suppose GM downloads erroneously too-detailed tile set for the given boundary and then downsamples the image (which is not necessary as a less-detailed tile set can be downloaded).

    Thanks again,
    vax.
  • vax
    vax Global Mapper User Trusted User
    edited August 2009
    I further examined the GM PNG file cache while exporting another 5000 x 5000 m image. It seems that GM downloads PNGs at the maximum possible resolution of the WMS server. Each tile is 512 x 512 px and the scale drawing is from 0 to 16 m, counting 10 pixels per meter, or 0.1 meters per pixel (I set sample spacing to 10 m for this test).

    The slow export is obviously to the very high load to the WMS server - around 10000 tiles/4 gigabytes of data downloaded for a 5000 m x 5000 m perimeter. Another issue - the Cancel button of the JPEG-export dialog does not work and I have to terminate GM via the Task Manager.
  • global_mapper
    global_mapper Administrator
    edited August 2009
    I'll take a look and let you know what I find. The download should be happening at the most appropriate resolution for the export and not using the full resolution layer.

    The Cancel button is only checked every so often (like between tile downloads), so if a tile download is taking a really long time the Cancel button might not respond for a while.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • global_mapper
    global_mapper Administrator
    edited August 2009
    It seems that you stumbled upon a pretty significant bug that was indeed causing the WMS data to pull from the most detailed zoom level available instead of the most approprriate for the export resolution. I have placed a new build at http://www.globalmapper.com/global_mapper11.zip with the change for you to try. Simply download that file and extract the contents into your existing v11.xx installation folder to give it a try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • vax
    vax Global Mapper User Trusted User
    edited August 2009
    Hello,

    sample spacing now affects download. I am not sure if it calculates right the most-appropriate resolution as my test image now consist of 17 x 17 tiles (5000 x 5000 UTM meters, 1 m sample spacing which produces 5000 x 5000 px image). Increasing the sample spacing to 2 m downloads 10 x 10 tiles but the resolution of the image is cut-down to 2500 x 2500 px. Again it seems that GM downloads too much data and then downsamples tiles.
  • global_mapper
    global_mapper Administrator
    edited August 2009
    Actually this is expected for up to 2X the requested resolution. Global Mapper breaks a WMS source into a series of predefined zoom levels, thus allowing meaningful caching as you zoom and pan around. I think for your source there was a zoom level around 0.55m resolution and another around 1.1m, so your 1.0m resolution export would draw from the next higher resolution layer, or the 0.55m one, so you would download a little more than you would get from calculating, but still much less than if you pulled from the most detailed layer.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • vax
    vax Global Mapper User Trusted User
    edited August 2009
    Thanks a lot - the last post fully explains my observations, so I can count this issue closed.