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
