Re: [Geopriv] loc-filters additional requirements

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

That's certainly a worthwhile goal.  It's somewhat equivalent in geodetic terms to requesting a certain uncertainty.

You're right, I was being economical - all that falls into the location quality bucket and is subject to my reservations on the topic.

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]]
> Sent: Thursday, 2 July 2009 3:38 PM
> To: Thomson, Martin; Brian Rosen; [e-mail]
> Subject: Re: [Geopriv] loc-filters additional requirements
> 
> Martin
> 
> Given you points, which at the moment I have no issues with - I'd
> like to still be able to specify that Alice wants Bob's civic
> location to the office or cube or building, and not just the city -
> which might be the default value Bob may choose to return.
> 
> If this takes two steps (#1 as Bob and see what he gives you, then
> ask again when his response wasn't to Alice's preferable level of
> detail) - this seems inefficient, but doable.
> 
> What I'm not see below, though you may have left it out because that
> will make the message longer, is this 'asking for specific elements
> of civic' level of detail.
> 
> Perhaps Alice wants to know Bob's
> 
> - altitude or
> - cube he's in or
> - the building name he's in or
> - the street or
> - county
> 
> all of which he wouldn't *or*didn't* return in his response as his
> default.
> 
> I keep going back to the only piece of location-info that's mandatory
> to be in a PIDF-LO is the ISO country code; everything else is
> assumed, and should be able to be asked for.
> 
> I don't read 4660/4661/4662 or Brian's filters ID to have this level
> of requestability (hey - new word), but I believe this has usefulness.
> 
> James
> 
> At 07:22 PM 6/30/2009, Thomson, Martin wrote:
> >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]
> >_______________________________________________
> >Geopriv mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/geopriv
> 

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