Subject: [Geopriv] Consensus request: Relative location and encoding options

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Apr 2010 09:14:34 +0800

I promised to provide a picture of relative locations so that we could resolve the issue we have with the relative draft.

Here it is:
  <http://www.flickr.com/photos/49099289@N05/4501565914/sizes/o/>

There is little contention on the fundamentals.  The authors all agree on what data is included, even if there are some details that haven't yet been resolved.

The conflict that needs resolution regards the behaviour we want existing PIDF-LO implementations to follow:

  Option A:
    Ignore relative locations.

  Option B:
    Interpret the reference location part as the actual location (and ignore the relative part).

Brian will argue that the impact of B is harmless and sometimes desirable, since the offset is small anyway, and something is better than nothing.

I will argue that option B revises the semantics of existing RFCs, which intentionally and unnecessarily misleads existing implementations.

It's important to note that there are separate encodings for XML and compact (binary).  We can make a different decision for each encoding, if we believe that to be justified.  This is already true of other aspects of the current draft.

Feel free to suggest your own option if these don't fit, as Jon did at the meeting recently.

As stated, my personal position is that Option A must be used for the XML encoding.  Extensions do not have a criticality indicator (in the same way that X.509 extensions do) that would allow us to make breaking changes of this nature.

I also believe that Option A is correct for the binary encoding.  However, there is enough detail absent from the current proposal that it would be impossible to form a definitive opinion on the impact of this choice.

--Martin

---

From: althomso <[email-masked]>
Date: Wed, 07 Apr 2010 18:29:02 -0700

Taking a more concrete indoor location example. <excuse the pseudo method
for defining the loc>

USA -> Florida -> Miami -> Building A -> Floor 4 -> Elevator -> Polygon
Offset 

A device receiving this would still be able to use
USA->Florida->Miami->BuildingA->Floor4

If it doesn't understand the polygon/elevator part and the location is still
more usable/accurate than if none were provided at all.

So Option B would provide more useable information than Option A.

Another example, if a device doesn't understand or care about floors in the
USA->Florida->Miami->Building->Floor example does that mean it should
disregard the complete location also? Even though it only cared about the
location up to building granularity?

I would suggest Option B is better for most systems/applications.

allan

On 4/7/10 6:14 PM, "Thomson, Martin" <[email-masked]> wrote:

> I promised to provide a picture of relative locations so that we could resolve
> the issue we have with the relative draft.
> 
> Here it is:
> There is little contention on the fundamentals.  The authors all agree on what
> data is included, even if there are some details that haven't yet been
> resolved.
> 
> Brian will argue that the impact of B is harmless and sometimes desirable,
> since the offset is small anyway, and something is better than nothing.
> 
> I will argue that option B revises the semantics of existing RFCs, which
> intentionally and unnecessarily misleads existing implementations.
> 
> It's important to note that there are separate encodings for XML and compact
> (binary).  We can make a different decision for each encoding, if we believe
> that to be justified.  This is already true of other aspects of the current
> draft.
> 
> As stated, my personal position is that Option A must be used for the XML
> encoding.  Extensions do not have a criticality indicator (in the same way
> that X.509 extensions do) that would allow us to make breaking changes of this
> nature.
> 
> I also believe that Option A is correct for the binary encoding.  However,
> there is enough detail absent from the current proposal that it would be
> impossible to form a definitive opinion on the impact of this choice.
> 
> --Martin
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Apr 2010 10:09:15 +0800

The pseudo method misrepresents the problem, but that's what we were arguing over in the first place.  What you are actually saying is:

  Polygon, relative to: USA->Florida->Miami->BuildingA->Floor4->Elevator 

The problem is that "Elevator" is wrong.  If this field is understood, then the recipient uses the wrong location.  

An offset always invalidates some parts of the reference location.  The problem here is that the recipient is not given the information necessary to distinguish right parts from wrong parts.

