WMS server white map output

[zanollim]

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

[dmorissette]

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.

[zanollim]

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
[...]

[dmorissette]

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?

[zanollim]

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 

[chodgson]

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.

[chodgson]

Patch for mapprojhack.c to support detecting degrees as a unit

[zanollim]

The patch works correctly on my test!

Thanks, I think the ticket can be closed.

michele

[dmorissette]

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.

[warmerdam]

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.

[chodgson]

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...

[warmerdam]

Sorry Chris - I was passing the wrong pointer. I have committed fixes in trunk and 6.0 branch (r11831, r11832). Thanks for testing, and I'd appreciate one more go around.

[chodgson]

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.