Subject: [Geopriv] Why draft-stanley-geopriv-indoor-location will not interoperate

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 25 Nov 2009 12:49:35 +0800

draft-stanley-geopriv-indoor-location will not interoperate.

I presented the same explanation in response to draft-linsner-geopriv-relativeloc; the two proposals are identical in this regard, as they are in many other aspects.

--
Existing civic definitions RFC 4776/5139 follow a simple rule:

  The location described by a set of civic address elements is entirely contained within the location described by any subset of those elements.

Or, from a different angle:

  Every civic address element adds information, it does not change existing information.

This rule is what makes the civic address definition extensible.  This rule ensures that elements can be safely ignored by processors that do not support them.  Applications can even choose to support a subset of the civic address elements safely.

  For instance, an application that is designed solely for use within Austria is able to ignore the STS element.  For addresses outside of Austria that use STS, the application wont perform well, but at least it wont break.

It also means that removing elements is safe: it might degrade the location but it does not fundamentally change it.

draft-ietf-geopriv-policy relies on this property for its privacy transformation.  Geocoders rely on this property - they only support a subset of the fields.  No application can know all possible civic address elements (especially if we accept Brian's arbitrary INT containers); therefore, all applications necessarily rely on this property.

All the extension proposals we've seen so far respect this rule, except draft-linsner-geopriv-relativeloc and draft-stanley-geopriv-indoor-location.  These proposals introduce elements that break this cardinal rule.  An application that does not understand the extension can be mislead if it ignores the offset values.

--
This really only hints at a bigger issue with draft-stanley-... in that it incorrectly assumes that this data forms a civic address.  Indoor location data is a new form of location information, it is not a "small expansion of the definition of a civic address".  In many respects, indoor locations more closely resemble geodetic data.

In any case, it should be clear from my explanation that this extension is not compatible with the definition of civic addresses.

--Martin

---

From: Marc Linsner <[email-masked]>
Date: Wed, 25 Nov 2009 09:37:33 -0500

Martin,

On 11/24/09 11:49 PM, "Thomson, Martin" <[email-masked]> wrote:

> 
> --
> This really only hints at a bigger issue with draft-stanley-... in that it
> incorrectly assumes that this data forms a civic address.  Indoor location
> data is a new form of location information, it is not a "small expansion of
> the definition of a civic address".  In many respects, indoor locations more
> closely resemble geodetic data.
> 
> In any case, it should be clear from my explanation that this extension is not
> compatible with the definition of civic addresses.
> 

How do you propose to revolutionize the myriad of people who are already
using reference point and offset in conjunction with civic.

"Hey Joe, run up on the 3rd floor and get my left-handed monkey wrench.
You'll see it on the floor about 30 west of elevator #1"

maybe

"Hey Joe, go get my left-handed monkey wrench, you'll find it at 33°56′46″S
151°10′38″E at 18m altitude."

-Marc-

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Wed, 25 Nov 2009 08:09:51 -0800

Martin - I fail to see how the Stanley-geopriv-indoor-location proposal
is not interoperable.

After reading this email I began to question what I thought was the
definition of interoperability. So I looked it up...

The IEEE defines interoperability as:

"the ability of two or more systems or components to exchange
information and to use the information that has been exchanged"

another definition found:

"the ability of systems, units, or forces to provide services to and
accept services from other systems, units or forces and to use the
services exchanged to enable them to operate effectively together."

Regarding your point about that Civic address elements adding
information but does not change information. 

>> I agree.

However, I can't agree that removing elements is safe.

What happens if you remove the building name from Civic and leave floor
name. The floor name is not unique without the building name. Therefore
there is inherent structure in the civic address that must be provided
if systems need to interoperate using floor names.

The Stanley-geopriv-indoor-location uses the same semantics to define a
fully qualified indoor location where it adds additional parameters to
the civic address in a structured way to define a position in a floor.
Without building or floor, the indoor location is meaningless.

So I disagree with your explanation shows that indoor location is not
compatible with the definition of civic addresses. If you talk to any
indoor location vendor today they all use a building based reference
location system (campus->building->floor->etc.) where the position on
the floor is an extension of the building based model. Many companies
have done this because it is a "natural" fit.

Again, the Stanley-geopriv-indoor-location proposal does not preclude
your proposal of using geospatial information for indoor going forward.
That is one of the fundamental differences between yours and the stanley
draft. And that is why the original recommendation was to continue both
drafts.

allan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Tuesday, November 24, 2009 8:50 PM
To: [email-masked]
Subject: [Geopriv] Why draft-stanley-geopriv-indoor-location will
notinteroperate

I presented the same explanation in response to
draft-linsner-geopriv-relativeloc; the two proposals are identical in
this regard, as they are in many other aspects.

  The location described by a set of civic address elements is entirely
contained within the location described by any subset of those elements.

  Every civic address element adds information, it does not change
existing information.

This rule is what makes the civic address definition extensible.  This
rule ensures that elements can be safely ignored by processors that do
not support them.  Applications can even choose to support a subset of
the civic address elements safely.

  For instance, an application that is designed solely for use within
Austria is able to ignore the STS element.  For addresses outside of
Austria that use STS, the application wont perform well, but at least it
wont break.

It also means that removing elements is safe: it might degrade the
location but it does not fundamentally change it.

draft-ietf-geopriv-policy relies on this property for its privacy
transformation.  Geocoders rely on this property - they only support a
subset of the fields.  No application can know all possible civic
address elements (especially if we accept Brian's arbitrary INT
containers); therefore, all applications necessarily rely on this
property.

All the extension proposals we've seen so far respect this rule, except
draft-linsner-geopriv-relativeloc and
draft-stanley-geopriv-indoor-location.  These proposals introduce
elements that break this cardinal rule.  An application that does not
understand the extension can be mislead if it ignores the offset values.

--
This really only hints at a bigger issue with draft-stanley-... in that
it incorrectly assumes that this data forms a civic address.  Indoor
location data is a new form of location information, it is not a "small
expansion of the definition of a civic address".  In many respects,
indoor locations more closely resemble geodetic data.

In any case, it should be clear from my explanation that this extension
is not compatible with the definition of civic addresses.

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

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 25 Nov 2009 10:34:32 -0700

There is considerable work being done in Korea on this issue. The Koreans 
have a huge government sponsored countrywide initiative titled "u-City". I 
have slides if anyone is interested. Anyway, within the u-City context there 
is a sub-project titled "Spatial Awareness". A key focus of this activity is 
how people navigate outdoors, indoors, and the combination of the two. 
Related to this particular issue, they have been working on how to best 
perform (from a computer perspective) spatial transformations among and 
between the many ways of defining a location so that applications can 
actually provide seamless navigation and routing in any spatial reference 
context. This work has resulted in a number of draft standards documents 
that have been submitted into ISO TC 211 for consideration as International 
Standards. I am a nominated expert representing the OGC community for these 
activities. Their approach even works aboard a cruise ship!

Regards

Carl

----- Original Message ----- 
From: "Marc Linsner" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 25, 2009 7:37 AM
Subject: Re: [Geopriv] Why draft-stanley-geopriv-indoor-location will not 
interoperate

>> it
>> is not

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Nov 2009 06:04:13 +0800

Marc,

You miss my point entirely.

The point is not that civic can't be used, just that it can't be used *as described in the draft*.

--Martin

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Thursday, 26 November 2009 1:38 AM
> To: Thomson, Martin; [email-masked]
> Subject: Re: [Geopriv] Why draft-stanley-geopriv-indoor-location will
> not interoperate
> 
> Martin,
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 26 Nov 2009 07:00:23 +0800

Hi Allan,

>...

Removing elements is safe.  It has to be.  If you create an extension (say pole number or number prefixes) then you must be able to remove the extension, because some implementations wont understand it.

> if systems need to interoperate using floor names.

Sure, it reduced the usefulness of the location information - it now might be any of a number of different buildings - but it has only increased the region of uncertainty, not moved it.

This might be inadequate for the application in mind, but it hasn't prevented interoperability.

The worst that can happen when an application doesn't support an element is a known ambiguity.

Say someone didn't understand a house number prefix (Brian's new work).  Say that element was necessary to distinguish between a-14 and b-14 Smith St.  If the application doesn't understand the prefix, it sees HNO=14, which potentially identifies two houses.  Now it's uncertain about which house the location refers to, but it hasn't mistakenly picked number 16.

> Without building or floor, the indoor location is meaningless.

But there's a difference between meaningless (or useless) and misleading.  Stanley-geopriv-indoor-location allows for the latter.
 
> have done this because it is a "natural" fit.

We disagree.  It is certainly not "natural", whatever that means.  I can appreciate how it might have been convenient or expedient.  Those are often the opposite of correct.

> draft. And that is why the original recommendation was to continue both

You'll have to explain that.  Because I don't see how that might work.

Please, let's try to create one solution for this.  Two solutions is an unnecessary burden on implementations.

--Martin