WFS problem with Filter accepting by MapServer with BBOX

[assefa]

reprorted by Diatchkov Vitali : untitle@MAIL.RU


The MapServer 4.8.* that we use as a WFS server has some problems with
GeoTools WFSDataStore at the client side. The Filter being produced by
GeoTool library looks like:

========================
<Filter><BBOX><PropertyName>msGeometry</PropertyName><Box><coordinates
decimal="." cs="," ts=" ">3669974.159827543,7034913.012544877
3670967.818494744,7035739.51367928</coordinates></Box></BBOX></Filter>
========================

and I suppose it conforms to GML2. But MapServer does not handle attributes
in<coordinates> tag: decimal, cs, ts. If these attributes are encoded in the
filter XML then MapServer returns an exception that Filter is invalid or not
supported.

The following filter work fine:
========================
<Filter><BBOX><PropertyName>msGeometry</PropertyName><Box><coordinates>
3669974.159827543,7034913.012544877
3670967.818494744,7035739.51367928</coordinates></Box></BBOX></Filter>
========================

Is it possible to fix the issue? Sure, it is a problem of MapServer not of
GeoTools library because these attributes are part of spec. And the
combination GeoTools + MapServer is quite widespread.


We would like to see this problem to be fixed, don't know what is the
situation in the following versions of MapServer..

[assefa]

setting target to 5.0

[assefa]

Partially fixed : ignore for now parameters decimal="." cs="," ts=" " so that
filters using the default values for these parameters are parsed properly.   

[tomkralidis]

It looks like mapogcfilter.c needs to change the hardcoded cs and ts values to fetch from the attributes if they exist: (lines 1510, 1515, 1517).

I did a local patch of this which ran into type problems with msStringSplit. msStringSplit assumes a char type as the delimiter. Should we always assume that a single char will always be the delimiter for msStringSplit?

Note that all occurences of msStringSplit in the codebase are against hardcoded, single char values.

[assefa]

Should we always assume that a single char will always be the delimiter for msStringSplit?

I think so; that is what the function expects.

[tomkralidis]

Replying to assefa:

Should we always assume that a single char will always be the delimiter for msStringSplit?

I think so; that is what the function expects.

Right. I guess I'm questioning the msStringSplit function definition, then. What happens if someone submits a filter statement as follows:

<Filter>
 <BBOX>
  <!PropertyName>msGeometry</PropertyName>
  <Box>
   <coordinates decimal="." cs="DELIM2" ts="DELIM1">-140DELIM240DELIM1-50DELIM284</coordinates>
  </Box>
 </BBOX>
</Filter>

[assefa]

I guess the function has to be changed (or have another function) that handles a string type delimiter. It either that or limit the support of cs and ts to one character (which seems to be the most probable case)

[tomkralidis]

Replying to assefa:

I guess the function has to be changed (or have another function) that handles a string type delimiter. It either that or limit the support of cs and ts to one character (which seems to be the most probable case)

Agreed in terms of the most probably case. We should also document the single char only support in the Filter HOWTO.

Attached is a patch for starters (which generates type warnings on build)

[assefa]

Tom, do you think we should apply the patch for 5.0 for the one charcter case for ts and cs. Looking into the path, it is missing the decimal element to be consistent.

[tomkralidis]

Replying to assefa:

Tom, do you think we should apply the patch for 5.0 for the one charcter case for ts and cs. Looking into the path, it is missing the decimal element to be consistent.

It covers the most common use case, so I think it would be okay (patch sans the type warnings)

[assefa]

Added support to use cs and ts values ad discussed r6759