Re: [Geopriv] loc-filters additional requirements

["Thomson, Martin" <[e-mail]>]

I'll note that 4661 isn't totally clear on these points, so there are some assumptions in how this fits together.

For geo/civic, <include/exclude> is a little clumsy in one direction and possibly impossible in the other.  Even assuming that we have only RFC 5491 shapes to contend with it's a bit fuzzy.

Requesting geodetic you can't specify ALL shapes because the PA must include these elements.  You only want one, but this would result in getting every shape:

	<include type="xpath">//gml:Point</include>
	<include type="xpath">//gml:Polygon</include>
	<include type="xpath">//gs:Circle</include>
	<include type="xpath">//gs:Ellipsoid</include>
	...
	<exclude type="xpath">//ca:CivicAddress</exclude>

Even using an include type of "namespace" wouldn't be advisable, there are two of those.  And without doing a lot more reading, I'm not certain that this wouldn't include the entire namespace, which for GML would be ridiculous.

The same argument applies to shape conversion.  In my experience, applications tend only support a limited number of shapes by choice.  Therefore, it's likely that they will indicate the set of shapes that they support and would prefer.  Again, using include would probably result in multiple values.

To that end, I propose two very simple filters:

   <locationType>geodetic/civic/any</locationType>

Which is clearly defined to mean that location information is requested in this form; if necessary the PA should convert the information it has into this form.

And:

  <geodeticShape>gml:Point</geodeticShape>

Which has similar meaning: provide 

I also considered combining the two - to some extent this makes sense if you consider these to have a sort of information hierarchy:

  Location - Civic
           - Geodetic - Point
                      - Polygon
                      - Circle
                      - ....

That does mess with the syntax a little though.

With respect to location quality, I have a concrete proposal in the draft I referenced (draft-thomson-geopriv-location-quality-04).

     <quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
       <maxUncertainty confidence="95">
         <horizontal>150</horizontal>
         <vertical>1000</vertical>
       </maxUncertainty>
       <maxAge>2008-05-27T05:47:55Z</maxAge>
     </quality>

To some extent I'm reluctant to request these additions.  There are things here that are more generally applicable to continuous-valued presence data (c.f. draft-thomson-simple-cont-presence-val-req).  My gut feel is that these sort of additions would greatly increase the complexity of what you are doing.  It might be better to leave these out for now and concentrate on the easy ones.

--Martin

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: Wednesday, 1 July 2009 1:01 AM
> To: Thomson, Martin; [e-mail]
> Subject: RE: [Geopriv] loc-filters additional requirements
> 
> Can you not use filter <include> and <exclude> from RFC4661 to
> accomplish
> the geo/civic and shape filters?
> 
> That was how I thought we would do it.
> 
> I don't have a problem with expanding to cover quality.
> 
> A specific proposal might be nice.
> 
> Brian
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Thomson, Martin
> > Sent: Tuesday, June 30, 2009 2:37 AM
> > To: [e-mail]
> > Subject: [Geopriv] loc-filters additional requirements
> >
> > I apologise for not getting these in earlier, but this came out of a
> > discussion that James Polk and I had over his filters draft.  We
> > concluded that the draft would become informational and would provide
> a
> > "cookbook" type of assistance to implementers rather than defining
> new
> > filters.
> >
> > To that end, there were a few fairly basic filters that could not be
> > accommodated by the current loc-filters document.  We decided to
> raise
> > these in the GEOPRIV WG:
> >
> >   1. location type:  A requirement to specify the desired location
> > type: geodetic or civic.  This would be a simple addition and would
> > either filter out the undesired type, or - if the PA supported it -
> > allow for the application of (reverse) geo-coding.
> >
> >   2. location shape: For geodetic locations, it might be desirable to
> > have the server perform shape conversion.  For instance, on a serving
> > node it's possible to make certain assumptions about shapes that
> result
> > in a smaller shape when converting.  This could be significantly
> better
> > than leaving a client to perform any conversions (perhaps based on
> > draft-thomson-geopriv-uncertainty) without that additional
> information.
> >
> > I also have some more general requirements on quality that I would
> like
> > to see included (see draft-thomson-geopriv-location-quality).  These
> > might require a somewhat different approach, as they regard the
> > continuous nature of location information.  I would have liked for
> > these to be considered, but am pragmatic enough to accept dealing
> with
> > these at a later date.
> >
> > In casting unsubstantiated dispersions about the maturity of this
> > document, these are the issues that I believe were not covered.
> ...and
> > need to be.  I hope that this is adequate substantiation.
> >
> > --Martin
> >
> > p.s. We probably also need to go to SIMPLE to discuss the addition of
> a
> > != operator in 4661.  There was a good use case for that included in
> > James' document, but my notes don't elaborate on it.
> >

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]