RE: [Geopriv] issues and adoption of draft-thomson-geopriv-geo-shape

Cullen,

I'll be submitting another copy of this draft that should appear some time soon.  In the new version I've made a few minor tweaks:

 - the guidance on when approximations are useful is a little more detailed, including the fact that processing these shapes might require tolerances built into the algorithms;
 - I've also noted that these shapes can be used without these approximations to precisely define shapes, depending on context;
 - text on applicability has been tweaked; and
 - I've also addressed some nits.

More inline with some snips...

Cheers,
Martin

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Friday, 19 May 2006 2:10 AM
> To: Thomson, Martin
> Cc: Andrew Newton; geopriv@ietf.org
> Subject: Re: [Geopriv] issues and adoption of draft-thomson-geopriv-geo-
> shape
> 
> Thanks - this helps a bunch in understanding why the document is the
> way that it is. Few more questions inline ...
> 
> On May 10, 2006, at 1:23 AM, Thomson, Martin wrote:
> 
> > Hi Cullen,
> >
> > I'm glad that someone is reading and questioning!  This is the
> > first feedback of any detail that I have received.  So, no, the
> > topic has not been discussed to death ;)
> >
> > I think that I may not have been completely clear about what this
> > draft is trying to solve.  I intend this to be used for personal
> > location/presence - the location of a device, which in this case is
> > likely to be wireless.  Perhaps this was a bad assumption and I
> > need to be more explicit about this in the draft.  What do you think?
> 
> So the shapes that are defined in the draft would be used to specify
> the location of a device is likely to be within some specified shape
> where the shape represents the uncertainty of the device location and
> the device location was determined with some wireless technique? For
> this purpose, lots of the assumptions seem fine. Another usage of
> these shape might be to describe the exact shape of some geopolitical
> region and ask if a given point is inside or outside. This type of
> usage might end up with very large polygons where the assumptions
> might not work as well. Anything that could be done to help people
> understand where it was appropriate to use this and where it might
> not be appropriate. I think people have been thinking about 3G
> wireless locations but would it still make sense for much more
> accurate 802.11 type measurements, or could it work when using wire-
> maps connected to building for location, or perhaps just IP where the
> error polygon might be some irregular region spanning a continent.

This document is intended to provide shapes that are compatible with those used for 2-3G wireless.  I also intended it to cover a range of access technologies:

 - WiMAX is similar to 2-3G when it comes to location, comparable transmission range, etc...

 - the shapes work better as they get smaller, so it covers 802.11, Pringle cans and all.  The benefits of its use in 802.15 are questionable, but I see no reason why it wouldn't apply (location = my right pocket).

 - the shapes are also appropriate for describing a house, a small housing subdivision, a floor or floors of a building.  This suits wiremap type location methods, including DHCP.

I've also looked at cable, broadband over power, blimps with WiFi attached, ad hoc WiFi, you name it.  Defining a polygon that covers an entire country, for instance, requires quite a few points, not to mention complications from the curvature of the earth - I really think that would start to make the document a little too tricky to work with.

> In an side conversation with Rohan, he explained that this formed a
> framework then specific usage, like E911 information, might constrain
> things down much more - like specifying coordinate systems and such.
> I might be asking questions here that are actually answered in other
> documents.

Rohan knows what he is talking about on this ;)

We actually do have other documents for those sorts of constraints.  More on that later...

> >
> > Maybe I should also point out, right up front, that one of the joys
> > of uncertainty is that it is an inexact science.  It doesn't have
> > to be completely precise.  In many cases an approximation that is
> > within a 5% margin of error is not going to make that great a
> > difference.  I won't re-run the confidence discussion, but suffice
> > it to say that we are dealing with guesses here.  That might shed a
> > different light on the draft.
> 
> I actually really liked a bunch of your discussion of this in the
> draft. It's hard stuff to explain. Yep, I think providing things
> about what level of approximation we are assuming is needed would be
> good.

Thanks :)

> Could we get away with just mandating counter clockwise polygons?

I would like to leave the flexibility in how polygons are used and leave the only horizontal or only counter-clockwise recommendations to other documents.  That's a good one for PIDF-LO profile, but WGLC is about to finish...  sends another email... ok, just in time.

> I think that I missed the definition of short enough. Can you point
> right place. It seems like giving concrete advice on this would be
> good. Perhaps even just specifying a maximum diameter for polygons
> that were small enough for the approximation would be all that is
> needed.
> 

Maximum recommended distances are covered in "4.4. Lines and Distances".  Pointing out the problem that occurs when the location nears the poles is a good suggestion. I have worked out a reasonable point where this degrades and have added notes to that effect: 3%error @ 130km @ 70 degrees.  70 degrees is good because it covers most of the populated area of the globe with only a few places sticking out.

> > I appreciate your point about the spherical interpolation, but I
> > think forcing support of that sort of mathematics would be a
> > prohibitive barrier to implementation.  In reality, inverse
> > flattening makes spherical interpolation infeasible, particularly
> > near the poles.  Geodesic interpolation would be required, which is
> > widely documented as being somewhere between tricky and a right PITA.
> 
> I probably land in the thinking it is a right PITA end of the
> spectrum. Questions is, are we making it simpler or are we sweeping
> something under the rug that is just going to cause buggy
> implementations. Do we need to say something like, this can not be
> used above 70 degrees latitude? Would a constraint like this be
> acceptable? I really don't know the answers to any of these - and I
> am not implying what is here won't work.  It's just not clear to me
> that it will work, or under what constraints it will fail.

Above.  Thanks for pointing out the latitude thing, I had thought about it, but it required some more calculations to work out some reasonable numbers.

> Part of the difficulty here is this draft defines a way to specify
> shapes. The things I am talking about failing are computational
> geometry algorithm that operate on the shapes. Right now the draft
> does not indicate requirements for what algorithm we might want to
> compute on the defined shapes and the desired accuracy of theses
> computation so it makes it hard to decide if the shapes we are
> allowing make it to hard to implement the algorithms needed.
>
> > So, thanks for the feedback!  You get a gold star for being the
> > first to get into the meat of this.  Has my response helped?  Or
> > did this just pile more confusion on?
> 
> Response helped a bunch - I'm sorry that right now I don't have any
> specific suggestions on how to improve. Some thoughts are getting
> crisp on constraints on shapes (such as max diameter and not near
> poles), then perhaps describe (by reference) some algorithm that are
> simple to implement and would produce results with acceptable error.
> I don't know this may be an awful idea, I just throwing stuff out and
> seeing it any of it makes sense to the experts.
> 

From the perspective of algorithms, WGS84 has some nice ones for translating lat/long/alt into Cartesian systems, where you can do all that nice Cartesian geometry on them.  Most of the approximations just make that translation easier.  I.e. you can get a real polygon in Cartesian space, rather than a wonky twisted thing with non-parallel and curved faces.

Aside from that, the algorithms that you need are probably specific to the application.  I think that we are talking containment/overlap determination for LoST, others might just be doing conical or transverse Mercator projections for mapping.

I don't really want to dig too deeply into that area - it's outside what is needed for interoperation and frankly, you are likely to close off possibilities more than anything else.  All this fuzzy science leaves a lot of scope for innovation and unique ideas, which gets all very proprietary, particularly when it touches on location determination technology.  Of course, suggestions and pointers are welcome.

Cheers,
Martin

<snip old stuff>

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