It's trivially possible to provide:

  Civic: USA->Florida->Miami->BuildingA->Floor4
  Relative: Polygon => USA->Florida->Miami->BuildingA->Floor4->Elevator

And thereby provide useful information without relying on guesswork.

--Martin

> -----Original Message-----
> From: althomso [mailto:[email-masked]]
> Sent: Thursday, 8 April 2010 11:29 AM
> To: Thomson, Martin; [email-masked]
> Subject: Re: [Geopriv] Consensus request: Relative location and
> encoding options
> 
> > The conflict that needs resolution regards the behaviour we want
> existing
> > PIDF-LO implementations to follow:
> >
> >   Option A:
> >     Interpret the reference location part as the actual location (and
> ignore
> > the relative part).
> >
> > Feel free to suggest your own option if these don't fit, as Jon did
> at the
> > meeting recently.
> >
> >

---

From: althomso <[email-masked]>
Date: Wed, 07 Apr 2010 23:32:47 -0700

I guess we are just talking past each other.

On 4/7/10 7:09 PM, "Thomson, Martin" <[email-masked]> wrote:

> The pseudo method misrepresents the problem, but that's what we were arguing
> over in the first place.  What you are actually saying is:
> 

AT: How is that the wrong location? What you are suggesting is that they
wouldn't use any of the location upto including Elevator if they just don't
understand Polygon whereas I'm saying that if they at least understand
Elevator (and everything up to it) then that is better/more location than
they have if they discard the entire location.

> 
> An offset always invalidates some parts of the reference location.  The
> problem here is that the recipient is not given the information necessary to
> distinguish right parts from wrong parts.
> 

AT: In what sense is it trivially possible to provide? That a server
understands all capabilities and application needs that run on a device and
provide the exact location used by each application on that device? If that
is what you mean by trivial I would disagree. It is much simpler to provide
a full location object and let the application /device decide what parts it
can use or not. If the application or device wants to disregard the complete
location if it doesn't understand part of it then the application /device
can choose to do that. What you are suggesting is the protocol mandates that
behavior and that is where we disagree. It is up to the application and
systems using the protocol to decide how they want to treat elements they
don't want or understand.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Apr 2010 14:50:02 +0800

> I guess we are just talking past each other.

Seems like it.

> > The problem is that "Elevator" is wrong.  If this field is
> understood, then
> > the recipient uses the wrong location.
> 

At least civic addresses are constructed such that they degrade safely.

> > An offset always invalidates some parts of the reference location.
...
> >   Relative: Polygon => USA->Florida->Miami->BuildingA->Floor4-
> >Elevator
> 
> AT: In what sense is it trivially possible to provide? 

Create PIDF-LO, add civic tuple, add relative tuple.

> That a server
> provide the exact location used by each application on that device? 

That's not necessary - the server need only provide the best information that it has, of both types.

> If that
> can use or not. 

That's the complicated part.  If - as you suggest - you allow cherry-picking of data, then you have to be sure that any single element is correct on its own, AND in combination with all other elements.  That's what I call a combinatorial disaster.

> If the application or device wants to disregard the complete
> can choose to do that. 

I'm saying the opposite - that by misleading the application (by allowing them to believe that the reference location is the true location), you are robbing them of that choice.

> What you are suggesting is the protocol mandates
> that
> behavior and that is where we disagree. 

Again - the opposite. 

> It is up to the application and

That's exactly my reasoning behind choosing option A.

> > And thereby provide useful information without relying on guesswork.
...

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Apr 2010 14:57:58 +0800

Hi Allan,

I think the point is that going down to "elevator" is precision beyond the actual accuracy. The interpretation under option B becomes that the location is "at the elevator"; it could be at the far end of the fourth floor in this case.

Since the application doesn't have any knowledge to understand what the extent of the offset is with reference to any of the other components of the location it can only, as Martin says, guess. In a general framework, that's not actually a solution.

