Ticket #673 (closed defect: fixed)
layer->project flag not being reset properly
|Reported by:||warmerdam||Owned by:||warmerdam|
|Component:||MapServer C Library||Version:||4.3|
|Cc:||sgillies@…, mapserver@…, sdlime|
Description (last modified by sdlime) (diff)
Currently the layer->project flag is MS_TRUE if a layer needs (or potentially needs) reprojection and if MS_FALSE we know we don't have to look at the projection object at all. In various places, such as mapdraw.c:msDrawShape() we have code constructs like this: #ifdef USE_PROJ if(layer->project && msProjectionsDiffer(&(layer->projection), &(map->projection))) msProjectPoint(&layer->projection, &map->projection, ¢er); else layer->project = MS_FALSE; #endif If it finds that the map and layer projections are identical then it sets the "project" flag to false so we don't have to do any more checking. However, in a MapScript or other long lived session operating on a map it is possible to thereafter reset the map projection (such that it would differ from a layer projection) but not have the layer->project flag reset to MS_TRUE. This can basically result in layers not being reprojected when they should under some esoteric situations. The problem is slightly worse with map rotation in the picture as the msProjectionsDiffer() also has to check if there is a rotation in effect and if so, returns TRUE even if the projections don't differ since there is a transformation to be applied. I think the solution is to review all code that uses the layer->project flag and ensure that it is recomputed carefully on each pass. Thus msDrawLayer() might reset the flag to MS_TRUE each time it is called. But the flag is also used in various query code and possibly other places, so I think other places also need to be updated. I propose to implement a msLayerSetProjectFlag(layerObj*) that would just set the layer->project flag appropriate at that point depend on whether projections exist, USE_PROJ is set, and the projections differ. This could be inserted at strategic points. Technically this issue exists in 4.2 and earlier versions but I think the situations in which it can cause problems are sufficiently esoteric that we can just address it in 4.3.
Note: See TracTickets for help on using tickets.