Subject: [Geopriv] RE: For those interested in WiFi location determination

From: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 26 Nov 2007 18:48:13 -0700

http://www.mycoordinates.org/testing-indoor-environment.php

      Testing of location systems using WiFi in indoor environments
      GUENTHER RETSCHER, ESMOND MOK 
            The use of WiFi for location determination has the advantage that no transmitters or receivers have to be installed in the building like in the case of infrared and ultrasonic based location systems. 

Carl Reed, PhD
CTO and Executive Director Specification Program
OGC

The OGC: Helping the World to Communicate Geographically

---------------------

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.

"The important thing is not to stop questioning." -- Albert Einstein 
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 10:46:03 +0100

Hi Carl,

thanks for sending us the link to "Testing of location systems using 
WiFi in indoor environments".
A quote from the paper:

"
As can be seen from Figure 3 the achievable positioning accuracies vary 
quite significantly and range from ± 1.3 to 6.3 m with a few outlieres 
with even larger positioning errors.
"

That's interesting date but as one can also see in the paper they are 
mapping the obtained position to civic information with the available 
maps. Hence, the errors do not really matter in this case (at least not 
for the question about generated location shapes we have).

I wonder whether someone is really using geodetic information within a 
building for a serious usage. In outdoor environments the errors are 
likely to be entirely different.

Ciao
Hannes

PS: I contacted the authors of that paper to get more information.

Carl Reed OGC Account wrote:
> ------------------------------------------------------------------------
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Nov 2007 08:28:37 -0500

On Nov 27, 2007, at 4:46 AM, Hannes Tschofenig wrote:

>
>
> That's interesting date but as one can also see in the paper they  
> are mapping the obtained position to civic information with the  
> available maps. Hence, the errors do not really matter in this case  
> (at least not for the question about generated location shapes we  
> have).

Unless the PSAP (or pizza delivery service) has a very accurate floor  
plan that is carefully mapped, providing geo information to the  
dispatch center seems rather pointless. What would the pizza guy do  
with geo coordinates, even assuming that he carries a GPS, given that  
it wouldn't work indoors? Is he going to ask the receptionist for the  
meeting room at 40.809403, -73.959223? On the other hand, that turns  
each pizza delivery and emergency into a game of geocaching...

Henning

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 27 Nov 2007 14:30:55 +0100

Hi Henning, 

> each pizza delivery and emergency into a game of geocaching...

I was in these cases actually hoping that the LIS in the access network
returns civic location information 
(for example via DHCP) instead of the geodetic location information when
it has such a floor plan. 

Ciao
Hannes

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 27 Nov 2007 07:48:04 -0600

We have witnessed first hand how a geodetic location can easily be
converted into an incorrect civic address due to differences in the
spatial data that is being used for the geodetic to civic translation.

It is far better to let the local PSAP (in this example) do the
translations because they are (should be) using the most up-to-date
geographic information and are most familiar with their area. 

Imagine trying to locate 40.809403, -73.959223 on several different sets
of geographic databases. One put the location at the NW corner of W
120th St and Amsterdam Ave, one puts it at say 1207 Amsterdam Avenue,
one puts it at the back corner of the Whitter building at the Teachers
Collage, and still another places it at the Engineering Terrace at
Columbia University. Too many variables (and liability) to be letting
anyone perform a geodetic to civic transformation other than at the
local level.

Thanks,
 Marc B

-----Original Message-----
From: Tschofenig, Hannes (NSN - DE/Munich)
[mailto:[email-masked]] 
Sent: Tuesday, November 27, 2007 7:31 AM
To: ext Henning Schulzrinne; Hannes Tschofenig
Cc: [email-masked]
Subject: AW: [Geopriv] RE: For those interested in WiFi location
determination

Hi Henning, 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 14:54:46 +0100

Hi Marc,

> geographic information and are most familiar with their area. 
But the PSAP is less likely have the floor plan for the building of your 
company site.

> anyone perform a geodetic to civic transformation other than at the
But isn't it most likely the case that the local network operator knows 
the location best?

Ciao
Hannes

>>> available maps. Hence, the errors do not really matter in 
>>>       
>> this case  
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 09:11:26 -0500

Never convert and then send the converted data.

How many times, in how many ways do we have to say that?

You can do a conversion and use it at that point for something, but you
never send the converted value; you send the original.

The only local network operator who would know the location best is an
enterprise, and it would be MUCH better for all concerned if the floorplan
was available for public safety.  No other access network will know better
than a PSAP (for the emergency case).

You probably need an escape, where the destination has no conversion
capability but the origination does.  If that's the circumstance, then you
have no choice.  That isn't the emergency case.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2007 8:55 AM
> To: Marc Berryman
> Cc: [email-masked]; Tschofenig,Hannes (NSN - DE/Munich); ext Henning
> Schulzrinne
> Subject: Re: [Geopriv] RE: For those interested in WiFi location
> determination
> 
> Hi Marc,
> 
> Marc Berryman wrote:

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 27 Nov 2007 08:18:42 -0600

Good morning Hannes,

Having dealt with local network operators, I can safely say, not really.
The addresses they use are often the address of the main office, or the
main mail stop, and does not accurately reflect the actual location of
the access point (for example). Often the address they provide is
incorrect, e.g. North Interstate 45 @ Main or 212 Main, rather than the
correct address of 212 North Main St.