Given the location server does actually understand (yes, that's the assumption) the relative significance of the location and offset components, it's in the best position to offer both alternative forms. The relative form is, for example, the most precise location; the "standard" form is more semantically constrained such that it can only provide a less precise location. Nevertheless, it is straightforward to see how a server can do this automagically - whereas it's not possible to see how an arbitrary client can correctly disassemble the single relative form from an arbitrary source.

Cheers,
(the other) Martin

---

From: Brian Rosen <[email-masked]>
Date: Thu, 08 Apr 2010 07:16:17 -0400

>   Relative: Polygon => USA->Florida->Miami->BuildingA->Floor4->Elevator
Although I am not sure why "Elevator" is left off the Civic above, the point
is that the ONLY thing you could do is add the (superfluous) civic.  You
can't do anything else.   It's that or nothing.  The civic is more useful
than nothing.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Apr 2010 07:25:24 -0400

<hat type="individual-contributor"/>

Couple of  observations here:

1. In many use cases, the offsets we're talking about here are not  
enormous -- typically on the order of the size of a building.  So  
while degraded location might be inaccurate, it will often still be  
accurate enough to be useful (e.g., for getting packages).

2. In cases where the offset is expected to be large, interoperability  
concerns are mitigated by the fact that a lot of cases the sources and  
consumers of location will be under the control of the same entity.   
For example, if a cruise ship reports position relative to its GPS  
receiver, then uses these location values to direct its medical staff  
in emergencies, then when it purchases the medical software, it can  
check that it works with relative location so that the ship's doctors  
aren't running to the GPS antenna all the time.

3. In cases where the source and consumer are independent, the  
consumer has an incentive to do the right thing: to implement relative  
location if it's significant, since it will improve the function of  
his application, or to ignore it if it's irrelevant (i.e., if the  
application only needs location to a granularity coarser than the  
typical offset).

4. Clients can still *recognize* the extension without *processing*  
it, so they can provide a signal to users that "something may be weird  
with this location value" with low cost/complexity.

5. The claim that in Option A, clients will ignore the whole location  
assumes that clients will ignore GML based on CRS.  This may not be  
true in practice; I can easily imagine software that either assumes  
the CRS is WGS84 and doesn't read the the CRS at all, or that reads  
the CRS but halts processing of the location value as a whole if it's  
not a CRS it understands (i.e., WGS84).  So Option A could still cause  
clients to think that they are where aren't (usually, off the coast of  
Ghana) or that they have no location at all, even if there's another  
location value in the LO.

Net of all that, it doesn't seem to me like there's a huge difference  
between the two proposals.  My inclination is to go with Option B  
("Interpret the reference location part as the actual location (and  
ignore the relative part)"), but I'm not hard over.  Option A just  
seems a little pedantic in light of the use cases.

--Richard

On Apr 8, 2010, at 2:57 AM, Dawson, Martin wrote:

> Hi Allan,
>
> I think the point is that going down to "elevator" is precision  
> beyond the actual accuracy. The interpretation under option B  
> becomes that the location is "at the elevator"; it could be at the  
> far end of the fourth floor in this case.
>
> Since the application doesn't have any knowledge to understand what  
> the extent of the offset is with reference to any of the other  
> components of the location it can only, as Martin says, guess. In a  
> general framework, that's not actually a solution.
>
> Given the location server does actually understand (yes, that's the  
> assumption) the relative significance of the location and offset  
> components, it's in the best position to offer both alternative  
> forms. The relative form is, for example, the most precise location;  
> the "standard" form is more semantically constrained such that it  
> can only provide a less precise location. Nevertheless, it is  
> straightforward to see how a server can do this automagically -  
> whereas it's not possible to see how an arbitrary client can  
> correctly disassemble the single relative form from an arbitrary  
> source.
>
> Cheers,
> (the other) Martin
>
>>  Polygon, relative to: USA->Florida->Miami->BuildingA->Floor4- 
>> >Elevator
>>
>>
>> The
>>> If it doesn't understand the polygon/elevator part and the  
>>> location is
>>> still
>>> Another example, if a device doesn't understand or care about  
>>> floors in
>>> the
>>> disregard the complete location also? Even though it only cared  
>>> about
>>> the
>>>> It's important to note that there are separate encodings for XML  
>>>> and
>>> compact
>>>> (binary).  We can make a different decision for each encoding, if  
>>>> we
>>> believe
>>>> As stated, my personal position is that Option A must be used for  
>>>> the
>>> XML
>>>> there is enough detail absent from the current proposal that it  
>>>> would
>>> be

