[Filter] upgrade to Filter 1.1.0

[tomkralidis]

(for reference: this stemmed from ticket #2105).

MapServer currently supports the OGC Filter Encoding Specification, version 1.0.0.

Filter Encoding 1.1.0:

Specification: ​http://portal.opengeospatial.org/files/?artifact_id=8340)

Schemas: ​http://schemas.opengis.net/filter/1.1.0/

Examples: ​http://schemas.opengis.net/filter/1.1.0/examples/

Here is what FES 1.1.0 provides over and above FES 1.0.0:

a./ Addition of SortBy, thereby allowing a Filter expression the opportunity to specify a sortation column, either ascending or descending (ASC or DESC). Example:

<ogc:SortBy>

<ogc:SortProperty>

<ogc:PropertyName>title</ogc:PropertyName> <ogc:SortOrder>DESC</ogc:SortOrder> </ogc:SortProperty>

</ogc:SortBy>

b./ GML Object id support, i.e.:

<Filter>

<GmlObjectId gml:id="TREESA_1M.1234"/>

</Filter>

...which isn't far from FeatureId (see ticket #2102)

Other notes:

a./ do we want to support functions (like sin, cos) and arithmetic operators (Sub, Add, etc.) ?

b./ spatial ops: which ones do we support? From FES 1.1.0:

Equals

Disjoint

Touches

Within

Overlaps

Crosses

Intersects

Contains

!DWithin

Beyond

BBOX

c./ note section 8.3 of the spec which deals with reprojecting (bscially, we process as per the underlying data's advertised projection, unless explicitly set by client (i.e. SRS in KVP, or SRS passed in Filter request). If an SRS is explicitly defined in the client's Filter packet, and not supported, then exception is thrown.

d./ comparison ops: which ones do we actually support? From FES 1.1.0:

PropertyIsEqualTo

PropertyIsNotEqualTo

PropertyIsLessThan

PropertyIsGreaterThan

PropertyIsLessThanOrEqualTo

PropertyIsGreaterThanOrEqualTo

PropertyIsLike

PropertyIsNull

PropertyIsBetween

e./ we support the logical ops (And, Or, Not)

f./ we have to now identify the GeometryOperands (i.e. gml:Point, gml:Polygon, etc.) that our filters support. Note that these must be in GML 3.1.1

g./ Note that most of the MapServer OGC codebase leverages Filter 1.0.0, with the exception of SOS (to which we've basically implemented Filter 1.1.0 without the new features (i.e. looks like Filter 1.0.0)

A big question here is how we develop this (i.e. msIO_printf or libxml2)? If the latter, do we do this only for FES 1.1.0?

My preference would be to encode just FES 1.1.0 with libxml2 and leave 1.0.0 as is.

[dmorissette]

This probably belongs to Assefa.

Pushing to 5.2 since it's clearly too late for 5.0.

[tomkralidis]

see r7271 for changes to Filter Capabilities per 1.1.0

[assefa]

Notes on GeometryOperands that will be supported

• the following geometries would be supported gml:Point, gml:LineString, gml:Polygon, and gml:Envelope

• the support of these geometries would be limited to gml3.1.1 SFL0/1 (​http://schemas.opengis.net/gml/3.1.1/profiles/gmlsfProfile/1.0.0/)

• we currently use OGR (OGR_G_CreateFromGMLTree) to parse the geometries from the xml for point line, and polygon. I will add a function to parse the Envelope (used only for BBOX operator). Although, OGR_G_CreateFromGMLTree is based on gml2, there are 2 things missing from what I can see to provide a gml3.1.1 SFL0 support for point,line,polygon:
  • parsing of a posList element (posList is simply a list of coordinates used for example for LineString and LineRing : <LineString ....><posList>31 42 53 64 55 76</posList></LineString> )

• polygon parsing: outerBoundaryIs and innerBoundaryIs are named interior and exterior. Note that their content is similar (LineRing)

Frank, do you think It is appropriate to add these two modifications in ParseGMLCoordinates? I am hesitant because they are gml3 functions but at the same time there is already a support for a gml3.1.x "pos" element and the modifications seem to be strait forward.

[warmerdam]

Assefa,

I think it is ok to add GML 3 reading as long as it doesn't break existing stuff. In fact, I'm adding some GML3 functionality currently for NAS format reading. You can either prepare a proposed patch and submit it to GDAL's Trac as a ticket, or just file a ticket with an example of the geometries you need to be able to process and I'll write the code.

[assefa]

I have added an enhancement ticket in gdal : ​http://trac.osgeo.org/gdal/ticket/2311

[assefa]

This should be close. Support was added.