I have had arguments with major providers who tell me they know exactly
where all their physical assets' are located, only for me to serve them
up a bit of humble pie when I show them some discrepancies in their
data.

I have no problem with the access provider obtaining the address, for
their access points, through their local 9-1-1 agencies. This too can
become a catch 22 because not all local 9-1-1 agencies are as
discriminating with providing the correct information as others. This is
another story though, a job where the "public educators" need to become
the "PSAP educators" as well, and another reason I always drink a glass
of wine before bed so I can sleep.

Thanks,
 Marc B

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, November 27, 2007 7:55 AM
To: Marc Berryman
Cc: Tschofenig, Hannes (NSN - DE/Munich); ext Henning Schulzrinne;
[email-masked]

Hi Marc,

company site.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 15:20:44 +0100

With this argument the applicability of DHCP-civic is not really useful 
when the location of the Target has to be returned.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Nov 2007 09:23:06 -0500

I hope we're agreeing that Columbia University (where indeed these  
coordinates are from) would send civic location data to the PSAP or  
the pizza parlor, so that there's no need to convert anywhere. As  
Hannes pointed out, that's what the indoor location systems generate  
naturally (since that's what's useful for other purposes, such as  
equipment or personnel tracking.) If it were to send geo data, the  
PSAP or pizza parlor would have to convert to building-and-floor data,  
which is clearly what we want to avoid. Since the WLAN positioning  
system doesn't use geo coordinates internally, they don't enter the  
picture unless somebody were to manually convert rooms or points on  
the floor plan to such coordinates, which also seems pointless and  
error-prone.

We've had this discussion before (and before that...).

This means that worrying about indoor geo positioning, i.e., 3825,  
seems unnecessary. In other words, we've narrowed typical 3825  
applicability to the outdoor/campus WiFi AP situation, where we are  
back to the roughly-RF-range discussion, i.e., some rough indication  
of 802.11 range that's pretty much location-independent (since nobody  
is going to map it precisely).

Henning

On Nov 27, 2007, at 8:54 AM, Hannes Tschofenig wrote:

> But the PSAP is less likely have the floor plan for the building of  
> your company site.
>
> But isn't it most likely the case that the local network operator  
> knows the location best?
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 09:26:15 -0500

Huh?  Why would you say that?  If the location was civic to start with
return civic.  You might not use that if the AP triangulated and produced a
geo, but, for if you are returning the location of the AP as the location of
a target it is.

Brian

> Sent: Tuesday, November 27, 2007 9:21 AM
> To: Brian Rosen
> Cc: 'Marc Berryman'; [email-masked]; 'Tschofenig,Hannes (NSN -
> DE/Munich)'; 'ext Henning Schulzrinne'
> your

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 16:02:57 +0100

Hi Brian,

> geo, but, for if you are returning the location of the AP as the location of

In a wireless environment location determination techniques do not 
produce civic location. In my discussion with Ray you might have 
realized that he also maps the location to a specific civic address.
In a fixed environment, like the DSL case or the enterprise environment 
with your Ethernet jack, you get civic location
information.

Ciao
Hannes

>>> enterprise, and it would be MUCH better for all concerned if the
>>>       
>> floorplan
>>     
>>> was available for public safety.  No other access network will know
>>>       
>> better
>>     
>>> capability but the origination does.  If that's the circumstance, then
>>>       
>> you
>>     
>>>>> Imagine trying to locate 40.809403, -73.959223 on several different
>>>>>           
>> sets
>>     
>>>>> I was in these cases actually hoping that the LIS in the access
>>>>>           
>> network
>>     
>>>>> (for example via DHCP) instead of the geodetic location information
>>>>>           
>> when
>>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 10:24:50 -0500

Hannes, 
  
> 
> In a wireless environment location determination techniques 
> do not produce civic location.

This is not true.  802.11 location determination systems produce data shown
in draft-linsner-geopriv-relativeloc-01.  This draft aligns with the
on-going work in the 802.11 group.

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 16:40:32 +0100

Hi Marc,

Marc Linsner wrote:
> in draft-linsner-geopriv-relativeloc-01.

That's true. It seems to cover one specific use case for transmitting 
location information obtained via WLAN location determination techniques.

>   This draft aligns with the
Presumably because you have brought it there.

Btw, I believe that the approach is not going into the right direction 
and the draft is quite misleading about it's intention.

Ciao
Hannes

---

From: [email-masked]
Date: Tue, 27 Nov 2007 10:54:18 -0500 (EST)

Hannes -

A number of OGC members have done some prototype testing of indoor
navigation systems (for first responders) that use a variety of
technologies to track human responders inside a building. In these
prototypes, they are generating geodetic locations. This is obviously a
different use case then you might be thinking. The OGC is looking to
having a formal testbed component in this area of functionality in 2008.
There has also been some excellent work done in U of NSW, Australia on in
door navigation.

Regards

Carl

