#2351 closed defect (fixed)
Producing very large maps fails without appropriate errors
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL Support | Version: | 4.10 |
Severity: | normal | Keywords: | raster |
Cc: | dmorissette, flavio, benft |
Description
Rendering this map:
NAME "Üp 1:10'000" SIZE 9000 9000 STATUS ON EXTENT 628750 242000 637500 248000 UNITS METERS IMAGECOLOR 255 255 255 IMAGETYPE JPEG OUTPUTFORMAT NAME jpeg DRIVER "GD/JPEG" MIMETYPE "image/jpeg" IMAGEMODE RGB EXTENSION "jpg" FORMATOPTION "QUALITY=100" END #============================================================================= # Swiss projection #============================================================================= PROJECTION "init=epsg:21781" END # ---------------------------------------------------------------------------- # UP # ---------------------------------------------------------------------------- LAYER NAME "UP 1:10000" TYPE RASTER STATUS ON #MAXSCALE 10000 DATA 'test.tif' PROCESSING "RESAMPLE=AVERAGE" PROJECTION "init=epsg:21781" END END END # Ende MapFile
for file:
Driver: GTiff/GeoTIFF Files: test.tif Size is 35000, 24000 Coordinate System is `' Origin = (628749.875000000000000,248000.125000000000000) Pixel Size = (0.250000000000000,-0.250000000000000) Metadata: TIFFTAG_SOFTWARE=IrfanView TIFFTAG_XRESOLUTION=1016 TIFFTAG_YRESOLUTION=1016 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: COMPRESSION=PACKBITS Corner Coordinates: Upper Left ( 628749.875, 248000.125) Lower Left ( 628749.875, 242000.125) Upper Right ( 637499.875, 248000.125) Lower Right ( 637499.875, 242000.125) Center ( 633124.875, 245000.125) Band 1 Block=35000x1 Type=Byte, ColorInterp=Palette Metadata: NBITS=1 Color Table (RGB with 2 entries) 0: 255,255,255,255 1: 0,0,0,255
fails on win32 system, when using the command shp2img on the map. The output map is 9K x 9K and it appears between the main gd image and the memory allocated in the raster resampling code the 32bit address space is exhausted. This might be ok, except that reasonable errors are not returned. Just a report that the layer failed to render.
It appears the raster rendering code does not report out of memory errors sensible, and in fact does not even check malloc() failures in some places it ought to. Problem experienced in 4.10 and 5.
Change History (5)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
comment:3 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
err, make that r6944 for the 5.0 changeset.
comment:4 by , 16 years ago
I think I may be victimized by this: the map image I'm attempting is 4204x2687
and I get these errors messages (which are bogus) when calling $image = $oMap->drawQuery() :
PHP Warning: Error: msDrawRaster(): Unrecognized or unsupported image format PHP Warning: Error: drawEPP(): EPPL7 support is not available. Is this fix released? Would it be possible to patch it in without rebuilding mapserver (which I'm not able to do)? We have 4.10.0
Thanks! Ben Thompson
comment:5 by , 16 years ago
Cc: | added; removed |
---|
Ben,
This doesn't sound like the same error to me. And there is no way to backport these fixes into 4.10 without someone rebuilding from source.
In the process of investigating this report (using "limit vmemorysize 510megabytes on linux) I found some problems with GDAL's out-of-memory handling addressed at: