Re: [Geopriv] loc-filters additional requirements

["Brian Rosen" <[e-mail]>]

How about:
<include type="xpath">/tuple/status/gp:geopriv/gp:location-info/gml:location </include>
and
<include type="xpath">/tuple/status/gp:geopriv/gp:location-info/cl:civicAddress</include>

That is neither brittle nor cumbersome.

Brian

> -----Original Message-----
> From: Thomson, Martin [mailto:[e-mail]]
> Sent: Tuesday, July 14, 2009 7:35 PM
> To: Brian Rosen; Hannes Tschofenig; [e-mail]
> Subject: RE: [Geopriv] loc-filters additional requirements
> 
> If I get you right, you want to be able to just use the information
> that is directly expressed in the PIDF to do everything.  Then you
> don't need a loc-filters document.  What you need is a much (much)
> smarter implementation of RFC 4661 - a specification that is already
> difficult to implement.
> 
> I know how to force inclusion of geodetic in the fashion you suggest,
> but it's cumbersome, indirect and brittle:
> 
>  <what>
>    <include type="xpath">
>      //gp:location-info/*[@srsName="urn:ogc:def:crs:EPSG::4326" or
> @srsName="urn:ogc:def:crs:EPSG::4979"]
>    </include>
>  </what>
> 
> How a PA is expected to see this and infer that it needs to perform
> geocoding, is probably beyond the ken of many.  The PA could just
> recognize the string and infer from that, but that's massively brittle.
> 
> I sat down and figured out how something like this might be implemented
> by a generic(-ish) PA.  You need to know that only GML geometries have
> an srsName attribute (which is actually not true: srsName cannot be
> namespace qualified, so this relies on an assumption).  Then the
> solution requires that the PA have further specialized knowledge.  Once
> you get to that sort of complexity, it's not that hard to just do
> something simple:
> 
>    <what><lf:locationType>geodetic</lf:locationType></what>
> 
> At some point, you need to know about the content in order to do the
> geocoding.  Why overcomplicate matters trying to avoid putting this
> knowledge in the filter?
> 
> Someone once submitted a centroid draft.  Derived properties in the
> PIDF could lead to some confusion.  Again, the same argument applies.
> 
> Quality filters need proper feedback to be properly useful [1].  Even
> with the proposed filters, this is necessary.  It's very easy to
> implement filters that don't actually achieve the intended goal.
> 
> --Martin
> 
> [1] http://tools.ietf.org/html/draft-thomson-simple-cont-presence-val-
> req
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[e-mail]]
> > Sent: Wednesday, 15 July 2009 7:14 AM
> > To: 'Hannes Tschofenig'; Thomson, Martin; [e-mail]
> > Subject: RE: [Geopriv] loc-filters additional requirements
> >
> > I'm particularly interested in keeping the same functionality for
> > filtering
> > for SIP and HELD, so I don't want to see HELD-specific solutions.
> >
> > I think you could easily force a civic by requiring country code
> field,
> > with
> > something similar for the geo.
> >
> > I suspect, but haven't thought out how to do something similar to
> force
> > a
> > particular shape
> >
> > I'd probably go along with adding quality filters, but I'd prefer we
> > first
> > make the quality parameters actual elements in a PIDF instead of
> > implicitly
> > using something like the circle radius.  We could then ask for a
> > specific
> > value or range of those elements of the PIDF.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Hannes Tschofenig
> > > Sent: Tuesday, July 14, 2009 4:32 PM
> > > To: 'Thomson, Martin'; [e-mail]
> > > Subject: Re: [Geopriv] loc-filters additional requirements
> > >
> > > Hi Martin,
> > >
> > > This functionality is not directly related to the original goal of
> > the
> > > filters document that tried to limit the amount of notifications
> that
> > > are
> > > being sent to the watcher.
> > >
> > > Anyway, functionality (1) is already in the HELD specification and
> > has
> > > also
> > > been re-used in the HTTP dereference document (that was actually
> the
> > > reason
> > > for having more functionality than just an HTTP lookup). Also
> > providing
> > > the
> > > functionality in this document would be very much inline with the
> > Deref
> > > document. This, I believe, is a good idea.
> > >
> > > Regarding functionality (2): This is neither in HELD nor in Deref.
> If
> > > you
> > > believe it is useful then we should add it to the Deref document as
> > > well. In
> > > general, we should think about how to keep this type of
> functionality
> > > (from
> > > a semantic point of view) roughly aligned and separated from the
> > actual
> > > transport.
> > >
> > > You mentioned the quality aspects: As a brief note I wanted to
> > mention
> > > that
> > > some basic functionality (in the form of the 'responseTime'
> > attribute)
> > > is
> > > already in the HELD base specification and is therefore inherited
> by
> > > the
> > > Deref document. As such, I believe it should be provided also in
> this
> > > document.
> > >
> > > Ciao
> > > Hannes
> > >
> > >
> > > >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
> > > >
> > >
> > > _______________________________________________
> > > 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]