Subject: [Geopriv] Quick review of draft-linsner-geopriv-relativeloc-02

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 9 Nov 2008 18:00:14 -0600

Hi Marc, Allan,

As with other drafts, I think that this work is useful.  It may be a little early, but that's not a failure of the draft.  My major concerns arise from execution.  As documented, this draft doesn't have quite enough detail to ensure that it doesn't cause problems.  

The most important part of this draft is the selection of the reference point.  Selecting a unique point using something as imprecise as a civic address format is difficult.

I find that it is helpful to think of the civic address as defining a series of (sometimes non-orthogonal) spatial partitions.  The first is the implicit partition that identifies the habited portion of the earth.  The second is the country.  Right down to road (which includes all properties that adjoin the street), and on to seat.  Each label might need to be interpreted with other values to provide context.  As a value at each level is interpreted, one or more partitions at that level are selected, and all other partitions of that type are excluded.  For non-orthogonal partitions, only the portion of the partition that fits within the existing space is selected (this is what ensures that George St in Sydney is selected, rather than the George St in Newcastle).  In effect, each defined element selects a partition of space and the resultant location is the intersection of all selected spaces.

This view helps with correlating the civic address with a geodetic position, including uncertainty (the selected space is the region of uncertainty).  At no stage does this select a point, though as spaces get smaller, approximation to a point is useful.

Based on this background, I'll outline my concerns:  

The reference point AND resultant relative location must be contained within the space selected by the rest of the civic address.  I'll expand on the reference point piece later.  For the result, this ensures that if the relative elements are not understood, the rest of the civic address isn't misinterpreted.  This is important for backward compatibility.

(The above also applies for if you allow this to be used in a complex with geodetic positions, but you would have to define this as relative to the centroid and restrict it to the geodetic positions that have uncertainty.)

The resultant relative location is only as good as the specification of the reference point.  If you specify a door as the reference, the resulting point has uncertainty of at least the size of a door.  Your corner office example still describes a location the size of an office.  An observation to this effect in the draft might be helpful.

There is another aspect to the definition of the reference point.  The reference location has local significance, but it's extremely important that the entire civic address be unambiguously understood.  Using generic reference labels (as suggested) can result in different interpretations if one or more of the civic address labels is not understood.  This means that you need to define which set of fields must be understood: all provided, or all 5139/4776 labels (the difference is significant; I favour the former).

Minor points:

Discussing earth curvature isn't really helpful.  If you want to talk about getting a very accurate geodetic position, my suggestion is that you be even more specific.  Convert to ECEF, and use the resultant x,y,z to get a unit vector for "up".  Then derive the northing vector by calculating the azimuth to a point directly north and adjusting for curvature.  The cross product of northing and the up vector will get an easting vector.

The above is all probably moot since I suspect that people will be using this on floor plans.  Plot the reference point on the plan, provide a north vector (based on survey or a compass) and that's probably enough.

Don't use X, Y and Z.  Use EW, NS and UD (or the longer EastWest, NorthSouth and UpDown).  This is easier to remember and you don't have problems with people putting north/south first and stuffing it up.

Don't extend the schema in the same namespace.  This doesn't work particularly well with the approach adopted by the IETF for XML design.  Define a new namespace and schema.  It doesn't even have to be flat like 5139 - that flat schema works well enough when you don't have any better structure, but you can potentially use a more GML-like position:
  <relative><to>Elevator-1</to><pos>-20 -31<pos></relative>

You don't want to use ca:caType for EW, NS and UD since those elements are numerical and don't require xml:lang.

Don't allow for feet.  If people want to use antiquated units of measure, they can use the standard formulae for conversion.  It's one fewer element to define.

Section 9.2 is empty.

Cheers,
Martin
------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Nov 2008 16:33:48 -0500

I rather like this email, and particularly like the "partition of the space"
concept, which I think is a powerful way to explain relationships.  I may
use it in some NENA work, where we are discussing the differences between
street centerlines with address points and road geometry with parcels (and
partitions of parcels).

Anyway.  I think you have a practical problem with saying that the reference
point and the relative location have to be within the same space selected by
the civic address.  The problem I see is that a common use case is
"triangulations" from a set of APs.  There is no guarantee that the set of
APs is in the same civic address. They may very well be in several adjacent
addresses.  By your reasoning, we would have to go up a level (street for
example) and say, well, it's somewhere on this street, with reference and
relative location.  Even that wouldn't work if the set of APs included parts
of two adjacent streets (back to back buildings for example).

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomson, Martin
Sent: Sunday, November 09, 2008 7:00 PM
To: GEOPRIV; [email-masked]; [email-masked]
Subject: [Geopriv] Quick review of draft-linsner-geopriv-relativeloc-02

Hi Marc, Allan,

As with other drafts, I think that this work is useful.  It may be a little
early, but that's not a failure of the draft.  My major concerns arise from
execution.  As documented, this draft doesn't have quite enough detail to
ensure that it doesn't cause problems.  

The most important part of this draft is the selection of the reference
point.  Selecting a unique point using something as imprecise as a civic
address format is difficult.

I find that it is helpful to think of the civic address as defining a series
of (sometimes non-orthogonal) spatial partitions.  The first is the implicit
partition that identifies the habited portion of the earth.  The second is
the country.  Right down to road (which includes all properties that adjoin
the street), and on to seat.  Each label might need to be interpreted with
other values to provide context.  As a value at each level is interpreted,
one or more partitions at that level are selected, and all other partitions
of that type are excluded.  For non-orthogonal partitions, only the portion
of the partition that fits within the existing space is selected (this is
what ensures that George St in Sydney is selected, rather than the George St
in Newcastle).  In effect, each defined element selects a partition of space
and the resultant location is the intersection of all selected spaces.

This view helps with correlating the civic address with a geodetic position,
including uncertainty (the selected space is the region of uncertainty).  At
no stage does this select a point, though as spaces get smaller,
approximation to a point is useful.

The reference point AND resultant relative location must be contained within
the space selected by the rest of the civic address.  I'll expand on the
reference point piece later.  For the result, this ensures that if the
relative elements are not understood, the rest of the civic address isn't
misinterpreted.  This is important for backward compatibility.

(The above also applies for if you allow this to be used in a complex with
geodetic positions, but you would have to define this as relative to the
centroid and restrict it to the geodetic positions that have uncertainty.)

The resultant relative location is only as good as the specification of the
reference point.  If you specify a door as the reference, the resulting
point has uncertainty of at least the size of a door.  Your corner office
example still describes a location the size of an office.  An observation to
this effect in the draft might be helpful.

There is another aspect to the definition of the reference point.  The
reference location has local significance, but it's extremely important that
the entire civic address be unambiguously understood.  Using generic
reference labels (as suggested) can result in different interpretations if
one or more of the civic address labels is not understood.  This means that
you need to define which set of fields must be understood: all provided, or
all 5139/4776 labels (the difference is significant; I favour the former).

Minor points:

Discussing earth curvature isn't really helpful.  If you want to talk about
getting a very accurate geodetic position, my suggestion is that you be even
more specific.  Convert to ECEF, and use the resultant x,y,z to get a unit
vector for "up".  Then derive the northing vector by calculating the azimuth
to a point directly north and adjusting for curvature.  The cross product of
northing and the up vector will get an easting vector.

The above is all probably moot since I suspect that people will be using
this on floor plans.  Plot the reference point on the plan, provide a north
vector (based on survey or a compass) and that's probably enough.

Don't use X, Y and Z.  Use EW, NS and UD (or the longer EastWest, NorthSouth
and UpDown).  This is easier to remember and you don't have problems with
people putting north/south first and stuffing it up.