>>             The use of WiFi for location determination has the advantage
>> that no transmitters or receivers have to be installed in
>> the building like in the case of infrared and ultrasonic
>> based location systems.
>>
>>
>> Carl Reed, PhD
>> This communication, including attachments, is for the exclusive use of
>> addressee and may contain proprietary, confidential or privileged
>> information. If you are not the intended recipient, any use, copying,
>> disclosure, dissemination or distribution is strictly prohibited. If you
>> are not the intended recipient, please notify the sender  immediately by
>> return email and delete this communication and destroy all copies.
>>
>> "Security is mostly a superstition. It does not exist in nature. Life is
>> either a daring adventure or nothing." -- Helen Keller
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 16:58:49 +0100

Hi Carl,

good to hear that. Are there some results available that could be used 
in the discussion?

The main answer I am still struggling with is the question what location 
shapes are useful in a WLAN environment.
A "Point" seems to be one when the appropriate location determination 
techniques can be applied. What should we do about the other case(s)?

Ciao
Hannes

---

From: [email-masked]
Date: Tue, 27 Nov 2007 11:15:54 -0500 (EST)

Hannes -

Yes. I will provide more details later as I have to join a teleconference
shortly.

All - Did not mean to open the dialogue again about what is provided to
the PSAP!  I just wanted to share the information. The work of the OGC WRT
standards and the EM community is more downstream - response and post
event as well as risk mitigation.

That said, in various OGC activities, we have taken the use case of there
is  an emergency - say responding to a warehouse fire. The address is
already known and validated. The police, fire, and other services respond.
At this point, we (OGC community) are interested in how can we quickly
obtain and integrate multiple info sources, such as 3d building
information (using BIM/IFC standard content), utility locations, hazardous
materials information, exits/entries, and so forth. All of this integrated
information when combined with sensor data (including tracking devices on
the responders) can be used to enhance tracking and navigation for the
responders while they are in the building. Hence our interest in in-door
tracking and navigation.

Apologies if I caused a digression.

Regards

Carl

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 27 Nov 2007 11:28:12 -0500

Hannes,

1) What specific technical concern do you have with including a relative
location/offset in a civic location?

2) Please explain what is 'quite misleading' wrt the intention of the draft?

Btw, your presumption is wrong.

-Marc-

> Sent: Tuesday, November 27, 2007 10:41 AM
> To: Marc Linsner
> Cc: [email-masked]
> Subject: Re: [Geopriv] RE: For those interested in WiFi 
> location determination
> 
> Hi Marc,
> 
> Marc Linsner wrote:
> > Hannes,
> >   
> >   
> >> produce civic location.
> > This is not true.  802.11 location determination systems 
> produce data 
> > shown in draft-linsner-geopriv-relativeloc-01.
> 
> That's true. It seems to cover one specific use case for 
> transmitting location information obtained via WLAN location 
> determination techniques.
> 
> Btw, I believe that the approach is not going into the right 
> direction and the draft is quite misleading about it's intention.
> 
> Ciao
> Hannes
> 
> > -Marc-
> >   
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Nov 2007 11:39:24 -0500

All of the commercial wireless indoor positioning systems deliver, at  
the end, room locations or possibly relative offsets, not geo  
coordinates. After all, the survey process works by pin-pointing your  
current location on a building plan, which is then associated with the  
RF fingerprint.

Are you disagreeing with that?

On Nov 27, 2007, at 10:02 AM, Hannes Tschofenig wrote:

> In a fixed environment, like the DSL case or the enterprise  
> environment with your Ethernet jack, you get civic location
> information.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 20:41:43 +0100

Hi Henning,

> Are you disagreeing with that?
I am not. However, Brian's reasoning seems to be different.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 27 Nov 2007 14:53:17 -0500

Wait: if the survey process works by determining an RF fingerprint,
associating a civic address with that fingerprint, and determining which
fingerprint, and thus which location the device is located in, then that is
civic address determination and not conversion.  No one ever got to a
lat/lon.

There is discussion of a relative offset to a civic location.  We may have
to handle that.

Brian

> Sent: Tuesday, November 27, 2007 2:42 PM
> To: Henning Schulzrinne
> Cc: GEOPRIV WG

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 27 Nov 2007 12:22:58 -0800

I would cite a few applications of indoor LBS technology which DO! use
automatic "measurement" techniques to produce a coordinate position
instead of the more commonly thought of port-mapping solutions which
rely on initial manual (human) provisioning:

1. AFLT - Advanced Forward-Link Trilateration is effective for use
indoors to a limited extent - is widely deployed in support of Phase II
Wireless/CS deloyments for CDMA in the U.S. today, and depends on your
definition of "indoors",
2. Other signal-based trilateration methods, (e.g., Rosum DTV) which are
intended for commercial use, though don't have wide adoption currently.
3. Any WLAN trilateration algorithm which determines a position based on
AP known positions (provisioned or self-surveyed), or (some, if not
most) RF-fingerprinting* approaches - both may end up using
transformations to change the determined position to a civic location
via "association" via location-to-port mapping, reverse-geocoding, etc.,
(something around which folks apparantly have strong opinions).

* See referenced link (thanks Carl) to Univ. NSW paper below which
plainly refers to coordinate pair (x,y) products for both WLAN
positioning techniques:

http://www.gmat.unsw.edu.au/snap/publications/lib_etal2006a.pdf

-roger marshall.

