Opened 17 years ago
Closed 15 years ago
#2111 closed task (fixed)
[Filter] upgrade to Filter 1.1.0
Reported by: | tomkralidis | Owned by: | assefa |
---|---|---|---|
Priority: | normal | Milestone: | 5.6 release |
Component: | SOS Server | Version: | svn-trunk (development) |
Severity: | normal | Keywords: | |
Cc: | sdlime, bartvde@…, dmorissette, warmerdam |
Description
(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.
Change History (6)
comment:1 by , 17 years ago
Cc: | removed |
---|---|
Milestone: | 5.0 release → 5.2 release |
Owner: | changed from | to
comment:2 by , 16 years ago
Version: | → svn-trunk (development) |
---|
see r7271 for changes to Filter Capabilities per 1.1.0
comment:3 by , 16 years ago
Cc: | added |
---|
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.
comment:4 by , 16 years ago
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.
comment:5 by , 16 years ago
I have added an enhancement ticket in gdal : http://trac.osgeo.org/gdal/ticket/2311
comment:6 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This should be close. Support was added.
This probably belongs to Assefa.
Pushing to 5.2 since it's clearly too late for 5.0.