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:br@brianrosen.net]
> > Sent: Wednesday, 1 July 2009 1:01 AM
> > To: Thomson, Martin; geopriv@ietf.org
> > 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > > Behalf Of Thomson, Martin
> > > Sent: Tuesday, June 30, 2009 2:37 AM
> > > To: geopriv@ietf.org
> > > 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
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