---

From: althomso <[email-masked]>
Date: Thu, 08 Apr 2010 06:31:26 -0700

> Create PIDF-LO, add civic tuple, add relative tuple.

AT: Providing a fully qualified location twice is extremely wasteful, and
inefficient. Not a good use of bandwidth over a network or where network
devices have limited memory/footprint. In a device that uses a binary
version of this information having the data twice would be a joke. The data
is already verbose enough.

Also, what happens when we add yet another TBD optional element to CIVIC
that not everyone understands? Now the server sends 3 copies?

> That's not necessary - the server need only provide the best information that

AT: And that is wasteful and inefficient for the reasons previously stated.

> That's the complicated part.  If - as you suggest - you allow cherry-picking
> of data, then you have to be sure that any single element is correct on its
> own, AND in combination with all other elements.  That's what I call a
> combinatorial disaster.
> 
> I'm saying the opposite - that by misleading the application (by allowing them
> to believe that the reference location is the true location), you are robbing
> them of that choice.

AT: If they understand relative loc then they wouldn't be robbed of
anything. If they don't understand relative loc they would at least know
what floor they are on. What you are suggesting is that they need to get 2
copies one with and one without for them to understand the one without.

>> behavior and that is where we disagree.

AT: We can cycle this argument all day. Should I?

> That's exactly my reasoning behind choosing option A.

AT: And my reason for choosing Option B.

---

From: Marc Linsner <[email-masked]>
Date: Thu, 08 Apr 2010 11:58:15 -0400

Option B for both XML and binary.

In the civic location case, the offset and relative location is a refinement
of the existing civic location type.  Not understanding the offset will
leave the recipient no worse off than they are without this extension.
Guidelines to implementers describing the usage of relative location may be
warranted.

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 08 Apr 2010 12:23:21 -0500

At 09:09 PM 4/7/2010, Thomson, Martin wrote:
>The pseudo method misrepresents the problem, but that's what we were 
>arguing over in the first place.  What you are actually saying is:
>
>understood, then the recipient uses the wrong location.
>
>An offset always invalidates some parts of the reference 
>location.  The problem here is that the recipient is not given the 
>information necessary to distinguish right parts from wrong parts.
>

I agree with Allan on several fronts, one that can't be overlooked.

The WG is aware that a lot of other SDOs (IEEE, TIA, etc) have for a 
long time used what Geopriv defines and use a binary version. In each 
of these binary versions - bits are precious, so adding many TLVs to 
a Ethernet frame (for example) is expensive. Adding a complete 
replica of a large chunk of information that already exists in the 
frame (i.e., the trivial example above) is viewed as kinda crazy.

Also, Allan, it has been said that if <elevator> is not understood, 
but everything else is (before it and after it) then the contained 
location would be wrong.  I have to agree this is a bogus argument 
because this would apply to every new element/field if not understood.

I think it should like this:

Civic: USA->Florida->Miami->BuildingA->Floor4
Relative: (ref=) Elevator->offset

where the reference <element> is identified, and everything in the 
relative part is separately indicated to ensure there is no confusion.

This both reduces the data to its minimum set, and for 
interoperability - only what's understood will be used, with the 
possibility that the recipient doesn't understand this extension, 
meaning they don't understand the whole "Relative" part, leaving that 
entity to believe the target is on <Floor>4</Floor>.  We just have to 
have firm text saying the target must be within x distance of floor 
4.  An easy example of somewhere outside floor 4 that still needs to 
be valid is a parking lot outside the building, or a window cleaner 
hanging outside the windows of floor 4.

