Subject: RE: [Geopriv] draft-thomson-geopriv-geo-shape-00

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 5 Mar 2006 02:01:28 -0600

I would actually suggest in that case that we use the 16 point bound as
a limitation for Location routing applications also. I think that trying
to perform arbitrary spatial lookups based on a polygon containing many
100s of points is hardly going to be something that we want to try an do
in real or near real time. I might also question the need for someone to
need to express their personal presence in such a way, but that is a
different discussion completely.

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Sunday, 5 March 2006 4:54 PM
> To: Winterbottom, James; Henning Schulzrinne; [email-masked]
> Subject: RE: [Geopriv] draft-thomson-geopriv-geo-shape-00
> 
> IMO only
> 
> We cannot bound this, but we can recommend limits that achieve
diminishing
> returns.  I have no knowledge of what this curve would look like, but
I
> just don't believe that limit is at 16 points by any stretch of the
> imagination.  I would think it would be in the thousands.  If
Manhattan
> had
> 670 points, what does Canada have, given the shape of the Northern
> Territories?  Or Russia?
> 
> One recommendation could be specifically to meeting the 3GPP
limitation
> they chose, but it should be just that: 'to do as 3GPP did (i.e. be
> interoperable with), a max of 16 points are allowed, and no more'.  I
> assume they were thinking of bw necessary to transmit when limiting
the
> number to that few.
> 
> I do not believe there should be any unilateral limitation for all
> implementations.
> 
> At 11:26 PM 3/4/2006 -0600, Winterbottom, James wrote:
> >Is the suggestion to make this unbounded in Geo-Shape, but make a
> >recommendation in PIDF-LO profile?
> >
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[email-masked]]
> > > Sent: Sunday, 5 March 2006 3:11 PM
> > > To: Henning Schulzrinne; [email-masked]
> > > Subject: Re: [Geopriv] draft-thomson-geopriv-geo-shape-00
> > >
> > > At 09:48 PM 3/4/2006 -0500, Henning Schulzrinne wrote:
> > >
> > > >In the draft, it states
> > > >
> > > >>"For interoperability with [3GPP.TS23032], the number of points
has
> > > >>been limited to 16".
> > > >
> > > >It seems unnecessary to make this a general restriction. PIDF
will be
> > > >used in many contexts where this is not necessary or appropriate.
Why
> > > >shouldn't I be able to describe "I'm in Foo County", and provide
the
> > > >boundary of that county?
> > >
> > > I'd also be curious how one would chose which 16 coordinate pairs
> > > represent
> > > the US or Canada or England/UK or Japan without getting seriously
out
> >into
> > > international waters or into another country's territory (think
about
> >how
> > > to get around the Great Lakes between the US and Canada).
> > >
> > > I believe someone (our chair Andy?) already showed Manhattan in
pairs
> >and
> > > had to use something like 670.  PIDF-LO can include more, and we
> >shouldn't
> > > be restricted in operation at this design level.  If an
implementation
> > > wants to maintain interoperability with 3GPP, they can choose to
only
> >use
> > > 16 points, and have limited precision in their results, but that's
an
> > > implementation's choice.
> > >
> > > You could say something like this:
> > >
> > >          "In order to maintain seamless interoperability with 3GPP
> > > implementations, per [3GPP.TS23032], there needs to be a maximum
of 16
> > > points used."
> > >
> > > But this cannot be normative; but just stated as guidance.
> > >
> > >
> > > >Henning
> > > >
> > > >_______________________________________________
> > > >Geopriv mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/geopriv
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > [email-masked]
> > > https://www1.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]

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 5 Mar 2006 09:56:46 -0500

There is a big difference between giving implementation advice and  
artificially restricting functionality. As noted, PIDF-LO has broad  
applicability, with many applications that we can't predict, most of  
which won't involve emergency calls or 3G.

There is a somewhat separate aspect: The description in these drafts  
is also taken as advice on how to use GML within other IETF  
documents. (My remark was actually triggered by the attempt of a grad  
student of mine to integrate the polygon description into the LUMP/ 
LoST test implementation of ours, to describe regions.) There, the 16- 
point limit makes absolutely no sense.

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 14 Mar 2006 10:38:46 -0700

Am catching up on emails. 16 points is not very many. However, if folks wish 
to go with a 16 point limit, is there any possibility of having a reference 
by URI to another resource that has a more detailed polygon (including 
islands/holes)? Arbitrary spatial lookups using complex polygons is actually 
incredibly fast if the correct algorithms are used. I can think of a variety 
of use cases in which a user could want more complex lines and polygons that 
require more than 16 coordinate pairs.

Cheers

Carl

----- Original Message ----- 
From: "Winterbottom, James" <[email-masked]>
To: "James M. Polk" <[email-masked]>; "Henning Schulzrinne" 
<[email-masked]>; <[email-masked]>
Sent: Sunday, March 05, 2006 1:01 AM
Subject: RE: [Geopriv] draft-thomson-geopriv-geo-shape-00