inconsistent behaviour between 3.3/3.6 and 3.7 (or 4.0?)

[dgadoury@…]

I have a layer in a mapfile which behaves differently in 3.3 or 3.6 than it does
in 3.7/4.0. It is a layer which draws highway shields with a label in them. Here
is the layer:

  LAYER
    NAME "shield"
    DATA "hwy"
    TYPE ANNOTATION
    TILEINDEX "tileindex"
    STATUS ON
    MINSCALE 800001.0
    MAXSCALE 1500000.0
    CLASSITEM "NCLASS"
    LABELITEM "HWY_NUM"
    CLASS
      NAME "Interstates"
      EXPRESSION "A10"
      SYMBOL "interstate-"
      COLOR 0 0 0
      LABEL
        POSITION CC
        SIZE TINY
        MINDISTANCE 400
        MINFEATURESIZE 5
        COLOR 255 255 255
        PARTIALS FALSE
      END
    END
  END

All features have a value in NCLASS, but some have no value in HWY_NUM. In
3.3/3.6 if a feature has no value in the HWY_NUM a shield is not drawn. In
3.7/4.0 a shield is drawn, but with no label (or a blank label). To me the
expected behaviour is the 3.7/4.0 behaviour, so it leads me to wonder why those
shields are not drawn in 3.3/3.6.

I didn't want blank shields so I modified the layer to look like this for 3.7/4.0:

  LAYER
    NAME "shield"
    DATA "hwy"
    TYPE ANNOTATION
    TILEINDEX "tileindex"
    STATUS ON
    MINSCALE 800001.0
    MAXSCALE 1500000.0
    CLASSITEM "NCLASS"
    LABELITEM "HWY_NUM"
    FILTERITEM "HWY_NUM"
    FILTER /[^ ]/
    CLASS
      NAME "Interstates"
      EXPRESSION "A10"
      SYMBOL "interstate-"
      COLOR 0 0 0
      LABEL
        POSITION CC
        SIZE TINY
        MINDISTANCE 400
        MINFEATURESIZE 5
        COLOR 255 255 255
        PARTIALS FALSE
      END
    END
  END

This filters out features with no value in HWY_NUM so no shields are drawn where
there is no value for a label. The result is the same as with the previous layer
definition under 3.3/3.6.

[dmorissette]

Steve: Please see the bug description... is this an intentional change in 
behavior?  If not then we'll have a look and try to fix this before the release.

[sdlime]

I can verify that it's a blank trimming issue. If I revert the code in
mapxbase.c to the original version for 3.6 (or at least the function in
question) then it works as expected. I'm suprised though I would have thought
trimming trailing blanks would have worked and that code is applied in both
versions. Will try to fix tonite...

[sdlime]

Ok, got it fixed. The issue is with character xbase columns. The code to trim
trailing blanks doesn't work if the entire string is blank. It looks for a
non-blank character to start the trimming and in this case never finds it. The
leading trimming caught that case but since it's not done anymore...

So, I added a quick test after the first attempt at trimming to detect all blank
strings. Seems to work fine.

[dgadoury@…]

I'm glad to hear that it is fixed. I'm not sure which behaviour is considered
the correct one though. Will 3.7 now behave as 3.6 did, or will 3.6 be changed
to act a 3.7 does? 

[dmorissette]

The correct behavior was the 3.3/3.6 behavior where blank labels would not be 
drawn, so you wouldn't end up with empty shields.  

The bug was that your DBFs contained spaces in the label field (which is normal) 
but MapServer didn't trim the blank spaces correctly and Steve has fixed that.

 

[dmorissette]

I've upgraded our server and verified that things work fine when I take the 
FILTER out of your mapfile Dean.  (But I didn't update your master mapfile Dean, 
I'll leave that up to you)

Thanks Steve for the fix.