labelInImage and buffer usage

[assefa]

Just raising an issue I just saw related to Bug 1353.

Here is labelInImage the function 

int labelInImage(int width, int height, shapeObj *lpoly, int buffer)
{
  int i,j;

  for(i=0; i<lpoly->numlines; i++) {
    for(j=1; j<lpoly->line[i].numpoints; j++) {
      if(lpoly->line[i].point[j].x < -buffer) return(MS_FALSE);
      if(lpoly->line[i].point[j].x >= width+buffer) return(MS_FALSE);
      if(lpoly->line[i].point[j].y < -buffer) return(MS_FALSE);
      if(lpoly->line[i].point[j].y >= height+buffer) return(MS_FALSE);
    }
  }

  return(MS_TRUE);
}

It is called from mapgd like this : 
 labelInImage(img->sx, img->sy, cachePtr->poly, labelPtr-
>buffer+map_edge_buffer) ... 

 - the polygon used to do the testing *already contains* the buffer (the 
buffer here is the buffer defined in the label object)

 
 My issue is the following :
   * why is labelInImage try to substruct the buffer when doing the test. 
Doing this makes it ignore the buffer that the user wanted and labels might
be at the edge of the image.

   * the changes done for bug 1353 (map_edge_buffer) should be revisited by 
either calling the labelinimage function with a negative value or updating the 
labelinimage function to do the tests diffrently.

[sdlime]

The buffer is there to maintain distance between labels not the edge of the 
image. That is why the buffer is backed out in this case. It's not perfect 
because with rotated labels the buffer distance should really be computed 
based on the label angle. However, that is quite expensive and since buffer 
sizes tend to be relatively small I made the decision to use this 
approximation.

I don't think your first issue is a problem. I haven't seen Dan's solution so 
can't comment on the second.

Steve

[sdlime]

Refactored labelInImage() in r12911 (branch-6-0). Will commit to trunk as part of RFC 77 work. -Steve