James

---

From: Brian Rosen <[email-masked]>
Date: Thu, 08 Apr 2010 14:56:45 -0400

Just so we don't drive people crazy, can we drop the "Elevator" part of this
discussion in this thread?  We are confusing two issues: how do we code the
reference point base civic, and how, exactly, is the precise reference point
represented if it's a civic.

Just forget "Elevator" for this thread.  Concentrate on what you get if you
don't understand the extension: nothing or the base (civic or geo)
reference.

Raise "Elevator" on another thread.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Apr 2010 07:07:43 +0800

Brian writes:
> Although I am not sure why "Elevator" is left off the Civic above, the

I made an assumption that the target was not in the elevator, since that was what Allan also said.  If the target was in the elevator, then you just need the one location and relative is unnecessary.

> point
> is that the ONLY thing you could do is add the (superfluous) civic.

Not superfluous.  Merely accurate.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Apr 2010 07:19:55 +0800

It seems that your main argument for option B is efficiency.  Would you be satisfied with option A if I could demonstrate that it is capable of the same efficiency?  Because that's easy.

> is already verbose enough.

For XML, you don't really have a case.  For binary, I totally understand.  But that's not a terribly difficult problem to solve.  I have suggested in the past that a simple pointer resolves this.  Your relative location can simply say (or have implied) that the civic address is included as a reference location.

> that not everyone understands? Now the server sends 3 copies?

The problem with this argument is the assumption that relative location is civic address data.  It's simply not.

In any case, additions to civic addresses (-prefix, -lamppost, -int) can and are being added without this problem.  Why?  Because the added elements don't potentially invalidate other elements.

> anything. 

Of course, that's the ideal situation.  We can do anything for clients who understand relative locations.  That's not the problem.

> If they don't understand relative loc they would at least
> know
> what floor they are on.

Unless the offset contained a vertical component.

> What you are suggesting is that they need to
> get 2

Not at all.  I'm suggesting that they get location in two different forms.  Inefficiencies can be resolved trivially, potentially without even costing a single octet.

---

From: althomso <[email-masked]>
Date: Thu, 08 Apr 2010 16:49:27 -0700

Martin - <this is exhausting>

I could respond to each individual issue or point below but I see no point.

This proposal was submitted to specifically resolve a request from the IEEE
and Option B solves that request. This proposal should have moved on months
ago.

When we discussed this in the design team previously there was consensus on
Option B except for you.

I'm not sure why you or I are speaking up on this issue given that the
purpose of sharing with the larger group was to hear other opinions. We
already know ours.

allan

On 4/8/10 4:19 PM, "Thomson, Martin" <[email-masked]> wrote:

> It seems that your main argument for option B is efficiency.  Would you be
> satisfied with option A if I could demonstrate that it is capable of the same
> efficiency?  Because that's easy.
> 
> Allan writes:
> For XML, you don't really have a case.  For binary, I totally understand.  But
> that's not a terribly difficult problem to solve.  I have suggested in the
> past that a simple pointer resolves this.  Your relative location can simply
> say (or have implied) that the civic address is included as a reference
> location.
> 
> In any case, additions to civic addresses (-prefix, -lamppost, -int) can and
> are being added without this problem.  Why?  Because the added elements don't
> potentially invalidate other elements.
> 
> Of course, that's the ideal situation.  We can do anything for clients who
> understand relative locations.  That's not the problem.
> 
> Not at all.  I'm suggesting that they get location in two different forms.
> Inefficiencies can be resolved trivially, potentially without even costing a
> single octet.
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Apr 2010 08:16:22 +0800

Thanks James, that's pretty much what I've been proposing.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Apr 2010 08:30:21 +0800

