Opened 21 years ago
Closed 21 years ago
#504 closed defect (fixed)
not all tiled rasters displayed
Reported by: | Owned by: | sdlime | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | MapServer CGI | Version: | 4.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
Tiled raster data are not completely displayed in MS 4.x especially when using layer projection different than map projection. Only one or none raster is displayed. During panning different rasters are revealing accidentaly. In 3.6.x version it worked well. I looked into source code (mapraster.c) and found in the function msDrawRasterLow this code (1297): if(layer->tileindex) { /* we have in index file */ if(msSHPOpenFile(&tilefile, "rb", msBuildPath3(szPath, map->mappath, map- >shapepath, layer->tileindex)) == -1) if(msSHPOpenFile(&tilefile, "rb", msBuildPath(szPath, map->mappath, layer- >tileindex)) == -1) return(MS_FAILURE); if((tileitemindex = msDBFGetItemIndex(tilefile.hDBF, layer->tileitem)) == - 1) return(MS_FAILURE); searchrect = map->extent; #ifdef USE_PROJ if((map->projection.numargs > 0) && (layer->projection.numargs > 0)) msProjectRect(&map->projection, &layer->projection, &searchrect); // project the searchrect to source coords #endif status = msSHPWhichShapes(&tilefile, searchrect); if(status != MS_SUCCESS) numtiles = 0; // could be MS_DONE or MS_FAILURE else numtiles = tilefile.numshapes; //here the values are good :) } //here the values are empty :( When I print the values (eg. numtiles) from inside the block, I get proper values (the searchrect projected walues are good, numtiles ok...). If I attempt to print them after the block, I get empty values (in the case of numtiles predefined value 1). In result only one raster is then processed (I think). It seems like the values are locally declared in the block but it is not true. My last idea is - some error in memory allocation in underlying functions. Has anything change from 3.6.x here? Any idea? ...
Attachments (1)
Change History (7)
comment:2 by , 21 years ago
Hmm, I don't see how this could be happening. It doesn't look like leaving the scope should change anything. I haven't done much work with tiled raster maps lately, but as far as I know it mostly works ... at least when the rasters aren't being reprojected. Can you provide a smallish example that we can use to reproduce the problem?
comment:3 by , 21 years ago
The error reveals only (?) when projected. Here is the URL to WMS service providing the map of Czech republic: http://www.premathmod.cz/cgi-bin/mapserv?map=../bnh/cechy/cr_wms_en.map (It can be viewed in common WMS viewer like www.wmsviewer.com or directly in our one: http://mapserv.netart.cz/mapserv/palm/pda_wms02.phm? wms=add&newserver=http://www.premathmod.cz/cgi-bin/mapserv? map=../bnh/cechy/cr_wms_en.map ) It contains the Forest layer (raster). When panning across the map in the eg. 1:200000 scale only one forest tile is seen. I can prepare also demonstration project and data to send, if it is possible, but it requires some work (next week?). Stepan Kafka
comment:4 by , 21 years ago
Stepan, I don't expect to dig into this bug unless you, or someone, can produce a map and supporting data that demonstrate the problem. I've spent most of today trying to reproduce another mapserver bug report with no success and it has somewhat turned me off the "experiment" to reproduce approach. Best regards,
comment:5 by , 21 years ago
Steve, Frank, excuse me to trouble you again but I need some information about this bug status before my own research :) Thank you very much. Stepan Kafka
comment:6 by , 21 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Stepan, I applogise. This fell through the cracks during my time away in December and I never returned to it to realize you had excellent data to reproduce the problem. It turns out the problem is that existing pen ids were being reused on subsequent tiles. With resampling turned on, the subsequent renders were actually into different gdImg objects (the temporary input to the resampler) which didn't actually have the colors allocated but because the pen was set in the layerObj classes it was assumed they were. The fix is to clear the pen values in the layerObj->class entries before color allocation in msDrawRasterLayerGDAL(). The change looks like this: warmerda@gdal2200[124]% cvs diff mapdrawgdal.c Index: mapdrawgdal.c =================================================================== RCS file: /data2/cvsroot/mapserver/mapdrawgdal.c,v retrieving revision 1.14 diff -r1.14 mapdrawgdal.c 443c443,455 < --- > > /* > * Wipe pen indicators for all our layer class colors if they exist. > * Sometimes temporary gdImg'es are used in which case previously allocated > * pens won't generally apply. See Bug 504. > */ > if( gdImg && !truecolor ) > { > int iClass; > for( iClass = 0; iClass < layer->numclasses; iClass++ ) > layer->class[iClass].styles[0].color.pen = MS_PEN_UNSET; > } > The new code goes in before the comment about "Get colormap for this image.", and it should be trivially retrofittable back into any MapServer 4.xish version of mapdrawgdal.c. Note, the bug does not occur if not using classes, or if resampling is not used. The problem turns out not to have been related to tile selection at all. They were all being loaded and rendered. The problem was just that the colors of some tiles (all after the first in this case!) were being treated as transparent due to the pen issues. The fix has been committed to the current development version of mapserver.
Note:
See TracTickets
for help on using tickets.