2

I'm trying to resolve an error when accessing a MapServer layer via MapCache.

I'll add excerpt of the relevant files below, but the basic situation is:

When accessing a particular WMS layer via MapCache, there is one small area of the map with missing tiles. The rest of the layer works fine.

Apache log shows the following:

[Tue Jan 14 13:23:22 2014] [error] [client ::1] Premature end of script headers: mapserv

[Tue Jan 14 13:23:22 2014] [error] [client 192.168.56.1] wms request for tileset Aerial returned an unsupported format:\n<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>Please contact the server administrator,\n [no address given] and inform them of the time the error occurred,\nand anything you might have done that may have\ncaused the error.</p>\n<p>More information about this error may be available\nin the server error log.</p>\n<hr>\n<address>Apache Server at localhost Port 80</address>\n</body></html>\n

When building the cache for this layer, no errors are reported.

Even stranger, accessing the WMS layer directly through MapServer works perfectly.

The above error is the only meaningful error I've been able to find.

To debug this I've set DEBUG 5 on both MAP and LAYER properties and tried accessing the 'broken' tile both via MapCache and MapServer. The results are... weird.

I'll post the files below, but note that:

  • The log for the MapCache request ends prematurely: msDrawRasterLayerGDAL(): red,gree
  • The source and other attributes referenced in the log are vastly different between the MapServer and MapCache request. Everything about the request is the same (projection, bounding box, etc), except the 'bad' request is passed through MapCache.

Files / URLs

MapCache request (broken)

  • URL: http://MYHOST/maps?LAYERS=Aerial&BGCOLOR=0x444444&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fjpeg&SRS=EPSG%3A27700&BBOX=363840,145762,365600,147522&WIDTH=512&HEIGHT=512
  • Log: apache.mapcache.log

MapServer request (works)

  • URL: http://HOST/cgi-bin/mapserv?MAP=/path/to/Aerial.map&LAYERS=Aerial&BGCOLOR=0x444444&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fjpeg&SRS=EPSG%3A27700&BBOX=363840,145762,365600,147522&WIDTH=512&HEIGHT=512
  • Log: apache.mapserver.log

MapCache config excerpt - (Paths / URIs altered)

mapcache.xml

Map file

Aerial.map

Improve this question
10
  • if mapserver works correctly with that raster, I'd say that mapcache is the problem. How did you create the raster? what gdal says about your raster? gdalinfo yourRaster.format will give some more details.
    – Gery
    Commented Jan 14, 2014 at 14:19
  • The layer is made up of ECW/EWW files. I've run gdalinfo on two tiles, one within the affected area and one just outside of the affected area. The output looks broadly similar save for different origin and coordinates, which all seem to be decent (i.e. not obviously wrong) values.
    – user2889370
    Commented Jan 14, 2014 at 14:48
  • I've also noticed this is only happening at certain zoom levels. When zoomed out, the layer loads correctly.
    – user2889370
    Commented Jan 14, 2014 at 14:49
  • your mapserver/gdal have support for ECW? check here: lintips.com/?q=node/97 and freegis.org/pipermail/mapserver-de/2009-August/004034.html
    – Gery
    Commented Jan 14, 2014 at 14:58
  • Yes should have mentioned, it's been compiled with ECW support. The rest of the layer (and other ECW layers) all work fine.
    – user2889370
    Commented Jan 14, 2014 at 15:01

2 Answers 2

Reset to default
2

This is clearly a mapserver issue, although you are only seeing it triggered through extent /sizes passed by mapcache (mapcache will alter the passed in extent/sizes to account for metatiling). If you replay the failing mapcache request, your logs will also show a request from mapcache to mapserver requesting the data to be tiled. That second url should be the one you can start debugging with (as it will also fail if you load it directly in your browser).

Improve this answer
3
  • Yeah I just clocked on to this... I removed meta tiling and many of the images have loaded and I've identified the specific area that's failing. the new error message is: drawGDAL(): Unable to access file. GDALDatasetRasterIO() failed:
    – user2889370
    Commented Jan 15, 2014 at 13:01
  • maybe you have a tileindex entry that's referencing an erroneous ECW?
    – Thomas Bonfort
    Commented Jan 15, 2014 at 17:10
  • Appreciate the help, I'll take another look at this later today and post back with the results. Since my last comment I run gdalinfo on the range of .ecw files around where it was failing. (e.g. the logs show MapServer processing xxx1.ecw xxx2.ecw xxx3.ecw and then fails. I've checked all of the files +/- 5 around the failure point and there's nothing obviously wrong with them
    – user2889370
    Commented Jan 16, 2014 at 11:08
0

I'd say then that the problem is the scales or tile sizes. Since your map file doesn't have specific scales, mapcache (very likely) is interpreting (or no interpreting) the right scales for your raster.

Try adding some scales in it and see how it works, similar to: https://stackoverflow.com/questions/2868027/layers-with-same-name-but-multiple-scale-in-mapserver-mapfile

Since tiles are involved, that could be the issue also, check this post about it: http://lists.osgeo.org/pipermail/mapserver-users/2013-May/074610.html.

Improve this answer
2
  • I added a CLASS to the layer with MINSCALEDENOM set to 0 and MAXSCALEDENOM set to an arbitrary low number, 10 just to see if it had an affect. This didn't result in an error, just a blank tile, so good news so far... I then set it to an arbitrarily high number so it definitely would be drawn, 5000000 and this resulted in the same error as before.
    – user2889370
    Commented Jan 14, 2014 at 15:22
  • Regarding your second link: The choice to go with 512 was due to the high number of files involved. There are numerous layers which all require a high level of zoom. This means a large number of individual files to cache. At 256, it was hitting the inode limit of the server. The client-side performance hit of moving to 2x the image size was fairly small so it seemed like a good comprimise.
    – user2889370
    Commented Jan 14, 2014 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.