> Sent: Tuesday, November 27, 2007 11:42 AM
> To: Henning Schulzrinne
> Cc: GEOPRIV WG
> >>> Huh?  Why would you say that?  If the location was civic to start 
> >>> with return civic.  You might not use that if the AP triangulated 
> >>> and produced a geo, but, for if you are returning the location of 
> >>> the AP as the location of a target it is.
> >>>
> >>>
> >>

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 23:35:21 +0100

Hi Marc,

I have sent a couple of comments already before IETF#69.

Anyway, here is new feedback for
http://tools.ietf.org/wg/geopriv/draft-linsner-geopriv-relativeloc-01.txt

Let's see whether you find it useful.

> location/offset in a civic location?

The document says that it defines relative location for a PIDF-LO and 
the DHCP Civic Location option.

I would like to express the reference value in civic and in geodetic
location information. 

For the PIDF-LO there is no reason to hack relative location into the
civic address field since there is a better way todo this. 
I compiled the idea based on the mailing list discussion and I also
sent it to you. Here again is the pointer to the document: 
http://www.tschofenig.priv.at/svn/draft-linsner-geopriv-relativeloc/draft-linsner-geopriv-relativeloc-02.txt
Obviously, it never got submitted. 

I am not sure why you define a the reference location as a text string
in the REFPT field. 

> 2) Please explain what is 'quite misleading' wrt the intention of the draft?

The document does not indicate for what you primarily want to use the 
proposed format. Is it for the
a) LIS to Target communication, or
b) for the Target to Location Recipient communication.

The difference between the two is:
* Defining the reference point as shown in REFPT might make is very 
difficult for a Location Recipient to actually understand
what's going on.
* The Target-to-LIS communication is more limited (at least for DHCP) 
and hence I do accept hacks more likely than with
a PIDF-LO enhancement.

The document needs more text at the beginning to explain the use case 
you have in mind.

I would understand when you say that you have an AP that is configured 
with civic or geodetic location information
(both seems to be reasonable to me) and then you put information in 
there regarding the distance of the target from the AP.

> Btw, your presumption is wrong.
Maybe. But I asked questions the weeks before IETF#69 and I did not got 
feedback. Now, I constructed my own story.

Don't get me wrong. Based on the discussions we had on the list about 
WLAN location determination I believe that location
information that indicates a reference value and the distance to the 
Target is useful.

Ciao
Hannes

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 09:32:20 -0500

Hannes,

Assumption: Relative location includes defining a reference point followed
by an offset.

In an attempt to better understand your position, please respond to these
points.

1) Your position is that a reference point described using civic
descriptions/attributes should not require any additional tags added to the
current civic location object?

2) In order to better understand the use case for expressing the reference
point as geo, can you provide real-world applications?

3) I don't understand your objection to providing relative location for all
LCP/discovery/conveyance functions.  Why is it not useful for any/all
location recipients to receive relative location information?

-Marc-

> Sent: Tuesday, November 27, 2007 5:35 PM
> To: Marc Linsner
> Cc: [email-masked]
> Subject: Review of draft-linsner-geopriv-relativeloc-01.txt
> 
> Hi Marc,
> 
> > 1) What specific technical concern do you have with including a 
> > relative location/offset in a civic location?
> >
> >   
> 
> The document says that it defines relative location for a 
> PIDF-LO and the DHCP Civic Location option.
> 
> I would like to express the reference value in civic and in 
> geodetic location information. 
> 
> For the PIDF-LO there is no reason to hack relative location 
> into the civic address field since there is a better way todo this. 
> I compiled the idea based on the mailing list discussion and 
> I also sent it to you. Here again is the pointer to the document: 
> http://www.tschofenig.priv.at/svn/draft-linsner-geopriv-relativelo
> c/draft-linsner-geopriv-relativeloc-02.txt
> I am not sure why you define a the reference location as a 
> text string in the REFPT field. 
>  
> 
> The document does not indicate for what you primarily want to 
> use the proposed format. Is it for the
> * Defining the reference point as shown in REFPT might make 
> is very difficult for a Location Recipient to actually 
> understand what's going on.
> * The Target-to-LIS communication is more limited (at least 
> for DHCP) and hence I do accept hacks more likely than with a 
> PIDF-LO enhancement.
> 
> The document needs more text at the beginning to explain the 
> use case you have in mind.
> 
> I would understand when you say that you have an AP that is 
> configured with civic or geodetic location information (both 
> seems to be reasonable to me) and then you put information in

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Nov 2007 16:02:03 +0100

Hi Marc,

> Assumption: Relative location includes defining a reference point followed
Yep.

> current civic location object?
It also has to work with the existing civic location elements. They 
should be sufficient to describe a place.
If there are further needs to add civic tokens then that's fine with me 
as well. I would like to treat it a bit separately though.

> point as geo, can you provide real-world applications?

I don't see a specific reason to stick with civic information. Why 
should a reference location always be civic?

> location recipients to receive relative location information?
When you sent me your relative location information with something like 
(copy-and-paste from the draft):

   <REFPT>elevator-1</REFPT> 

   <RELPOS-X>-20</RELPOS-X> 

   <RELPOS-Y>-31</RELPOS-Y> 

Then, this wouldn't tell me anything.

In comparison, look at Section 4 of 
http://www.tschofenig.priv.at/svn/draft-linsner-geopriv-relativeloc/draft-linsner-geopriv-relativeloc-02.txt