Don't extend the schema in the same namespace.  This doesn't work
particularly well with the approach adopted by the IETF for XML design.
Define a new namespace and schema.  It doesn't even have to be flat like
5139 - that flat schema works well enough when you don't have any better
structure, but you can potentially use a more GML-like position:
  <relative><to>Elevator-1</to><pos>-20 -31<pos></relative>

You don't want to use ca:caType for EW, NS and UD since those elements are
numerical and don't require xml:lang.

Don't allow for feet.  If people want to use antiquated units of measure,
they can use the standard formulae for conversion.  It's one fewer element
to define.

Section 9.2 is empty.

Cheers,
Martin
----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 11 Nov 2008 20:59:21 -0600

Hi Brian,

Thanks :)

The constraint is necessary to ensure that a processor that doesn't support this specification doesn't end up with wrong or misleading information.

I'm not sure that the constraint introduces too many concerns in the kind of environment that this is generally aimed at (offices and similar).  Your example seems like it is more of a case for using geodetic location information (potentially followed by a reverse geocoding step to get a plain civic location).  It's almost as if you are suggesting that the mechanics of location determination be exposed.  If you have two reference points, it's only necessary to pick one.

For your example, there are three alternatives: use geodetic, use (reverse-geocoded) civic, or use multiple location information elements.

In the latter approach, you have one relative location that identifies a containment and a relative measurement.  A second location can include the additional fields that are (or could be) misleading in combination with the relative position.

