Re: [Geopriv] GEOPRIV Event Package Drafts (draft-ietf-geopriv-loc-filters, draft-polk-sip-location-get, and draft-winterbottom-sip-location-package)

On 7/24/08 8:31 AM, Brian Rosen wrote:
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, July 24, 2008 9:17 AM
> To: 'Hannes Tschofenig'; 'Adam Roach'
> Cc: 'GEOPRIV Working Group'; 'Rohan Mahy'; 'James Winterbottom'; 'James
> Polk'
> Subject: RE: [Geopriv] GEOPRIV Event Package Drafts (draft-ietf-geopriv-
> loc-filters, draft-polk-sip-location-get, and draft-winterbottom-sip-
> location-package)
>
> I appreciate the review Adam did on the documents.
>
> I will try to take a lot of his advice to re-use existing work, but I'm
> not entirely convinced that it actually is better to warp an existing doc
> to fit a new use if the warp looks ugly. Let me cite an example:
> Motion filtering is a really basic notion for location. However, although
> the location reporting is done lat/lon, a motion filter is nearly always
> expressed in linear meters (or other directly convertible units like
> feet). Using the 4660/4661 paradigm, we would pretty much be constrained
> to use degrees as the units. Conversions are, of course, possible, but
> pretty expensive using some model of the earth shape. If you want
> accuracy (and admittedly, you often don't need much accuracy), the model
> can be somewhat complex.

As I understand things, the conversion from °/'/" to meters has to take
place somewhere in the system. You're arguing for a model in which the
LIS applies a one-size-fits-all conversion. Using 4660/4661 most
naturally lends itself to a a requestor-supplied conversion.

As you point out, in most cases the accuracy is not that critical for a
filter -- triggering on a move that is 1 meter versus 1.0073 meters will
result in similar enough user experience as to make no difference. On
the other hand, the entity that best knows what level of accuracy is
required will be the requestor. So, if he knows that the trigger is very
approximate, he can approximate the earth as a smooth sphere and get
perfectly adequate results. If higher precision is needed for some
reason, he can apply an appropriately complex conversion model.

On the other hand, if the LIS is performing the conversion, it must
convert using a the most complex model required by any client.

> Some further comments are in-line.
>

Responses to one block of comments below.

>>> This is currently proposed to use something like:
>>>
>>> <location-filter>
>>> <movedVert uom="urn:ogc:def:uom:EPSG::9001">3</movedVert>
>>> </location-filter>
>>>
>>> However, use of RFC4660/4661 would appear to be sufficient for this
>>> purpose. Keep in mind that RFC4660/4661 is *intended* to be extended
>>> by specific event packages to accommodate the specific data associated
>>> with those event packages.
>>>
>>> I'm going to throw out a strawman based on 4660/4661:
>>>
>>> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
>>> <ns-bindings>
>>> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
>>> </ns-bindings>
>>> <filter id="123" uri="sip:presentity@example.com">
>>> <trigger>
>>> <changed component="latlong" by="20">
>>> /gp:geopriv/gp:location-info/gml:location/gml:coordinates
>>> </changed>
>>> </trigger>
>>> <trigger>
>>> <changed component="altitude" by="3">
>>> /gp:geopriv/gp:location-info/gml:location/gml:coordinates
>>> </changed>
>>> </trigger>
>>> </filter>
>>> </filter-set>
>>>
...
> Also note the explosion in the size of the filter, and the difference in
> clarity of purpose.

Yes. Point solutions will pretty much always be more concise than general tools that can be used to build solutions. On the other hand, they're usually not as flexible, and hamper future innovation.

I would point you to <http://tools.ietf.org/html/draft-ohta-notasip-04> and its companion <http://tools.ietf.org/html/draft-fujikawa-iphone-url-01> as an example.

> It may be possible to come up with some extension to
> 4660/1 that makes this more reasonable. I'll think about that.

That would be a good approach. Another point I meant to make in my previous email is that I'm concerned that GEOPRIV will come up with all these nice means of talking about PIDF-LO that are completely immiscible with the ways that we can talk about PIDF. I would like to be able to subscribe to a presence server that includes all kinds of user presence -- including location -- and apply the filters that GEOPRIV is defining as well as the normal PIDF filters defined in 4661. If you use something outside the 4660/4661 framework, I'm left having to reinvent all that work.

/a

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Thu, 24 Jul 2008 14:50:01 -0500