In the interests of Allan's continuing wellbeing, I'll not continue to re-run the same points.

Instead, I offer new information.

A colleague just reminded me of a use case that was first raised ~3 years ago when I was working with the OMA [1] LOC group.  OMA LOC are currently defining detailed requirements for a new positioning protocol - LPPe - and amongst the work items is work on SET (Device) to SET positioning.

I'll continue to try to find the original presentation, but in lieu of that, the synopsis is pretty simple.

Using GNSS signals, it is possible to determine the relative position of two receivers with greater accuracy than the absolute position of either.  

As long as the receivers are close (on a planetary scale), atmospheric errors are similar.  This is what drives differential GPS, but it has wider application.

The most basic use case is relative navigation.  One user can be given precise directions to their target.  Think of the tracking devices you see in the movies: "your target is 732 meters away on a bearing of 73 degrees".

Option B doesn't support this application.  Option A does.

Given that the advantages of either are highly subjective, it seems better to base decisions on something tangible.

--Martin

p.s. For those with OMA portal access, this document might be interesting:

<http://member.openmobilealliance.org/ftp/Public_documents/LOC/2010/OMA-LOC-2010-0058-CR_LPPe1_0_RD_HighAccuracyRelativePositioning.zip>

For those without, I can provide the document.  It is public.

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 9 Apr 2010 08:43:49 +0800

Works for me. And it should work for Allan too.

Let's call it option C (for Compromise).

Richard - sorry - I can't buy into the "offsets are generally small" argument. That assumption is fraught in the context of defining a general framework. It's a bad thing to create convention that readily communicates precision in excess of accuracy.

Cheers,
Martin

---

From: Marc Linsner <[email-masked]>
Date: Fri, 09 Apr 2010 08:26:20 -0400

Martin,

Respectfully, PIDF-LO is a location object, not designed to carry
point-by-point navigation information.

-Marc-

On 4/8/10 8:30 PM, "Thomson, Martin" <[email-masked]> wrote:

> A colleague just reminded me of a use case that was first raised ~3 years ago
> when I was working with the OMA [1] LOC group.  OMA LOC are currently defining
> detailed requirements for a new positioning protocol - LPPe - and amongst the
> work items is work on SET (Device) to SET positioning.
> 
> Using GNSS signals, it is possible to determine the relative position of two
> receivers with greater accuracy than the absolute position of either.
> 
> As long as the receivers are close (on a planetary scale), atmospheric errors
> are similar.  This is what drives differential GPS, but it has wider
> application.
> 
> The most basic use case is relative navigation.  One user can be given precise
> directions to their target.  Think of the tracking devices you see in the
> movies: "your target is 732 meters away on a bearing of 73 degrees".
> 
> 
> <http://member.openmobilealliance.org/ftp/Public_documents/LOC/2010/OMA-LOC-20
> 10-0058-CR_LPPe1_0_RD_HighAccuracyRelativePositioning.zip>
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 09 Apr 2010 14:29:24 -0500

>Thanks James, that's pretty much what I've been proposing.

I know we aren't too far apart but what I am proosing is not what you 
have been proposing - as I don't agree with your proposal to include both

and

         USA -> Florida -> Miami -> Building A -> Floor 4 ->
         Elevator -> Polygon Offset

in the same message. I am personally in favor of just having any one 
<element> in the PIDF-LO once, such as this:

> > Relative: (ref-point=) <some point on 4th floor>->offset from that point

but I know Brian is the one who adamantly opposes the idea of 
indicating which is the reference point/element - and I think that is 
flawed.  I believe my offering above is the one that interoperates 
perfectly with existing implementations, given that any LR that 
doesn't understand this particular extension can't confuse any of its 
ref-point= or offset elements (in XML or in binary).

We also can't expect that an LR that does understand this extension 
to somehow not understand the <ref-point=> element, so that argument 
goes out the window in this proposal.