I hope my response helps.

Ciao
Hannes

>>> 2) Please explain what is 'quite misleading' wrt the 
>>>       
>> intention of the draft?
>>     
>>>   
>>>       
>>>>>> In a wireless environment location determination 
>>>>>>             
>> techniques do not 
>>     
>>>>>> produce civic location.
>>>>>>     
>>>>>>         
>>>>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Nov 2007 16:22:27 +0100

Hi Marc,

> point as geo, can you provide real-world applications?

Consider the question in a different fashion: LLDP-MED allows to 
distribute the location information of an AP. It is able to provide 
civic and geodetic information.

One could argue that the reference location is the location of the AP.

Following your line of argument one could claim that geodetic location 
information in LLDP-MED for the APs location is not a useful deployment 
option. I am not sure about this line of argument. Hence, I believe we 
need both.

Ciao
Hannes

Btw, DHCP-civic has a what field. How would you set it for relative 
location?
- the location of the network element believed to be closest to the 
client (a value of 1), or
- the location of the client (a value of 2)

Is the registration of new value for the 'what' field necessary?

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 28 Nov 2007 10:29:43 -0500

FWIW I do agree that the reference+offset is generally useful and the
reference should be either geo or civic

Brian

> Sent: Wednesday, November 28, 2007 10:22 AM
> To: Marc Linsner
> Cc: [email-masked]
> Subject: [Geopriv] Re: Review of draft-linsner-geopriv-relativeloc-01.txt
> 
> Hi Marc,
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 10:48:49 -0500

Hannes,

In-line.... 

> > descriptions/attributes should not require any additional 
> tags added 
> > to the current civic location object?
> >   
> It also has to work with the existing civic location 
> elements. They should be sufficient to describe a place.
> If there are further needs to add civic tokens then that's 
> fine with me as well. I would like to treat it a bit 
> separately though.

Using the relative location scenario below, please define how you would
describe the reference point using current civic location tags.

Reference point: 123 N. Main St., Anytown, PA, 03030, USA, 3rd floor,
elevator door
Offset: 15 feet south and 10 feet east

Current civic location objects:

country two-letter ISO3166a2 country code (required)
A1	national subdivisions (state, canton, region, province, prefecture) 
A2	county, parish, gun (JP), district (IN)          
A3	city, township, shi (JP)                         
A4	city division, borough, city district, ward, chou (JP)
A5	neighborhood, block
A6	group of streets below the neighborhood level
PRD	leading street direction
POD	Trailing street suffix
STS	Street suffix or type
HNO	House number
HNS	House number suffix
LMK	Landmark or vanity address
LOC	Addition location
NAM	Name (residence and office occupant)
PC	Postal/zip code
BLD	Building (structure)
UNIT	Unit (apartment, suite)
FLR	Floor
ROOM	Room
PLC	Place-type
PCN	Postal community name
POBOX	Post Office Box (P.O. Box)
ADDCODE	Additional code
SEAT	Seat (desk, cubicle, workstation)
RD	Primary road or street
RDSEC	Road Section
RDBR	Road Branch
RDSUBBR	Road Sub-Branch
PRM	Road pre-modifier
POM	Road post-modifier

-Marc-

---

From: [email-masked]
Date: Wed, 28 Nov 2007 11:15:23 -0500 (EST)

Same here.

Carl

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 11:19:58 -0500

Hannes, 

I asked for examples of real-world applications that have deployed relative
location using a geo description of the reference point.  In my small world,
only having exposure to applications of relative location that describe the
reference point as civic, I'm trying to understand.

Why you are attempting to turn this into a general geo vs. civic debate?  I
thought you already agreed to providing reference points utilizing civic
descriptions?

more in-line....

> 
> > 2) In order to better understand the use case for expressing the 
> > reference point as geo, can you provide real-world applications?
> >   
> 
> Consider the question in a different fashion: LLDP-MED allows 
> to distribute the location information of an AP. It is able 
> to provide civic and geodetic information.
> 

The actual reference location chosen for use by the implementer is of no
concern to the IETF.  FYI, the reference point does not have to be the
location of a network entity.

-Marc-

> 
> Following your line of argument one could claim that geodetic 
> location information in LLDP-MED for the APs location is not 
> a useful deployment option. I am not sure about this line of 
> argument. Hence, I believe we need both.
>

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 28 Nov 2007 17:24:46 +0100

Hi Marc, 

> thought you already agreed to providing reference points 

I hope I am not trying todo that. 
I wonder why you restrict the functionality of the reference location to
civic location. 
I don't see a reason todo this given that we have both civic and
geodetic everywhere else as well. 

> location of a network entity.
To me these assumptions need to be spelled-out in the document since
they imply  
operational considerations. 

Ciao
Hannes

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 11:27:07 -0500

Brian,

I'm trying to figure out if geo reference + offset is actually in use or
deployed applications have gone with simply doing the math and provide the
actual location in geo.  With a reference point described using geo, it's
pretty easy to figure out the geo coordinates of the offset.

Do you know?

