SLD parsing fails on Windows

[assefa]

When we use only one NamedLayer with one Rule, everything works fine. When
we use 2 NamedLayer elements, the original map gets drawn. We also tried
copying the LAYER in the MAP file, so that we did not reference the same
NamedLayer twice. This does not make any difference, the layer is rendered
without any Filter/SLD applied.

The reason we want to use this kind of SLD is to have a selection drawn on
top of another selection, and have the result in one image.

Any info appreciated.

<StyledLayerDescriptor version="1.0.0">
   <NamedLayer>
      <Name>Gemeentes1</Name>
      <UserStyle>
         <Title>xxx1</Title>
         <FeatureTypeStyle>
            <Rule>
               <Filter>
                  <PropertyIsEqualTo>
                     <PropertyName>GEMNAAM</PropertyName>
                     <Literal>Amsterdam</Literal>
                  </PropertyIsEqualTo>
               </Filter>
               <LineSymbolizer>
                  <Geometry>
                     <PropertyName>center-line</PropertyName>
                  </Geometry>
                  <Stroke>
                     <CssParameter name="stroke">#ffff00</CssParameter>
                     <CssParameter name="stroke-width">10.0</CssParameter>
                  </Stroke>
               </LineSymbolizer>
            </Rule>
         </FeatureTypeStyle>
      </UserStyle>
   </NamedLayer>
   <NamedLayer>
      <Name>Gemeentes2</Name>
      <UserStyle>
         <Title>xxx2</Title>
         <FeatureTypeStyle>
            <Rule>
               <Filter>
                  <PropertyIsEqualTo>
                     <PropertyName>GEMNAAM</PropertyName>
                     <Literal>Amsterdam</Literal>
                  </PropertyIsEqualTo>
               </Filter>
               <LineSymbolizer>
                  <Geometry>
                     <PropertyName>center-line</PropertyName>
                  </Geometry>
                  <Stroke>
                     <CssParameter name="stroke">#0000ff</CssParameter>
                     <CssParameter name="stroke-width">2.0</CssParameter>
                  </Stroke>
               </LineSymbolizer>
            </Rule>
         </FeatureTypeStyle>
      </UserStyle>
   </NamedLayer>
</StyledLayerDescriptor>


AY :

 I have tried to debug the problem this morning but was not successful. I can 
reproduce this on a windows machine but the the same setting works on a Linux 
setup. What is even worst was that on Windows, the request works when I am in 
the debugger.  I could not really pin point where was the problem but It seems 
that the inital parsing of the XML is the probelm (the XML seems to be valid 
but the parser returns an error).

[assefa]

Bart,

 Can you check if this happens with the latest build from maptools.org. I was 
trying to debug this today and realized that I can't reproduce it any more.

[dmorissette]

Any update on this Bart? Can you still reproduce the problem?

[bartvde@…]

I just checked and I got the same error with the new binary.

[Wed Apr 14 09:51:48 2004] [error] [client 192.168.3.107] Wed Apr 14 09:51:48
2004 - : WMS server error. Invalid SLD document

A colleague of mine found out this is caused by the line separator.
If I save the same XML document in Textpad in the UNIX file format, then there
is no problem.

I do get a new error in the Apache error log when using this SLD:
[Wed Apr 14 09:56:09 2004] [error] [client 192.168.3.107] Wed Apr 14 09:56:09
2004 - msAddImageSymbol(): Unable to access file. Error opening image file
/ms4w/apps/general/map/sld_line_symbol.

[dmorissette]

Can you please attach the XML document that causes the crash?  ZIP it so that
the linefeeds are not converted when we download it.

BTW, bug 567 also reported an issue with linefeeds in parsing of XML post data
but we didn't have a testcase in that bug, perhaps that's related to the same
parser issue?

[bartvde@…]

SLD XML document which fails in Mapserver

[dmorissette]

Assefa, can you look at this before Friday or should I take it?

[assefa]

Lookin at it.

[assefa]

Update on this :

 The error message msAddImageSymbol() is a "normal" error message : It is 
triggered in the sld when for example a line style with a certain width is
 created :

STYLE
          COLOR 255 255 0
        MAXSIZE 100
        MINSIZE 1
        SIZE 10
        SYMBOL "sld_line_symbol"
END

 The sld_line_symbol is an inline symbol added by the sld when needed.
 All lines try to use the sld_line_symbol so the first call is to check if this