The key to the above proposal is to uniquely identify each "Relative" 
<element>. You can call this another location type, you can call this 
variations of the <INT> element type. I don't care as a practical 
matter, just so long as they are uniquely identified so any LR that 
doesn't understand this extension CAN'T misinterpret the information 
(which is a fear you've stated over and over again).

There also needs to be MUST NOT level text about not allowing the 
offset to be very far away from the perimeter of the property that is 
understood within RFCs 4119 and 5139. If we agree on that idea, we 
can then work on the distance that should be allowed, and what is too 
far - as guidance.   An example of this in urban areas is nothing 
outside the parking lot perimeter surrounding the building in the 
PIDF-LO. I'm not sure what is viable in rural areas, but perhaps the 
property line in the PIDF-LO is good there too.

James

---

From: Richard Barnes <[email-masked]>
Date: Fri, 9 Apr 2010 18:27:52 -0400

Would another way to phrase this "Option C" be the following:
-- "Normal part": location with low enough precision to include the  
intended location
-- "Relative part": further granularity for the reference point, plus  
the offset
That way, entities that don't understand get a less precise, but still  
correct location.

So for example, if we wanted to refer to an ellipse offset from an  
<LMK> in a building...

In Civic:
-- Normal: country, A1, A3, PC, HNO, RD, STS, FLOOR
-- Relative: LMK, offset shape

In Geodetic:
-- Normal: outline of the building
-- Relative: point inside building, offset shape

It's still a little wasteful in the geodetic case, but it's not that  
bad.

--Richard

On Apr 9, 2010, at 3:29 PM, James M. Polk wrote:

> I know we aren't too far apart but what I am proosing is not what  
> you have been proposing - as I don't agree with your proposal to  
> include both
>
> indicating which is the reference point/element - and I think that  
> is flawed.  I believe my offering above is the one that  
> interoperates perfectly with existing implementations, given that  
> any LR that doesn't understand this particular extension can't  
> confuse any of its ref-point= or offset elements (in XML or in  
> binary).
>
> The key to the above proposal is to uniquely identify each  
> "Relative" <element>. You can call this another location type, you  
> can call this variations of the <INT> element type. I don't care as  
> a practical matter, just so long as they are uniquely identified so  
> any LR that doesn't understand this extension CAN'T misinterpret the  
> information (which is a fear you've stated over and over again).
>
> offset to be very far away from the perimeter of the property that  
> is understood within RFCs 4119 and 5139. If we agree on that idea,  
> we can then work on the distance that should be allowed, and what is  
> too far - as guidance.   An example of this in urban areas is  
> nothing outside the parking lot perimeter surrounding the building  
> in the PIDF-LO. I'm not sure what is viable in rural areas, but  
> perhaps the property line in the PIDF-LO is good there too.
>
> James
>
>>

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 11 Apr 2010 11:45:07 -0500

>Would another way to phrase this "Option C" be the following:

err... didn't I mention this specific layout in the previous message 
within this thread (though not yet calling it "Option C")?

I'll grant you naming rights if we can agree to this...  ;-)

>-- Normal: outline of the building

we should discuss this - as I think this (point "outline of the 
building") is problematic. What if you are at Yankees stadium or 
Soldier's Field.  Where is the point "outline of the building"? that 
still means Yankees stadium or Soldier's Field?  I think for Geo, we 
have to agree if the geo points to a property, and then there can be either:

- a reference point within that property aside from the macro geo 
coodinates, or
- us the exact geo as the reference point to then do an offset from.

I know James and Martin will balk at this latter choice, saying why 
not just recalculate the external geo -- but I think that isn't so 
obvious, but it may be.

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Apr 2010 08:20:50 +0800

James Polk writes:
> still means Yankees stadium or Soldier's Field?  

That depends.  It might be reasonable to use a shape that encloses either the stadium or the enclosing grounds.

> I think for Geo, we

Not so much as you might think.  While I always favour the inclusion of more information, and Richard's presentation is what I would consider ideal, this usage isn't that offensive.  

A recipient that receives the information is not presented with more precision than there is accuracy, since there is no claim made with respect to accuracy.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Apr 2010 08:22:58 +0800

With equal respect - why do we provide relative location if not to convey information in a local context.  The aim being to provide information that is more useful to a recipient than absolute information would otherwise be.

--Martin

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, 9 April 2010 10:26 PM
> > In the interests of Allan's continuing wellbeing, I'll not continue
> to re-run
> > the same points.
> >
> > I'll continue to try to find the original presentation, but in lieu
> of that,
> > the synopsis is pretty simple.
> >
> >
> > Given that the advantages of either are highly subjective, it seems
> better to
> > base decisions on something tangible.
> >
> > --Martin
> >
> >

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 16 Apr 2010 10:10:22 -0400

There are still some details to be worked out, but I think we are very  
near to consensus on "Option C." I'd like to suggest that Brian in his  
editorial role try to work this approach into the current draft and  
share it back with the design team and then the list.

Alissa

On Apr 11, 2010, at 8:20 PM, Thomson, Martin wrote:

> That depends.  It might be reasonable to use a shape that encloses  
> either the stadium or the enclosing grounds.
>
>> I think for Geo, we
> Not so much as you might think.  While I always favour the inclusion  
> of more information, and Richard's presentation is what I would  
> consider ideal, this usage isn't that offensive.
>
> A recipient that receives the information is not presented with more  
> precision than there is accuracy, since there is no claim made with  
> respect to accuracy.
>
> --Martin
>
>> James
>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 16 Apr 2010 12:44:23 -0400

So, just making sure I understand what I'm doing to the text:
A) I'm leaving the basic location alone, but probably changing the name of
it, because it's not the reference location
B) I'm adding an element to the offset, or adding some new element at the
same level as the offset, that can have some fields that are in a PIDF
civic, specifically, CAtypes, or a new geo location that is as general as
the original (point or shape, WGS84 CRS, ...)
C) This refinement of the reference point for a civic is constrained to be
more specific -- that is the CAtypes have to be more specific then the last
one in the initial location
D) With a geo, the only way to make any use of this is to specify a location
with a large uncertainty in the original location, and then specify the same
location with a smaller uncertainty in the extension.  We would probably
want to constrain the implementation to that.   This means that it's Option
A for geo.  
E) I imagine there is no reason to require the second location -- that is,
if you just have the original location, and an offset, it's fine.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Apr 2010 15:15:53 -0400

