not all tiled rasters displayed

[tbonfort]

Reporter: kafka@email.cz Date: 2003/12/03 - 11:37

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

[tbonfort]

Author: sdlime Date: 2003/12/04 - 20:28

Boy, I dunno. I changed code in some of the shape handling stuff to avoid 
passing around the shape path, but that's about it. I don't know about the 
projection code. Frank would have to comment. Do you know if panning works fine 
when not projected?

Steve

[tbonfort]

Author: fwarmerdam Date: 2003/12/04 - 20:51

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?

[tbonfort]

Author: kafka@email.cz Date: 2003/12/05 - 10:29

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

[tbonfort]

Author: fwarmerdam Date: 2003/12/10 - 22:47

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,

[tbonfort]

Author: kafka@email.cz Date: 2004/02/02 - 16:14

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

[tbonfort]

Author: fwarmerdam Date: 2004/02/02 - 18:23

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.