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

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Mar 2006 15:20:48 -0600

Hi Carl,

I think that we decided that a 16 point limit should not be enforced.  The reason that the 16 point limit was even mentioned was interoperability with 3GPP GAD (23.032), which only allows for 15 points and, as we know, Polygon requires that the first and last points are the same.

Any limit would now only be guidance...for a specific application.  The decision about whether 16 is a reasonable limit for specific applications has not been made - James was suggesting that it might be useful to limit this for routing applications (i.e. emergency).  The only problem with this is that any requirement on emergency is likely to become a de-facto limit for other applications.

With regards to the addition of a parameter that references a more complex shape; that is one thing that I think merits some more discussion.  That might be a way to ensure that detail is available when necessary without adding to the complexity or implementation burden imposed by the core specification.

Cheers,
Martin

> -----Original Message-----
> From: Carl Reed OGC Account [mailto:[email-masked]]
> Sent: Wednesday, 15 March 2006 4:39 AM
> To: Winterbottom, James; James M. Polk; Henning Schulzrinne;
> [email-masked]
> Subject: Re: [Geopriv] draft-thomson-geopriv-geo-shape-00
> 
> 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
> 
> 
> >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
> >
> 
> 
> _______________________________________________
> 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]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 20 Mar 2006 13:49:30 -0700

Thanks for the clarification.

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: "Carl Reed OGC Account" <[email-masked]>; "Winterbottom, 
James" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 14, 2006 2:20 PM
Subject: RE: [Geopriv] draft-thomson-geopriv-geo-shape-00

> Hi Carl,
>
> I think that we decided that a 16 point limit should not be enforced.  The 
> reason that the 16 point limit was even mentioned was interoperability 
> with 3GPP GAD (23.032), which only allows for 15 points and, as we know, 
> Polygon requires that the first and last points are the same.
>
> Any limit would now only be guidance...for a specific application.  The 
> decision about whether 16 is a reasonable limit for specific applications 
> has not been made - James was suggesting that it might be useful to limit 
> this for routing applications (i.e. emergency).  The only problem with 
> this is that any requirement on emergency is likely to become a de-facto 
> limit for other applications.
>
> With regards to the addition of a parameter that references a more complex 
> shape; that is one thing that I think merits some more discussion.  That 
> might be a way to ensure that detail is available when necessary without 
> adding to the complexity or implementation burden imposed by the core 
> specification.
>
> Cheers,
> Martin
>