That sounds about right to me.  Suggested guidance text to accompany:
"
This extension effectively allows the creator of a location object to  
include two location values plus an offset.  The "baseline" location  
that is given outside of the <relative> element is what will be  
visible to a client that does not understand that extension (i.e., one  
that ignores the <relative> element).  A client that does understand  
this extension will interpret the location within the relative element  
as a refinement of the baseline location, which gives the reference  
location for the relative offset.

Creators of location objects with relative location thus have a choice  
of how much information to put into the "baseline" location and how  
much to put into the "reference" location.  For example, all location  
information could be put inside the <relative> element, so that  
clients that do not understand relative location would receive no  
location information at all.  Alternatively, the baseline location  
value could be precise enough to specify a building that contains the  
relative location, and the reference location could specify a point  
within the building from which the offset is measured.

In any case, it is RECOMMENDED that the baseline location be general  
enough to describe both the reference location and the relative  
location (reference plus offset).  In particular, while it is possible  
to put all location information into the "reference" location (leaving  
an universally broad "baseline"), location objects SHOULD NOT have all  
location information in the "baseline" location. Doing this would  
cause clients that do not understand relative location to incorrectly  
interpret the baseline location (i.e., the reference point) as the  
actual, precise location of the client.
"

On Apr 16, 2010, at 12:44 PM, Brian Rosen wrote:

>>>> have to agree if the geo points to a property, and then there can  
>>>> be
>>>> either:
>>>>