Open tbonfort opened 12 years ago
Author: assefa Date: 2007/02/22 - 17:51
setting target to 5.0
Author: assefa Date: 2007/02/26 - 22:58
Partially fixed : ignore for now parameters decimal="." cs="," ts=" " so that
filters using the default values for these parameters are parsed properly.
Author: tomkralidis Date: 2007/06/22 - 15:52
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.
Author: assefa Date: 2007/06/22 - 16:47
Should we always assume that a single char will always be the delimiter for msStringSplit? I think so; that is what the function expects.
Author: tomkralidis Date: 2007/06/22 - 17:03 Replying to [comment:4 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>
Author: assefa Date: 2007/06/22 - 17:37 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)
Author: tomkralidis Date: 2007/06/22 - 18:08 Replying to [comment:6 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)
Author: assefa Date: 2007/08/08 - 17:42 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.
Author: tomkralidis Date: 2007/08/09 - 15:13 Replying to [comment:8 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)
Author: assefa Date: 2007/08/31 - 15:33 Added support to use cs and ts values ad discussed b9150f71da3ca44167551d2b69e66df7d6aeb6fe (r6759)
Reporter: assefa Date: 2007/02/22 - 17:50