[Filter] upgrade to Filter 1.1.0

[tbonfort]

Reporter: tomkralidis Date: 2007/06/04 - 18:42

(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:PropertyNametitle/ogc:PropertyName ogc:SortOrderDESC/ogc:SortOrder /ogc:SortProperty /ogc:SortBy

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

...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.

[tbonfort]

Author: dmorissette Date: 2007/08/02 - 20:42 This probably belongs to Assefa.

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

[tbonfort]

Author: tomkralidis Date: 2008/01/17 - 20:49 see e692fc3e2f2a2554e6ee6d50b9a3bf07324b8ab2 (r7271) for changes to Filter Capabilities per 1.1.0

[tbonfort]

Author: assefa Date: 2008/04/03 - 01:44 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 ....>31 42 53 64 55 76 )
  • 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.

[tbonfort]

Author: warmerdam Date: 2008/04/03 - 04:53 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.

[tbonfort]

Author: assefa Date: 2008/04/03 - 16:49 I have added an enhancement ticket in gdal : http://trac.osgeo.org/gdal/ticket/2311

[tbonfort]

Author: assefa Date: 2009/10/11 - 01:16 This should be close. Support was added.