-Marc-

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 10:30 AM
> To: 'Hannes Tschofenig'; 'Marc Linsner'
> Cc: [email-masked]
> Subject: RE: [Geopriv] Re: Review of 
> draft-linsner-geopriv-relativeloc-01.txt
> 
> FWIW I do agree that the reference+offset is generally useful 
> and the reference should be either geo or civic
> 
> Brian
> 
> > reference
> > information in LLDP-MED for the APs location is not a useful 
> > deployment option. I am not sure about this line of 
> argument. Hence, I 
> > believe we need both.
> > 
> > Ciao
> > Hannes
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 28 Nov 2007 11:30:21 -0500

You can provide a very high quality reference point and a relatively low
quality offset.  It's very useful to know that detail.  

I don't personally know of a specific implementation that uses a geo
reference.  It seems pretty obvious to me that it's useful.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2007 11:27 AM
> To: 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: [Geopriv] Re: Review of draft-linsner-geopriv-relativeloc-
> 01.txt
> 
> Brian,
>

---

From: "Stuard, Doug" <[email-masked]>
Date: Wed, 28 Nov 2007 11:33:30 -0500

Consider a wireless emergency caller who tells the PSAP call taker:
"There's a fire about 400 meters east of me.  The caller has no idea of
his location, but the wireless system provides it to the PSAP as a geo.

Doug

> Subject: RE: [Geopriv] Re: Review of
draft-linsner-geopriv-relativeloc-
> > > Is the registration of new value for the 'what' field necessary?

------------------------------------------------------------------------------------------------
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: John Schnizlein <[email-masked]>
Date: Wed, 28 Nov 2007 11:38:30 -0500

Why do you assume that the location provided by LLDP-MED is that of  
an Access Point?  AFAIK the location provided by LLDP-MED is whatever  
the LAN administrator assigned to that particular switch port - most  
reasonably the location of the jack in office space - not the  
location of some network infrastructure.

Of course, one could argue almost anything in a hypothetical sense,  
but we should not lose sight of how things are designed to work.

John

On Nov 28, 2007, at 10:22 AM, Hannes Tschofenig wrote:
> ...

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 11:41:35 -0500

Doug, 

I don't understand your proposal.  The offset would be delivered to the PSAP
via the bearer channel, not pidf-lo.

-Marc-

> "There's a fire about 400 meters east of me.  The caller has 
> no idea of his location, but the wireless system provides it 
> to the PSAP as a geo.
> 
> Doug
> 
> 
> > I'm trying to figure out if geo reference + offset is 
> actually in use 
> > or deployed applications have gone with simply doing the math and 
> > provide the actual location in geo.  With a reference point 
> described 
> > using geo, it's pretty easy to figure out the geo 
> coordinates of the 
> > offset.
> > 
> > Do you know?
> > 
> > -Marc-
> > 
> > 
> > 
> > > FWIW I do agree that the reference+offset is generally useful and 
> > > the reference should be either geo or civic
> > >
> > > Brian
> > >

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Nov 2007 17:48:28 +0100

Hi Marc,

> Reference point: 123 N. Main St., Anytown, PA, 03030, USA, 3rd floor,

This is one of the problems with the entire draft. As I commented in my 
review July this year:
http://www1.ietf.org/mail-archive/web/geopriv/current/msg03851.html

You seem to have a different usage scenario in mind than I have. I 
wouldn't not have a reference location that cannot be expressed with the 
current civic tokens. If that would be the case then I would write a 
draft that defines these new civic tokens totally independently of 
relative locations. In this case the draft would be pretty short and 
would just contain the REFPT field although I would rename (see my 
argument below).

I have the feeling that we are getting closer to the core of the 
misunderstanding. Examples obviously seem to help.

Your example in the draft is a "code snippet" and did not describe the 
reference location as the one indicated above. Instead, it just said 
"elevator-1".
For a location recipient it is different to receive a civic location 
that says "elevator-1" compared to one that says  "123 N. Main St., 
Anytown, PA, 03030, USA, 3rd floor, elevator-1". The assumed usage is 
obviously different. Since you call the REFPT field "Reference Point" it 
creates a lot of confusion since this is only one part of the reference 
point of the entire "123 N. Main St., Anytown, PA, 03030, USA, 3rd 
floor, elevator-1" address.

With respect to this issue you are essentially suggesting to add a 
freetext field to the civic location tokens. That seems to be a good idea.

Leaving the field of DHCP encoding I wouldn't even encode the direction 
using civic tokens. Instead, I would just use the GML functionality that 
is available.

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 28 Nov 2007 17:51:14 +0100

That's how I understood Manfred's presentation:
http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EswAgenda2007

He indicated that there is work ongoing to distribute the location of the Target in addition to the location of the network device. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext John Schnizlein [mailto:[email-masked]] 
> Gesendet: Mittwoch, 28. November 2007 17:38
> An: Hannes Tschofenig
> Cc: [email-masked]; Marc Linsner
> Betreff: Re: [Geopriv] Re: Review of

---

From: "Stuard, Doug" <[email-masked]>
Date: Wed, 28 Nov 2007 12:07:48 -0500

Marc,

My bad.  Perhaps a better example would be where a location of the
target were determined via optical ranging (as might be the case in
surveying), which would be distance and direction from a geodetic
reference point.  This would then be in the PIDF-LO.

Doug

