#3543 closed defect (fixed)
WGS84 to Mercator WMS Cascade Crazy Near Poles
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | WMS Client | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | rhow, dmorissette, KeithMoss |
Description
A client has encountered a problem with world wide requests in EPSG:4326 being cascaded by MapServer to a Mercator only WMS. The equivalent extent in Mercator is in theory unbounded in the Y direction and in practice is so extreme as to produce useless result due to "north south pixellation".
I am attaching a somewhat artificial sample map to a non-existant server (test.map) which when rendered using shp2img like this:
shp2img -all_debug 5 -m test.map -o out.png
reports via debug output a cascaded request like:
http://test.mapserver.org/wms.cgi?LAYERS=0&REQUEST=GetMap &SERVICE=WMS&FORMAT=image/jpeg&STYLES=&HEIGHT=180&VERSION=1.1.1 &SRS=EPSG:3857&WIDTH=360 &BBOX=-19925566.9553994,-62575754.8663339,19925566.9553994,62575754.8663267 &TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_inimage
Note the 125 million meter Y range of the BBOX. The question at hand is can we make a more appropriate cascaded request in a reasonably common situation like this?
Attachments (1)
Change History (7)
comment:1 by , 14 years ago
Status: | new → assigned |
---|
comment:2 by , 14 years ago
I am going to proceed to develop a patch so that WMS client layers do not have to be requested with exactly the same size and shape as the map output being produced and to honour metadata extents to limit the requests made to the remote wms.
comment:3 by , 14 years ago
Cc: | added |
---|
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It turns out that mapwmslayer.c already supported requests not the same size as the map due to work I did a while ago. I have added the ability to restrict the request based on layer extents which can be expressed via the EXTENT keyword or wms/ows_extent metadata.
It only kicks in for layers with only a single _srs listed on the basis that otherwise it is hard to know what coordinate system the extent is in. The support could be extended in the future to be smarter but this is sufficient for my client.
Updates to mapwmslayer.c are in trunk (r10536). I also incorporated an msautotest (r10534).
comment:5 by , 13 years ago
Hi Frank,
We seem to have run into an issue with this change.
We have one service (Service A) cascading to another of our services (Service B). They're both using the SRS (EPSG:900913).
We're finding the the BBOX that Service A uses in its request to Service B is altered from the BBOX which we asked Service A for. This causes the resulting image to stretc because the width and height are unaltered. For example, we asked Service A for:
BBOX=12856946.532288,-3764838.6714909,12862144.250212,-3759640.9535669
but Service B was asked for:
BBOX=12856946.532288,-3764838.6714909,12862144.250212,-3761969.13736867
We think this may be related to this change because adding another SRS to the wms_srs metadata property in Service A fixed the issue.
Unfortunately we can't easily provide a live URL because it's a private authenticated service at the moment.
Cheers
comment:6 by , 13 years ago
Cc: | added |
---|
Generally speaking map services based on mercator projections limit the latitude range (perhaps to -80 to +80), so my thought is to allow the person setting up the .map file a way of expressing the extents of the wms service in it's default projection and using that to restrict the area requested.
Note, this issue is at least vaguely related to #3179, and #3459.
If we limit the BBOX of a cascaded request we might also need to use a distinct width/height from that of the map - an issue that impacted #3409 but was never actually handled.