Subject: [Geopriv] draft-linsner-geopriv-relativeloc-01.txt

From: "Marc Linsner" <[email-masked]>
Date: Tue, 3 Jul 2007 10:33:27 -0400

Updated version submitted

http://www.ietf.org/internet-drafts/draft-linsner-geopriv-relativeloc-01.txt

This is updated with comments received on the 00 version from Martin Thomson
and Carl Reed.

Changes are mostly tightening up the applicability/use case along with
technical corrections.

Comments are welcome.

-Marc-

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 3 Jul 2007 17:44:18 -0500

Hi Marc,

I think that the concept of relative location has merit though I would
prefer to see it as a separate "type" of location, rather than conflate
it into the existing civic structure.

My thoughts were that you would define a type call relativeLocation, for
example, which has a mandatory reference, which may be a civic address
or a GML point. You would define an orientation, and then have the X and
Ys relative to that.

I think that this is a cleaner solution and provides greater
flexibility.

I don't really want to see relative data added to the existing civic
schema, but I do like the concept you are trying to achieve.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 4 July 2007 12:33 AM
> To: 'GEOPRIV WG'
> Subject: [Geopriv] draft-linsner-geopriv-relativeloc-01.txt
> 

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

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 5 Jul 2007 14:07:40 -0400

James,

I believe we are talking about two different use cases.  This draft is
targeted to support an enterprise that has the capability via it's wireless
LAN infrastructure to offer additional location information, to be used in
conjunction with the provided civic location information.  As with cubicle
number, floor number, room number, etc., this draft enhances the civic
location information such that a finer grain location can be expressed.
Hence, the resultant location expressed via this draft is contained within
the boundary of the expressed civic location.

I do agree that on a larger scale, such as one that may be presented by a
service provider, where the offset of the location extends beyond one or
more civic locations from the reference point, a new location type might
best serve that use case.  This draft is not trying to solve this suggested
service provider case.

-Marc-

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 6:44 PM
> To: Marc Linsner; GEOPRIV WG
> Subject: RE: [Geopriv] draft-linsner-geopriv-relativeloc-01.txt
> 
> Hi Marc,
> 
> I think that the concept of relative location has merit 
> though I would prefer to see it as a separate "type" of 
> location, rather than conflate it into the existing civic structure.
> 
> My thoughts were that you would define a type call 
> relativeLocation, for example, which has a mandatory 
> reference, which may be a civic address or a GML point. You 
> would define an orientation, and then have the X and Ys 
> relative to that.
> 
> I don't really want to see relative data added to the 
> existing civic schema, but I do like the concept you are 
> trying to achieve.
> 
> Cheers
> James
> 
> 
> > This is updated with comments received on the 00 version 
> from Martin 
> > Thomson and Carl Reed.
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 5 Jul 2007 17:04:23 -0500

Hi Marc,

> conjunction with the provided civic location information.

[AJW] I think we are talking about the same use case. My point is that
this is a compound location problem that is trying to be squeezed into a
single representation for convenience, even though it doesn't really
fit.

The first location is a reference which the second location uses as an
offset. This is clearly a two location problem, similar to geodetic
point and floor.

I remain opposed to squashing this data into the civic schema. Your
example demonstrates that a clean relative location type will meet your
needs, and has applicability beyond the scope of what you are trying to
do. I think that a clean flexible solution should be the target of the
WG.

Cheers
James

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 6 Jul 2007 09:49:56 -0400

James, 

> 
> The first location is a reference which the second location 
> uses as an offset. This is clearly a two location problem, 
> similar to geodetic point and floor.

Do you understand that the resultant location is within the boundary of the
civic address location?

I'm curious why you consider this a 'two location problem'?  Using your
logic, do you consider '123 N. Main St., seat 456' a two location problem?

Btw, IMO, your example is not a 'two location problem', it's a single
location and a schema problem (FLR is missing from the geo schema).

> 
> I remain opposed to squashing this data into the civic 
> schema.

The proposed tags are not required.

 Your example demonstrates that a clean relative 
> location type will meet your needs, and has applicability 
> beyond the scope of what you are trying to do. I think that a 
> clean flexible solution should be the target of the WG.

The proposal maintains the hierarchy of the current civic location
mechanism, expression of less precise to most precise.  Attempting to
reorder the hierarchy in the enterprise case makes no sense as the reference
point is only of local significance.

Example enterprise hierarchy:

US
Pennsylvania
Pittsburgh
123 N. Main St.
3rd Floor
47 feet east and 24 feet south of the panda bear statue

I agree that in the possible different context the reference point would
move up the hierarchy, requiring a new location type might be best.  But, I
believe that is a discussion for a different document.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 6 Jul 2007 20:35:56 -0500

Isn't "the panda bear statue" the actual location your example provides
a relative offset from? In fact, isn't "47 feet east and 24 feet south
of the panda bear statue" a single datum and not, in fact, a relative
location at all - given we don't have a location object describing the
panda bear's location?

Just asking. It seemed to highlight that least->most accurate as a
concept doesn't really meld with "relative" location since the accuracy
of the reference location and the accuracy of the offset are two
independent quantities.

Isn't this example covered by the ability to add some additional
clarifying, but arbitrary, text in the PIDF-LO?

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, 6 July 2007 11:50 PM
To: Winterbottom, James; 'GEOPRIV WG'
Subject: RE: [Geopriv] draft-linsner-geopriv-relativeloc-01.txt

James, 

> similar to geodetic point and floor.

Do you understand that the resultant location is within the boundary of
the
civic address location?

I'm curious why you consider this a 'two location problem'?  Using your
logic, do you consider '123 N. Main St., seat 456' a two location
problem?

The proposal maintains the hierarchy of the current civic location
mechanism, expression of less precise to most precise.  Attempting to
reorder the hierarchy in the enterprise case makes no sense as the
reference
point is only of local significance.

US
Pennsylvania
Pittsburgh
123 N. Main St.
3rd Floor

I agree that in the possible different context the reference point would
move up the hierarchy, requiring a new location type might be best.
But, I
believe that is a discussion for a different document.

-Marc-