symbol exists and this check uses the function msGetSymbolIndex that generates
the message. I could change the code to look myself into the array of symbols if
this is a big deal.

 I am still trying to reproduce this xml parsing issue on windows.

 

[dmorissette]

The error message is definitely misleading.  The msGetSymbolIndex() problem has
been raised by Sean before and would be solved if we fixed bug 612.  I'll work
on bug 612 tonight then.

[bartvde@…]

Assefa, I have set up a testcase here on our Windows Apache webserver.

1)
SLD with Windows line feeds:
http://www.vz.geodan.nl/users/bart/sldtestbart_pc.xml

GetMap request associated with 1:
http://www.vz.geodan.nl:1111/cgi-bin/sld/mapserv_41.exe?
map=/ms4w/apps/general/map/gemeentes2.map&service=WMS&request=GetMap&layers=Geme
entes,Gemeentes2&bbox=100000,350000,300000,550000&width=500&height=500&srs=EPSG:
28992&version=1.1.1&format=image/png&sld=http://www.vz.geodan.nl/users/bart/sldt
estbart_pc.xml

2) SLD with Unix linefeeds:
http://www.vz.geodan.nl/users/bart/sldtestbart_unix.xml

GetMap request associated with 2:

http://www.vz.geodan.nl:1111/cgi-bin/sld/mapserv_41.exe?
map=/ms4w/apps/general/map/gemeentes2.map&service=WMS&request=GetMap&layers=Geme
entes,Gemeentes2&bbox=100000,350000,300000,550000&width=500&height=500&srs=EPSG:
28992&version=1.1.1&format=image/png&sld=http://www.vz.geodan.nl/users/bart/sldt
estbart_unix.xml

[fwarmerdam]

I have run xmlreformat (a thin wrapper around CPLParseXMLString()) on the
SLD documents and had no problem parsing either one. 

I will try again on win32 to see if that is an issue. 

[fwarmerdam]

OK, I haven't reproduced the problem myself, but looking at this code in
mapogcsld.c/msSLDApplySLDURL() I think I see the problem:

            if ((fp = fopen(pszSLDTmpFile, "r")) != NULL)
            {
                int   nBufsize=0;
                fseek(fp, 0, SEEK_END);
                nBufsize = ftell(fp);
                rewind(fp);
                pszSLDbuf = (char*)malloc((nBufsize+1)*sizeof(char));
                fread(pszSLDbuf, 1, nBufsize, fp);
                pszSLDbuf[nBufsize] = '\0';
            }

The file is opened with default file type.  On win32 it will be opened in
text mode.  But ftell() is not reliable on text streams.  I imagine the
nBufsize is wrong (too long or too short) and the resulting buffer
of data is either clipped or includes a bunch of binary junk. 

I would suggest opening the file in binary mode (use a mode of "rb" instead 
of "r").  In binary mode the length calculation should work fine.  The
CPL MiniXML code should have no problem reading linefeeds in unix or
PC format so we don't need the file access to do it for us. 

Assefa ... I'll bounce this back to you to make the change and test it. 

[assefa]

Thanks Frank. That did solve the problem on my case. I am also updating the
mapcontext.c file that would have a similar problem.

Bart, do you need a new windows binaries. If not this fix will be part of the
4.2 release.

 Marking bug as fixed.

[dmorissette]

I have committed a fix for bug 612 in which msGetSymbolIndex() was modified to
be able to avoid the call to msAddImageSymbol().  I modified all the mapogcsld.c
code to pass try_addimage_if_notfound=MS_FALSE. I'm sure that was the right
thing to do for most places that called msGetSymbolIndex(), but one or two calls
were not as obvious.  

Assefa, can you please review all calls to msGetSymbolIndex() in mapogcsld.c to
make sure they do the right thing.  Also, could someone please confirm that the
error about msAddImageSymbol() is gone with that new version?

[assefa]

mapogcsld.c seems to be correct, test files seems to work properly.

[bartvde@…]

4.2 will be fine (we have a workaround by saving the files as Unix).

[dmorissette]

I'm not sure to understand your comment Bart.  Are you saying that there are
still problems in 4.2 and that you still need the workaround?

[bartvde@…]

Daniel, I was referring to Assefa's question:

"Bart, do you need a new windows binaries. If not this fix will be part of the
4.2 release."

With my answer I meant that I am okay with waiting for the 4.2 release binaries 
and that Assefa does not have to provide a new binary.

[dmorissette]

Ah... makes more sense now. sorry for the noise.