> Sent: Wednesday, November 28, 2007 11:42 AM
> To: Stuard, Doug
> Cc: [email-masked]
> 01.txt
> 
> Doug,
> 
> I don't understand your proposal.  The offset would be delivered to
the
> PSAP
and
> > > > > - the location of the network element believed to be closest
to
> > the

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 12:19:51 -0500

Doug,

Great!  Can you provide contacts/companies in this space that are interested
in using pidf-lo?  I'll try to reach out to gather their application
requirements.

Thanks!

-Marc-

> 
> Marc,
> 
> My bad.  Perhaps a better example would be where a location 
> of the target were determined via optical ranging (as might 
> be the case in surveying), which would be distance and 
> direction from a geodetic reference point.  This would then 
> be in the PIDF-LO.
> 
> Doug
> 
> 
> > > "There's a fire about 400 meters east of me.  The caller 
> has no idea 
> > > of his location, but the wireless system provides it to 
> the PSAP as 
> > > a geo.
> > >
> > > Doug
> > >
> > >
> > > 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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Nov 2007 18:43:38 +0100

Hi Marc,

you seem to believe that geodetic location information as a reference 
point is academic.
In a mail on the resolution vs. uncertainty I essentially asked the 
question:
How is DHCP-geo used today? The background of my question was to learn 
more about location determination techniques and their relationship to 
the information information in DHCP.

Unfortunately, I haven't seen the responses to that question. Is it 
possible that our entire discussion is a bit academic?

Ciao
Hannes

Marc Linsner wrote:
>>>> Consider a wireless emergency caller who tells the PSAP 
>>>>         
>> call taker:
>>     
>>>>> or deployed applications have gone with simply doing 
>>>>>           
>> the math and 
>>     
>>>>>>>> 2) In order to better understand the use case for
>>>>>>>>                 
>>>> expressing the
>>>>         
>>>>>>> reference
>>>>>>>               
>>>>>>> Consider the question in a different fashion: LLDP-MED
>>>>>>>               
>>>> allows to
>>>>         
>>>>>>> distribute the location information of an AP. It is able to
>>>>>>>               
>>>> provide
>>>>         
>>>>>>> One could argue that the reference location is the location
>>>>>>>               
>>>>>> of the AP.
>>>>>>             
>>>>>>> Following your line of argument one could claim that
>>>>>>>               
>>>>>> geodetic location
>>>>>>             
>>>>>>> information in LLDP-MED for the APs location is not 
>>>>>>>               
>> a useful 
>>     
>>>>>> argument. Hence, I
>>>>>>> believe we need both.
>>>>>>> Btw, DHCP-civic has a what field. How would you set it for
>>>>>>>               
>>>> relative
>>>>         
>>>>>>> location?
>>>>>>> Is the registration of new value for the 'what' field
>>>>>>>               
>>> necessary?
>>>       
>>>>>>>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 28 Nov 2007 13:10:27 -0500

Hannes,
 
> 
> You seem to have a different usage scenario in mind than I 
> have.

Please expand on your usage scenario.

FYI, as I tried to establish in the draft, there are WLAN systems
implemented producing the data I've described.

 I wouldn't not have a reference location that cannot be 
> expressed with the current civic tokens. 

Disregarding your double negative, having a tag embedded in the civic object
that provides clear meaning for it's intended use seems better (to me) than
attempting to utilize a more generic tag that means something different in
other contexts.  Agree?

If that would be the 
> case then I would write a draft that defines these new civic 
> tokens totally independently of relative locations. In this 
> case the draft would be pretty short and would just contain 
> the REFPT field although I would rename (see my argument below).
> 
> I have the feeling that we are getting closer to the core of 
> the misunderstanding. Examples obviously seem to help.
> 
> Your example in the draft is a "code snippet" and did not 
> describe the reference location as the one indicated above.

Sorry, I attempted a short cut in the draft and it caused you pain.  I
thought it was clear the proposed tags were additional to the existing civic
object.  

> Instead, it just said "elevator-1".
> For a location recipient it is different to receive a civic 
> location that says "elevator-1" compared to one that says  
> "123 N. Main St., Anytown, PA, 03030, USA, 3rd floor, 
> elevator-1". The assumed usage is obviously different. Since 
> you call the REFPT field "Reference Point" it creates a lot 
> of confusion since this is only one part of the reference 
> point of the entire "123 N. Main St., Anytown, PA, 03030, 
> USA, 3rd floor, elevator-1" address.
> 
> With respect to this issue you are essentially suggesting to 
> add a freetext field to the civic location tokens. That seems 
> to be a good idea.

Glad you agree.

One major difference we need to hammer out.  You are proposing that relative
location be a completely new location type, a third one in addition to the
existing geo and civic.  You claim this will provide better
interoperability.

If we add the refpt and relpos-? tags to civic as I propose:

1) Location targets/recipients that do NOT understand relative location,
meaning they don't understand the refpt and relpos-? tags, will still be
able to utilize the remaining tags included in the civic object.  Hence, no
harm, no foul.

2) If in fact there is a completely new location type, as you propose, and
this new relative location type is the only one available to a host that
doesn't understand relative location, location discovery/conveyance does not
happen.

Conclusion: IMO, adding the proposed tags to the existing document is better
than creating a new document.

