Filter parsing does not fail suitably if GML geometry is invalid

[ejn]

FLTParseFilterEncoding returns a superficially valid (passes FLTValidFilterNode) FilterEncodingNode if given a filter with a bad GML geometry (e.g. a Polygon without outer boundary).

This can be traced to FLTInsertElementInNode which does not set the eType to FILTER_NODE_TYPE_UNDEFINED if the geometry is bad and FLTShapeFromGMLTree which returns MS_TRUE and sets no error message even if OGR_G_CreateFromGMLTree returns NULL.

Using a bad GML geometry in a WFS filter query currently therefore results in a WKT read error (obviously the first point where the contents of the geometry in the parsed filter are actually checked!) rather than an invalid filter error. The parsing should however pick up the problem, as other consumers may choke badly.

The attached patch fixes this so that if the geometry is bad then MS_FALSE is returned from FLTShapeFromGMLTree, and an appropriate error message is set, and the returned filter node from FLTInsertElementInNode has eType FILTER_NODE_TYPE_UNDEFINED.

The immediate net result is that giving an invalid geometry in the WFS filter results in an "InvalidParameterValue / Invalid or Unsupported FILTER in GetFeature" exception instead of a rather more cryptic "NoApplicableCode / FLTApplyFilterToLayer() feailed / WKT processing failed / GEOS library error" exception.

[ejn]

Patch to make filter parsing react properly to a bad GML geometry

[ejn]

Patch to make filter parsing react properly to a bad GML geometry

[ejn]

Sorry, uploaded the wrong patch first time: both patches are identical apart from the filename (admin, feel free to delete one of them!)