Opened 13 years ago
Closed 13 years ago
#3883 closed defect (fixed)
WMS server white map output
Reported by: | zanollim | Owned by: | dmorissette |
---|---|---|---|
Priority: | normal | Milestone: | 6.0.1 release |
Component: | WMS Server | Version: | 6.0 |
Severity: | normal | Keywords: | |
Cc: | chodgson, warmerdam |
Description
I have a layer in UTM WGS84 (EPSG:25832) so defined:
LAYER NAME "Ortofoto2009ld" GROUP Ortofoto2009 METADATA "wms_title" "title" "wms_abstract" "abstract" "wms_srs" "EPSG:25832 EPSG:4326" "wms_extent" "648300 5090700 677500 5116000" END STATUS OFF DATA "raster/ortofoto_2009.tif" TYPE RASTER PROCESSING "RESAMPLE=AVERAGE" MINSCALEDENOM 10001 END
If I request with a WMS client the layer in EPSG:25832 coordinates
- layer served by mapserver 5.4.1: I see the layer correctly
- layer served by mapserver 6.0.0: I see the layer correctly
If I request with a WMS client the layer in EPSG:4326 coordinates
- layer served by mapserver 5.4.1: I see the layer correctly
- layer served by mapserver 6.0.0: I see nothing (the map is white)
Is my layer definition wrong? Is it a bug of mapserver 6.0.0?
thanks, michele
Attachments (1)
Change History (12)
follow-up: 2 comment:1 by , 13 years ago
comment:2 by , 13 years ago
Replying to dmorissette:
What happens if you remove wms_extent and MINSCALEDENOM? What are your top level mapfile projection, extent and units set to?
Aha, the problem seems related to MINSCALEDENOM. If I comment that line, I see the map!
Also please try enabling "DEBUG 5" at the map and layer level and see if anything useful is logged (see http://mapserver.org/optimization/debugging.html).
Debug does not log errors nor anything useful
Unless one of the above points us to the solution, we'll probably need a complete testcase to reproduce.
Here my top level definition
[...] EXTENT 648300 5090700 677500 5116000 UNITS meters PROJECTION "init=epsg:25832" END WEB METADATA "ows_enable_request" "*" "ows_onlineresource" "http://11c80:8080/cgi-bin/mapserv6?map=/opt/geodati/ogc_services.map&" "ows_service_onlineresource" "http://11c80:8080/cgi-bin/mapserv6?map=/opt/geodati/ogc_services.map&" "ows_srs" "EPSG:25832 EPSG:4326" "wms_feature_info_mime_type" "text/plain" "wms_schemas_location" "http://schemas.opengeospatial.net" END IMAGEPATH "/tmp/" END [...]
comment:3 by , 13 years ago
Milestone: | → 6.0.1 release |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Sounds like something related to the way scale is computed. Could you please attach a complete mapfile to reproduce the problem and the params of the EPSG:4326 WMS GetMap request that works with 5.4 and fails with 6.0?
comment:4 by , 13 years ago
this is my GetMap request that works with 5.4 and fails with 6.0 (but works if I remove MINSCALEDENOM 10001 in the map file):
service=wms& version=1.1.0& request=getmap& srs=epsg:4326& bbox=10.9136,45.9469,11.2996,46.1814& width=832&height=589& layers=ortofoto2009ld& format=image/jpeg
and this is my complete map file
MAP NAME "ogc_services" EXTENT 648300 5090700 677500 5116000 UNITS meters MAXSIZE 10000 SHAPEPATH "/opt/geodati/" IMAGECOLOR 255 255 255 FONTSET "/opt/mapaccel/fonts/fontset.txt" SYMBOLSET "/opt/mapaccel/symbols/symbols.sym" RESOLUTION 96 CONFIG "PROJ_LIB" "/usr/local/share/proj/" CONFIG "MS_ERRORFILE" "/tmp/mserrorfile" DEBUG 5 PROJECTION "init=epsg:25832" END WEB METADATA "ows_enable_request" "*" "ows_title" "title" "ows_onlineresource" "http://11c80:8080/cgi-bin/mapserv?map=/opt/geodati/ogc_services.map&" "ows_service_onlineresource" "http://11c80:8080/cgi-bin/mapserv?map=/opt/geodati/ogc_services.map&" "ows_srs" "EPSG:25832 EPSG:4326" "wms_schemas_location" "http://schemas.opengeospatial.net" END IMAGEPATH "/tmp/" END LAYER NAME "Ortofoto2009ld" GROUP Ortofoto2009 METADATA "wms_title" "title" "wms_abstract" "abstract" "wms_srs" "EPSG:25832 EPSG:4326" "wms_extent" "648300 5090700 677500 5116000" END STATUS OFF DATA "raster/ortofoto_2009.tif" TYPE RASTER PROCESSING "RESAMPLE=AVERAGE" MINSCALEDENOM 10001 END END
comment:5 by , 13 years ago
Cc: | added |
---|
The problem is in GetMapserverUnitUsingProj() in mapprojhack.c. Proj doesn't define degrees as a unit, so when the map is projected from from meters to degrees, it fails to figure out that it is in degrees, and so the scale is computed incorrectly and any layers which are scale dependent have no hope of being displayed correctly.
Patch attached.
by , 13 years ago
Attachment: | mapprojhack_degrees.patch added |
---|
Patch for mapprojhack.c to support detecting degrees as a unit
comment:6 by , 13 years ago
The patch works correctly on my test!
Thanks, I think the ticket can be closed.
michele
comment:7 by , 13 years ago
Cc: | added |
---|
Thank you for looking into this Chris. I didn't understand why this would have changed between 5.x and 6.0, but then I found out that GetMapserverUnitUsingProj() was completely reworked in r11022 for 6.0.
I have added Frank (PROJ maintainer) to CC to check whether there are other case like this that we may need to support. Another question for Frank is whether it's possible to use to_meter and proj=longlat in the same definition (probably not but I want to be sure). If yes then the patch would need to be modified to handle degrees in the to_meter case I guess.
comment:8 by , 13 years ago
Daniel,
to_meter never applies with proj=latlong so on quick inspection the logic of checking for proj=latlong and return MS_DD is reasonably sound. There are actually several ways of specifying latlong so it might be better to test with pj_is_latlong().
I have taken the liberty of applying this slightly alternate approach in trunk (r11829) and in the 6.0 branch (r11830).
Could someone confirm it is behaving as desired?
Sorry for busting this for 6.0.
comment:9 by , 13 years ago
I wondered if there were other ways to end up with degrees as units as well, but grep told me that the 3 cases (proj=latlong, units=*, to_meter=*) covered every case in my epsg file. Anyways surely Frank knows better (I was surprised to see that it was Frank's change that broke it!)
However, Franks fix using pj_is_latlong doesn't appear to be working for me. The test case is pretty simple - setup a layer using a meters-based data source, and some kind of scale limit, then request it via WMS as a lat-long projection (&SRS=EPSG:4326). Because it ends up treating the lat long coordinates as meters, the scale it calculates is always quite zoomed in - 1:100 or something, and anything with a minscaledenom in a reasonable range will never be displayed.
That said, it would appear that pj_is_latlong() just isn't working at all because it is returning the wrong answer based on my debugging...
comment:10 by , 13 years ago
comment:11 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Yah it took me a while to track down that pointer myself and then I realized the very next line of code should have made it obvious. Anyways, yes, this works.
What happens if you remove wms_extent and MINSCALEDENOM? What are your top level mapfile projection, extent and units set to?
Also please try enabling "DEBUG 5" at the map and layer level and see if anything useful is logged (see http://mapserver.org/optimization/debugging.html).
Unless one of the above points us to the solution, we'll probably need a complete testcase to reproduce.