> 
> Leaving the field of DHCP encoding I wouldn't even encode the 
> direction using civic tokens. Instead, I would just use the 
> GML functionality that is available.

I have never suggested encoding direction anywhere.

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Nov 2007 15:39:47 -0600

I have a few major concerns with this draft.

The first is that the relative offset fields are part of a civic address.  These are not civic fields - it seems that the civic format is only used because it is convenient.  Convenience is not a good technical reason to use those fields.

The second is similar to what others have expressed.  A relative location applies to both civic and geodetic locations.  This follows from the first - the offset should be specified separately.

In addition, there is no formal way to describe a specific point using a civic address.  A civic address describes a region of uncertainty at all levels, except where informal fields like "LOC" are used.  This makes establishing a reference point difficult.  i.e. Given a building name, which point within the extents of the building is the actual location.  Keep in mind that informal fields are extremely difficult to interpret programmatically.

Finally, consideration needs to be made to how relative location can be controlled with policy.  In particular, the obfuscation method requires extra thought - obscuring the reference location could invalidate the location entirely, but only obscuring the offset could still reveal too much information via the reference location (for instance, if the reference was an AP location, this reveals the means by which the location was derived and places certain bounds on the result).

My minor considerations are more numerous, but these need to be addressed first.

I have some thoughts on how to resolve these problems using geodetic forms.  However, I think that we should focus on PIDF-LO before updating the DHCP formats.

Cheers,
Martin

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Nov 2007 23:14:54 -0500

I agree with Marc that treating relative location as a refinement of  
existing (civic) location data makes more sense than creating another  
format. That both geo and civic happen to be able to use relative  
references seems of secondary importance to the user. They primarily  
care whether the base format and measurement origin is civic or geo.  
Adding another two formats just seems to complicate query protocols  
and the number of possibilities. This doesn't preclude re-using tags  
and conventions across both civic and geo formats.

This is in line with the roughly hierarchical nature of civic location  
elements, where higher-level elements can be useful even if a lower- 
level element is ignored. This naturally assumes that one doesn't  
specify something silly like

352.382 km NE of 123 Main Street

(I'm only commenting on this design decision, not on any other aspects  
of the draft or its presentation.)

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Nov 2007 22:28:12 -0600

I disagree, if this is a coordinate based position it more sensibly fits within a geodetic object.  All you need to do is create a new CRS, which can be as informal as you like, providing that everyone understands what it means:

<location-info>
<civicAddress xml:id="base"><country>US</country></civicAddress>
<Point srsName="urn:ietf:some:civic:based:location+ne" newns:base="base">
  <pos>352382</pos>
</Point>
</location-info>

Carl has been saying this for a while.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 29 November 2007 3:15 PM
> To: Marc Linsner
> Cc: [email-masked]
> Subject: Re: [Geopriv] RE: Review of draft-linsner-geopriv-relativeloc-
> 01.txt
> 
> >
>

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 29 Nov 2007 14:47:12 -0500

Martin,
 
In-line.....
> 
> The first is that the relative offset fields are part of a 
> civic address.  These are not civic fields - it seems that 
> the civic format is only used because it is convenient.  
> Convenience is not a good technical reason to use those fields.

The design is attempting to meet the end-user application.  End-users
expect/utilize the hierarchy of the data within the civic location object.
Currently, there is no mechanism to allow inclusion of WLAN location
information.  This is simply allowing an application to express a more
granular civic location, parallel to other information such as ROOM, SEAT,
etc.

Would you feel more comfortable if the tags were WLANRP/WLANOFFX/WLANOFFY?

> 
> The second is similar to what others have expressed.  A 
> relative location applies to both civic and geodetic 
> locations.  This follows from the first - the offset should 
> be specified separately.

I'm agnostic wrt geodetic relative location as I don't understand the
application.

> 
> In addition, there is no formal way to describe a specific 
> point using a civic address.  A civic address describes a 
> region of uncertainty at all levels, except where informal 
> fields like "LOC" are used.  This makes establishing a 
> reference point difficult.  i.e. Given a building name, which 
> point within the extents of the building is the actual 
> location.  Keep in mind that informal fields are extremely 
> difficult to interpret programmatically.

Apparently, the end-users are very happy with the 'region of uncertainty'
associated with civic location.  I don't believe this is the venue to debate
whether this application fits end-user needs.

Since the data proposed is only of local significance, any misinterpretation
is self-inflicted and only of local significance.  Regardless, the remaining
information in the civic object is still pertinent/useful.

> 
> Finally, consideration needs to be made to how relative 
> location can be controlled with policy.  In particular, the 
> obfuscation method requires extra thought - obscuring the 
> reference location could invalidate the location entirely, 
> but only obscuring the offset could still reveal too much 
> information via the reference location (for instance, if the 
> reference was an AP location, this reveals the means by which 
> the location was derived and places certain bounds on the result).

I don't understand how this applies to the proposal.  Adding location tags
to an accepted GeoPriv document does not conflict with either the GeoPriv
charter or RFC3693/4.  Policy applies to the handling of object, not the
individual tags.

-Marc-

> I have some thoughts on how to resolve these problems using 
> geodetic forms.  However, I think that we should focus on 
> PIDF-LO before updating the DHCP formats.
> 
> Cheers,
> Martin
>