Cheers,
Martin

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 12 November 2008 8:34 AM
> To: Thomson, Martin; 'GEOPRIV'; [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Quick review of draft-linsner-geopriv-
> relativeloc-02
>

---

From: Marc Linsner <[email-masked]>
Date: Wed, 12 Nov 2008 09:06:08 -0500

Martin,

Thanks for the review.

Comments in-line....

On 11/9/08 7:00 PM, "Thomson, Martin" <[email-masked]> wrote:

> The most important part of this draft is the selection of the reference point.
> Selecting a unique point using something as imprecise as a civic address
> format is difficult.
> 
> partition that identifies the habited portion of the earth.  The second is the
> country.  Right down to road (which includes all properties that adjoin the
> street), and on to seat.  Each label might need to be interpreted with other
> values to provide context.  As a value at each level is interpreted, one or
> more partitions at that level are selected, and all other partitions of that
> type are excluded.  For non-orthogonal partitions, only the portion of the
> partition that fits within the existing space is selected (this is what
> ensures that George St in Sydney is selected, rather than the George St in
> Newcastle).  In effect, each defined element selects a partition of space and
> the resultant location is the intersection of all selected spaces.
> 
> no stage does this select a point, though as spaces get smaller, approximation
> to a point is useful.
> 
> the space selected by the rest of the civic address.

Agree.  Currently this is in the draft as a SHOULD.

  I'll expand on the
> misinterpreted.  This is important for backward compatibility.

Agree.  If the location recipient doesn't understand the ref point/offset,
the associated civic data needs to still work.  The same is true with 'room
number', it's meaningless outside of the associated civic address.

> reference point.  If you specify a door as the reference, the resulting point
> has uncertainty of at least the size of a door.  Your corner office example
> still describes a location the size of an office.  An observation to this
> effect in the draft might be helpful.

OK.  I was under the assumption that human interpretation of civic locations
took this into account.  123 Main St. Room 106 carries with it the
understanding that any point within Room 106 is valid, hence I'm not sure
the whole area covered by Room 106 would/should be considered 'uncertainty'.
We need more discussion on this.

> the entire civic address be unambiguously understood.  Using generic reference
> labels (as suggested) can result in different interpretations if one or more
> of the civic address labels is not understood.  This means that you need to
> define which set of fields must be understood: all provided, or all 5139/4776
> labels (the difference is significant; I favour the former).

The civic location fields have a hierarchy to them: country; state; city;
street; address; etc.  Beyond street address, all supplementary data is
locally significant: floor; room; seat; cubicle; etc.  Do you think we need
to update the existing documents (4119, 5139) with this suggestion?

> northing and the up vector will get an easting vector.

The curvature discussion was added as a response to Carl Reed's comments.
Like you, I don't believe the use case this draft covers needs to be
concerned with earth curvature.  I think we were not clear in the use case
in earlier versions of the draft, hence Carl's concern, and we should ask
Carl if this still make sense.

> 
> The above is all probably moot since I suspect that people will be using this
> on floor plans.  Plot the reference point on the plan, provide a north vector
> (based on survey or a compass) and that's probably enough.
> 

We offered to do this in earlier discussions to help with confusing this
with geodetic locations.  We need more discussion amongst the
authors/contributors.

> 
> Don't extend the schema in the same namespace.  This doesn't work particularly
> well with the approach adopted by the IETF for XML design.  Define a new
> namespace and schema.  It doesn't even have to be flat like 5139 - that flat
> schema works well enough when you don't have any better structure, but you can
> potentially use a more GML-like position:

OK

> 
> Don't allow for feet.  If people want to use antiquated units of measure, they
> can use the standard formulae for conversion.  It's one fewer element to
> define.
> 
> Section 9.2 is empty.

OK

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Wed, 12 Nov 2008 09:15:30 -0500

Brian,

In-line....

snip...................
> addresses.

I don't understand.  Are you referring to an admin domain that has APs
spread across multiple civic addresses?

If this were the case, why would that admin domain offer a reference point
located at 123 Main St. from an AP located at 125 Main St.?

-Marc-

  By your reasoning, we would have to go up a level (street for
> of two adjacent streets (back to back buildings for example).

snip.....................

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Nov 2008 16:00:29 -0600

Hi Marc,

> reference

This is only a concern in that the reference point might have a different meaning if the fields aren't understood.  This includes any potential extensions to the civic LO.  All that I'm asking is that you define the set of fields that must be understood before the relative position is applied.  That's a note for this document.

For instance, a reference point of "main entrance" has a greatly different meaning depending on how much of the location you've actually understood.  If you only understood to the building level, and not to the level of an office (or some proprietary compartment) you get a completely different meaning.

Cheers,
Martin

---

From: Marc Linsner <[email-masked]>
Date: Wed, 12 Nov 2008 17:37:52 -0500

Martin,

Thanks, now I understand where you are coming from.

-Marc-

On 11/12/08 5:00 PM, "Thomson, Martin" <[email-masked]> wrote:

> This is only a concern in that the reference point might have a different
> meaning if the fields aren't understood.  This includes any potential
> extensions to the civic LO.  All that I'm asking is that you define the set of
> fields that must be understood before the relative position is applied.
> That's a note for this document.
> 
> For instance, a reference point of "main entrance" has a greatly different
> meaning depending on how much of the location you've actually understood.  If
> you only understood to the building level, and not to the level of an office
> (or some proprietary compartment) you get a completely different meaning.
> 
> Cheers,
> Martin

---

From: TSG <[email-masked]>
Date: Wed, 12 Nov 2008 16:01:08 -0800

Guys -
This is why the MONUMENT-Type Location Indicator needs to be defined. 
And yes local Address formats need to be recallable - as should be the 
encoded version... Somewhat like XDR makes NFS work. When I originally 
specified these controls in 1998 we included the ability to attach a 
statement of Legal Jurisdiction to a signed location tag. You are right 
in that you will also need to factor how cities lay out addresses as 
well into this mindset.

BTW - as a comment on the Reference Points - in my vision of the 
controls Physical and Virtual Locations may include any referable 
reference point This includes Side Doors, Hallways, Rooms, Structural 
Stairways, Elevator's and other internal or localization instances where 
a location could be controlled under some policy set without being the 
'location of reference'. Locations are Physical, Logical, and Virtual in 
form. The also may or may not have MONUMENT status - i.e. legal 
importance. They can be linked lists or loosely associated lists which 
specify location and entitlement control.

Todd Glassey

Marc Linsner wrote:
>>>> There is another aspect to the definition of the reference point.
>>>>         
>>> The
>>>       
>>>> reference location has local significance, but it's extremely
>>>>         
>>> important that
>>>       
>>>> labels (as suggested) can result in different interpretations if one
>>>>         
>>> or more
>>>       
>>>> of the civic address labels is not understood.  This means that you
>>>>         
>>> need to
>>>       
>>>> define which set of fields must be understood: all provided, or all
>>>>         
>>> 5139/4776
>>>       
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM
>
>

---

From: <[email-masked]>
Date: Sat, 15 Nov 2008 02:45:29 +0200

Few remarks below:

  >From: [email-masked] 
  >[mailto:[email-masked]] On Behalf Of ext Marc Linsner
  >Sent: Wednesday, November 12, 2008 6:06 AM
  >To: Thomson, Martin; GEOPRIV; [email-masked]
  >Subject: Re: [Geopriv] Quick review of 
  >draft-linsner-geopriv-relativeloc-02
  >
  >Martin,
  >
  >Thanks for the review.
  >
  >Comments in-line....
  >
  >
  >> As with other drafts, I think that this work is useful.  
  >It may be a 
  >> little early, but that's not a failure of the draft.  My major 
  >> concerns arise from execution.  As documented, this draft 
  >doesn't have 
  >> quite enough detail to ensure that it doesn't cause problems.
  >> 
  >> Selecting a unique point using something as imprecise as a civic 
  >> I find that it is helpful to think of the civic address as 
  >defining a 
  >> series of (sometimes non-orthogonal) spatial partitions.  
  >The first is 
  >> the implicit partition that identifies the habited portion of the 
  >> earth.  The second is the country.  Right down to road 
  >(which includes 
  >> all properties that adjoin the street), and on to seat.  
  >Each label 
  >> might need to be interpreted with other values to provide 
  >context.  As 
  >> a value at each level is interpreted, one or more 
  >partitions at that 
  >> level are selected, and all other partitions of that type are 
  >> excluded.  For non-orthogonal partitions, only the portion of the 
  >> partition that fits within the existing space is selected (this is 
  >> what ensures that George St in Sydney is selected, rather than the 
  >> George St in Newcastle).  In effect, each defined element 
  >selects a partition of space and the resultant location is 
  >the intersection of all selected spaces.
  >> 
  >> This view helps with correlating the civic address with a geodetic 
  >> position, including uncertainty (the selected space is the 
  >region of 
  >> uncertainty).  At no stage does this select a point, 
  >though as spaces 
  >> get smaller, approximation to a point is useful.
  >> 
  >> The reference point AND resultant relative location must 
  >be contained 
  >> within the space selected by the rest of the civic address.
  >

I do not think this restriction is necessary. The cited radio frequency
measurement technologies are unlikely to be able to determine whether
the resultant relative location is within the boundaries of the rest of
the civic address. A map application which understands the reference
point and knows the boundaries of the civic address, would be able to.
And if the resultant relative location falls within the boundaries of
the adjacent civic address, that is an important piece of information
especially in cases when this is the only way to determine the civic
address at the point of presence.

  >> relative elements are not understood, the rest of the 
  >civic address 
  >> isn't misinterpreted.  This is important for backward 
  >compatibility.
  >
  >Agree.  If the location recipient doesn't understand the ref 
  >point/offset, the associated civic data needs to still work. 
  > The same is true with 'room number', it's meaningless 
  >outside of the associated civic address.

If the reference point is not understood, then the relative location
should be disregarded. 

With respect to the 'room number' example above, that may be meaningful
outside the associated civic address. As an example, consider a mall
with a Stacbucks inside (having the same civic address as the rest of
the shops in the mall). Receiving a relative position telling you that
you are 10m from Starbucks while outside on the street, could be useful
information. There are probably better examples, the idea is that
whether a reference point is meaningful or not outside an associated
civic address, should be decided by the application using it (the
reference point belongs to the associated civic address, but may be
meaningful outside of it).
 
  >> (The above also applies for if you allow this to be used 
  >in a complex 
  >> with geodetic positions, but you would have to define this 
  >as relative 
  >> to the centroid and restrict it to the geodetic positions 
  >that have 
  >> uncertainty.)
  >> 
  >> The resultant relative location is only as good as the 
  >specification 
  >> of the reference point.  If you specify a door as the 
  >reference, the 
  >> resulting point has uncertainty of at least the size of a 
  >door.  Your 
  >> corner office example still describes a location the size of an 
  >> office.  An observation to this effect in the draft might 
  >be helpful.

I would propose adding one additional element, RELPOS-R (radius), which
would tell the range the subject is from the reference point (eg within
10m from the elevator) and/or a RELPOS-D (distance), which would tell
how far the subject is from the reference point (eg 10m from the
elevator) without specifying the angle from the true north (X, Y
coordinates) as most of the time that will be impossible to be
determined and in many cases useless (on a corridor you can only walk
straight).

- Gabor

  >OK.  I was under the assumption that human interpretation of 
  >civic locations took this into account.  123 Main St. Room 
  >106 carries with it the understanding that any point within 
  >Room 106 is valid, hence I'm not sure the whole area covered 
  >by Room 106 would/should be considered 'uncertainty'.
  >> important that the entire civic address be unambiguously 
  >understood.  
  >> Using generic reference labels (as suggested) can result 
  >in different 
  >> interpretations if one or more of the civic address labels is not 
  >> understood.  This means that you need to define which set 
  >of fields 
  >> must be understood: all provided, or all 5139/4776 labels 
  >(the difference is significant; I favour the former).
  >
  >The civic location fields have a hierarchy to them: country; 
  >state; city; street; address; etc.  Beyond street address, 
  >all supplementary data is locally significant: floor; room; 
  >seat; cubicle; etc.  Do you think we need to update the 
  >existing documents (4119, 5139) with this suggestion?
  >
  >> 
  >> Minor points:
  >> 
  >> Discussing earth curvature isn't really helpful.  If you 
  >want to talk 
  >> about getting a very accurate geodetic position, my 
  >suggestion is that 
  >> you be even more specific.  Convert to ECEF, and use the resultant 
  >> x,y,z to get a unit vector for "up".  Then derive the 
  >northing vector 
  >> by calculating the azimuth to a point directly north and 
  >adjusting for 
  >> curvature.  The cross product of northing and the up 
  >vector will get an easting vector.
  >
  >Like you, I don't believe the use case this draft covers 
  >needs to be concerned with earth curvature.  I think we were 
  >not clear in the use case in earlier versions of the draft, 
  >hence Carl's concern, and we should ask Carl if this still 
  >make sense.
  >
  >> 
  >> The above is all probably moot since I suspect that people will be 
  >> using this on floor plans.  Plot the reference point on the plan, 
  >> provide a north vector (based on survey or a compass) and 
  >that's probably enough.
  >> 
  >> Don't use X, Y and Z.  Use EW, NS and UD (or the longer EastWest, 
  >> NorthSouth and UpDown).  This is easier to remember and 
  >you don't have 
  >> problems with people putting north/south first and stuffing it up.
  >
  >We offered to do this in earlier discussions to help with 
  >confusing this with geodetic locations.  We need more 
  >discussion amongst the authors/contributors.
  >
  >> 
  >> particularly well with the approach adopted by the IETF for XML 
  >> design.  Define a new namespace and schema.  It doesn't 
  >even have to 
  >> be flat like 5139 - that flat schema works well enough 
  >when you don't 
  >> have any better structure, but you can potentially use a 
  >more GML-like position:
  >> You don't want to use ca:caType for EW, NS and UD since 
  >those elements 
  >> are numerical and don't require xml:lang.
  >
  >OK
  >
  >> 
  >> Don't allow for feet.  If people want to use antiquated units of 
  >> measure, they can use the standard formulae for 
  >conversion.  It's one 
  >> fewer element to define.
  >> 
  >> Section 9.2 is empty.
  >
  >OK
  >
  >-Marc-
  >
  >> 
  >> Cheers,
  >> Martin
  >> 
  >-------------------------------------------------------------
  >---------
  >> --------
  >> ------------------
  >> This message is for the designated recipient only and may contain 
  >> privileged, proprietary, or otherwise private information.
  >immediately 
  >> and delete the original.  Any unauthorized use of this email is 
  >> prohibited.
  >> 
  >-------------------------------------------------------------
  >---------
  >> --------
  >> ------------------
  >> [mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 16 Nov 2008 11:05:56 -0600

Hi Gabor,

> address at the point of presence.

This constraint is necessary for reasons of backward compatibility.  Sure, you cannot prevent people from describing down to SEAT, which would make the whole thing virtually impossible to guarantee.  However, that doesn't mean that we shouldn't still make a MUST like I suggested.  The responsibility for ensuring that this is true is one that is shared.  This covers the provisioning of the information (i.e. don't specify fields that cannot be guaranteed) as well as the technology side.

I'll note that you can't prevent your WiFi from spilling out of a building, so there is a reasonableness test.  Keep in mind that civic address also have confidence and that you can be wrong.  If we use the same confidence as for geodetic, then we are allowed to be wrong 5% of the time.  That should cover those cases - and if it doesn't, then you need to consider different approaches, probably in your provisioning.

>   >>For the result, this ensures
>   >that if the

Useful or not, the information is actually harmful if someone doesn't understand relative-loc.  They are lead to believe that they are in the Starbucks (or the mall), which is false.
 
> determined and in many cases useless (on a corridor you can only walk

I didn't understand this suggestion.  This information sounds either like an uncertainty radius (based on a civic address anchor) or it sounds like it could just be derived (sqrt(x^2 + y^2)).

Cheers,
Martin

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 17:44:54 +0200

Inline:

  >This constraint is necessary for reasons of backward compatibility.
  >Sure, you cannot prevent people from describing down to SEAT, which
would
  >make the whole thing virtually impossible to guarantee.  However,
that
  >doesn't mean that we shouldn't still make a MUST like I suggested.
The
  >responsibility for ensuring that this is true is one that is shared.
  >This covers the provisioning of the information (i.e. don't specify
  >fields that cannot be guaranteed) as well as the technology side.

I do not see any backward compatibility issues. If the resultant
relative location is outside the boundaries of the civic address, does
not mean you are wrong. You could have instead been wrong if you didn't
take into consideration the reference point and relative position.

  >I'll note that you can't prevent your WiFi from spilling out of a
  >building, so there is a reasonableness test.  Keep in mind that civic
  >address also have confidence and that you can be wrong.  If we use
the
  >same confidence as for geodetic, then we are allowed to be wrong 5%
of
  >the time.  That should cover those cases - and if it doesn't, then
you
  >need to consider different approaches, probably in your provisioning.

End devices are expected to use multiple radio measurement methods to
determine location. Some of the determined locations may be partial and
may only make sense if combined together.
  
...
  >I didn't understand this suggestion.  This information sounds either
like
  >an uncertainty radius (based on a civic address anchor) or it sounds
like
  >it could just be derived (sqrt(x^2 + y^2)).
  
Yes, if you know x and y. Current radio frequency measurement methods
are not capable to determine x and y, but they can determine a range or
distance from a reference point.

>-----------------------------------------------------------------------
--
  >-----------------------
 
>-----------------------------------------------------------------------
--
  >-----------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 18 Nov 2008 17:49:50 -0600

Hi Gabor,

> take into consideration the reference point and relative position.

If the relative location points outside of the boundaries of the civic address, then you are misleading those clients that don't understand relative-loc.  You then have two choices.

 - If you are able, provide the information that you do have and that you know is accurate.  This might be considerably worse than otherwise, and you might need to specify your reference point more elaborately, but at least you aren't being purposefully misleading.

 - If you are unable to provide any information otherwise, then you could provide the information in a new container, that can't in any other way be mistaken for a civic address.  In other words, don't even attempt to be backwardly compatible.

> may only make sense if combined together.

If that is the case, then you are working in a coordinate space.  If you are doing that, then a geodetic position might be more appropriate (and yes, I understand the cases where this is hard to do, and so on).  Otherwise, read above.

>From this, it sounds like you would like to have a way to express uncertainty.  This could be added to the document, but that would be up to Marc.

Cheers,
Martin

---

From: <[email-masked]>
Date: Thu, 20 Nov 2008 08:43:24 +0200

Martin,
  >If the relative location points outside of the boundaries of the
civic
  >address, then you are misleading those clients that don't understand
  >relative-loc.  

Let's take an example:
An AP has its location configured as being at the Reference Point A
within the civic location X. A device downloads that location, then
involves radio technology measurements and determines that is is 50m
away from the AP (reference Point A). 

The map application then will figure out based on these inputs, where
the device possibly is, at the same location X, or in an adjacent one.

In the example above, the radio measurement was done by the device, thus
the result is available in the device, which is the entity computing the
resultant location.

Radio measurement can be performed by the network/AP as well, case in
which the relative position is determined by the network. The device
gets that location which includes the relative location, provides it to
a map application, which will determine if the resultant location of the
device is at the same location X, or outside of it (note, the AP will
not do that).

There is uncertaincy in it, but that comes from the uncertaincy of the
radio technology method determining the relative position.

You seem to assume that the entity providing the location, involving
radio measurements to determine relative location and the one
calculating the resulting location is the same, while those are at least
2, sometimes 3 different ones.

  > You then have two choices.
  >
  > - If you are able, provide the information that you do have and that
you
  >know is accurate.  This might be considerably worse than otherwise,
and
  >you might need to specify your reference point more elaborately, but
at
  >least you aren't being purposefully misleading.
  >
  > - If you are unable to provide any information otherwise, then you
could
  >provide the information in a new container, that can't in any other
way
  >be mistaken for a civic address.  In other words, don't even attempt
to
  >be backwardly compatible.
  >
  >If that is the case, then you are working in a coordinate space.
A mix of both. I can describe the building and the reference points
inside it with coordinates, but I need relative location to better
specify the location.

  If you
  >are doing that, then a geodetic position might be more appropriate
(and
  >yes, I understand the cases where this is hard to do, and so on).
  >Otherwise, read above.
  >
  >From this, it sounds like you would like to have a way to express
  >uncertainty.  

I just want to accurately describe the result of a radio measurement.
And those come with uncertaincy.

This could be added to the document, but that would be up
  >to Marc.
 
--
 
--

---

From: TSG <[email-masked]>
Date: Thu, 20 Nov 2008 08:00:26 -0800

> away from the AP (reference Point A). 
You mean "in and about Reference Point A" right? Unless a specific 
x:y:z:time cooridinate is included here there is no absolute fixing 
being done. Its a range of locations.
> radio technology method determining the relative position.
The addition of any uncertainty to the chain-of-custody makes the 
attestation of the device of less value from an evidence standpoint. 
Depending on what's being controlled with the location/proximity systems 
this may be a serious problem. Each object or element in the trust chain 
*** MUST *** me capable of being set to a mode where they are 
authenticated individually and such that they provide a unique assurance 
as well that they are 'what they represent themselves to be'.

> Version: 8.0.175 / Virus Database: 270.9.8/1800 - Release Date: 11/19/2008 6:55 PM
>
>