Subject: AW: [Geopriv] Quick random comments ondraft-ietf-geopriv-pdif-lo-profile-00

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 5 Jul 2005 23:34:28 +0200

hi henning, 

thanks for the quick comments. 
please see a few responses inline:

> This draft is very helpful and timely. A set of quick comments:
> 
thanks. 

> I don't see the point of allowing or recommending a variety 
> of position 
> representations. This just adds interoperability testing 
> hassles without 
> adding any value. Thus, why use (from the example)
> 
> <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
> 
> at all if this is then called inappropriate and deprecated a 
> section or 
> two later?

that's true. we should fix the examples. 

> 
> On a more general level, I'm also doubtful about the wisdom of having 
> partial civic (country and floor). I have a hard time 
> picturing a real 
> scenario where you would just have these two elements as 
> opposed to both 
> full civic (including city and street) and maybe geo. This 
> offers much 
> more value to recipients and avoids having to deal with 
> various strange 
> incomplete civic address objects. If floor and country is ok, why not 
> have people send street number and directional only (125 S), just for 
> the entertainment value :-)?

a motivating example would certainly help. 

one example is the currently specified dhcp-geo where floor is combined
with geospatial location info. 

ideally, i would like to avoid these representations. however, james
might have better examples. 

> 
> "If only a coverage area is required
>     without a nominal central point requiring specification, then this
>     form is ideal for representation using GML."
> 
> Reference of "this" is unclear.

true. needs to be fixed. 

> 
> In general, standards are about making choices. Thus, having a very 
> simple set of recommended ways to doing each thing, with alternatives 
> relegated to an appendix, will, in my opinion, avoid the needless 
> complexity that we have incurred by using GML without 
> sufficient detail. 
> Other approaches (like Jabber) avoid this complexity 
> altogether and we 
> should strive to make GEOPRIV-based systems as easy to deploy 
> and test.

i have seen the jabber location document and i fully agree with you that
we should be as simple as possible. 

> 
> Also, there are a few references to "emergency services" or 
> "emergency 
> routing" (not a clear term, btw). I don't think any of these 
> recommendations would change if we were to use PIDF-LO to give 
> directions to the local pizza parlor or the AAA tow truck. 
> Thus, unless 
> something truly technically depends on emergency services, I would 
> remove the qualifiers, as this just leaves open the question what all 
> the other uses of PIDF-LO should do to allow some minimal 
> interoperability.

we will remove these statements. 

> 
> In short, the draft could be 20 pages shorter if it focused on 
> recommendations, rather than exploring all alternatives. Putting the 
> second-best alternatives in an appendix will at least avoid confusing 
> implementors that only look at examples.

i also hope to shorten it although i think it might be good to have more
examples. 

ciao
hannes

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Jul 2005 20:06:34 -0400

> with geospatial location info. 

Given that we have very limited deployments (to put it generously) of 
either civic or geo options, another path forward to consider: Deprecate 
the use of floors in the geo DHCP option and don't carry it in PIDF-LO 
unless it is part of the full civic option. Logically, floors were 
always a bad fit for the geo option, but necessary until we had others.

The geo floor option has known problems (cannot represent certain 
floors) and I can't picture a scenario where the floor (and geo) is 
known, but the street address isn't. Having to merge floor and country 
information from geo and civic just adds complexity and error cases, for 
no increase in functionality.

> we should be as simple as possible. 

We really only four things to create a deployable system:

(1) How to represent a simple geo coordinate pair + altitude (however 
derived, whether by GPS or DHCP) in PIDF-LO/GML.

(2) Add the missing civic elements to PIDF-LO.

(3) Describe uncertainty in exactly one way.

(4) Deal with the combination of civic + geo (and rule out various other 
combinations of geo + geo, civic + civic, etc).

> i also hope to shorten it although i think it might be good to have more

I agree that examples are a very good thing.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Jul 2005 20:10:36 -0400

Another comment: It might be worth pointing out that the 
draft-ietf-simple-future extension does make it possible and sensible to 
have multiple locations in the same PIDF, namely as <timed-status> 
objects, indicating either past or future locations.

Longer term, it might also be useful to allow embedding PIDF-LO objects 
elsewhere, e.g., in CIPID-like objects for longer-term addresses. 
(Example: Some folks I met at a NENA event were very interested in 
having billing addresses available for callers, as that apparently 
greatly helps debugging should something go wrong. They obviously need 
to be marked as such to avoid them being used for call routing or other 
inappropriate purposes.)

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Jul 2005 16:59:26 -0400

Henning,

> 
> Given that we have very limited deployments (to put it 
> generously) of either civic or geo options, another path 
> forward to consider: Deprecate the use of floors in the geo 
> DHCP option and don't carry it in PIDF-LO unless it is part 
> of the full civic option. Logically, floors were always a bad 
> fit for the geo option, but necessary until we had others.
> 
> floors) and I can't picture a scenario where the floor (and 
> geo) is known, but the street address isn't. Having to merge 
> floor and country information from geo and civic just adds 
> complexity and error cases, for no increase in functionality.
> 

I can't agree with 'Deprecate the use of floors in the geo DHCP option and
don't carry it in PIDF-LO unless it is part of the full civic option.'

With all the extraeous baggage associated with supporting civic addresses,
why would you want to force the operator of a multistory building to support
only civic???

Geo is simply easier/cheaper to support.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 12 Jul 2005 17:55:59 -0400

I don't understand this question.

First of all, it is far easier to use civic in a multistory building -- 35th
floor, suite 3510, Room 25 (or cubicle 25-6).  Certainly, until we get
accurate floor plans, accurately aligned to GPS coordinates, we would
strongly prefer civic.

Secondly, if you do have a way to measure accurate lat/lon inside a
multistory building, you could get accurate altitude.

For the foreseeable future, if your device measures lat/lon, by all means
send that.  If not, please send civic.  Never convert.  If you know you are
on the 35th floor, in Suite 3510, Room 25, and you are looking at some sort
of map that would tell you what the lat/lon is, you are converting.  Don't
do that.  If you have a WiFi mechanism that is triangulating, and the only
reasonable output is lat/lon, please make darn sure your base station
location is accurate, and send geo.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner
Sent: Tuesday, July 12, 2005 4:59 PM
To: 'Henning Schulzrinne'; 'Tschofenig, Hannes'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv] Quick
randomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

Henning,

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Jul 2005 19:37:53 -0400

In-line... 

> I don't understand this question.

Civic has all the problems, plus associated costs ($$), that we've been
discussing for over 2 years. Ambiguity. Geo is not ambiguous.

> 
> First of all, it is far easier to use civic in a multistory 
> building -- 35th floor, suite 3510, Room 25 (or cubicle 
> 25-6).

As long as I state it in your format, then verify that your format doesn't
change at some frequency prescribed by you.  Hence, my statement that civic
has baggage associated with it.

 Certainly, until we get accurate floor plans, 
> accurately aligned to GPS coordinates, we would strongly prefer civic.
> 
> Secondly, if you do have a way to measure accurate lat/lon 
> inside a multistory building, you could get accurate altitude.

Not necessarily.  Besides, take your GIS system and tell me what floor
equates to 83.4 meters?

-Marc-

> 
> For the foreseeable future, if your device measures lat/lon, 
> by all means send that.  If not, please send civic.  Never 
> convert.  If you know you are on the 35th floor, in Suite 
> 3510, Room 25, and you are looking at some sort of map that 
> would tell you what the lat/lon is, you are converting.  
> Don't do that. If you have a WiFi mechanism that is 
> triangulating, and the only reasonable output is lat/lon, 
> please make darn sure your base station location is accurate, 
> and send geo.
> 
> Brian
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Linsner
> > generously) of either civic or geo options, another path forward to 
> > consider: Deprecate the use of floors in the geo DHCP 
> option and don't 
> > carry it in PIDF-LO unless it is part of the full civic option. 
> > Logically, floors were always a bad fit for the geo option, but 
> > necessary until we had others.
> > 
> > geo) is known, but the street address isn't. Having to 
> merge floor and 
> > country information from geo and civic just adds complexity 
> and error 
> > cases, for no increase in functionality.
> > 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Jul 2005 21:43:10 -0400

> discussing for over 2 years. Ambiguity. Geo is not ambiguous.

For this discussion, we should just have a list of standard arguments 
pro and con, so we can abbreviate the discussion. 42! No, 87!

I am curious, however, how geo can be cheaper for in-building locations 
in DHCP or elsewhere, given that most people and administrators have a 
pretty good idea what street address, building name and floor they get 
mail at or have the FedEx guy go to, but seem to have considerably more 
difficulty knowing that they might live at 40.85790 N, 73.98857 W.

I have no objection to providing geo where available; I fail, however, 
to see why in any practical case, providing geo and complete civic for 
cases where floors matter (office buildings, apartment buildings) would 
pose any hardship or incremental cost.

I agree that a geo location would probably work better for places like 
http://img.slate.msn.com/media/1/123125/2068716/2112810/2122381/2122405/5-A-survivor-of-the-Apple-2.jpg

(see http://slate.msn.com/id/2122382/slideshow/2122433/entry/2122413/)

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jul 2005 08:36:49 -0400

Maybe I've been asleep.

I don't know about any costs associated with civic addresses.
I know about costs associated with maintaining things like wiremap tables
that figure out where a wall jack is when you change a patch cord.

I go back a refrain:
	If you have some device that MEASURES location, use it (that's geo)
	If you are having someone type in location, use civic

Ambiguity is not something we have discussed much with regard to civic
location.  There are the issues of "numbering" (how the authorities assign
addresses), that, if you don't follow the rules, leads to ambiguity.  I get
that.  There is history (multiple streets with the same name in a city). 
So, yes, civic has ambiguity.  This has been solved (mostly by some sort of
unambiguous code, like a postal code), but there is some cost to it.
We have addressed these issues with the civic location formats we have
chosen.  If you use them, you should not have ambiguity.  I'll agree that
geo does not have ambiguity.

The problem is, how do you get that geo?  If you measure it, then we can
talk about measurement accuracy.  If you convert, then we have to talk about
the quality of the database you used to convert.  Generally, I think it's a
bad idea to convert (or at least, if you do convert, send the original also
so that the recipient can ignore your conversion).

A GIS system that can tell you where you are in a building can tell you what
floor you are on given altitude.  It would have to have the interior
building plans, and that would include vertical planes.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2005 7:38 PM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv]
Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

In-line... 

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jul 2005 10:54:09 -0400

> geo does not have ambiguity.

In practice, there is ambiguity both in the measurement and the definition.

If you provide a point (or a point with some circle or other geometric 
construct of accuracy around it), it is not always clear what civic 
artifact this refers to. A point at the center of gravity of my property 
may well be closer to the entrance door or driveway of my neighbor or, 
in all likelihood, be behind my house (which probably means that a 
geo-driven ambulance would arrive at the next street and the ambulance 
driver would have to climb my backyard fence). You'd have to have strong 
and universally followed conventions ("measure intersection of driveway 
and public street") to avoid that.

Also, the useful accuracy of many GPS systems is well within the packing 
density of rowhouses in Queens.

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Jul 2005 11:36:01 -0400

in-line.... 

> If you provide a point (or a point with some circle or other 
> geometric construct of accuracy around it), it is not always 
> clear what civic artifact this refers to. A point at the 
> center of gravity of my property may well be closer to the 
> entrance door or driveway of my neighbor or, in all 
> likelihood, be behind my house (which probably means that a 
> geo-driven ambulance would arrive at the next street and the 
> ambulance driver would have to climb my backyard fence). 
> You'd have to have strong and universally followed 
> conventions ("measure intersection of driveway and public 
> street") to avoid that.

15642 Country Rd. is the address for farmer John.  This location value also
describes the 600 acres behind farmer John's house where he happens to be
immobilized due to a chainsaw accident.

15642 Country Rd. = 26,136,000 sq. ft. where John is located.

41.4567 N x 86.5678 W = 3 sq. ft. where John is located.

If I were John, I would want my 802 phone to report geo when I pried it out
of my shirt pocket and dialed 9-1-1.

> 
> Also, the useful accuracy of many GPS systems is well within 
> the packing density of rowhouses in Queens.

The accuracy of civic locations also goes down when these 25 houses within a
city block have no numbers on them.

Conclusion:  This is all out-of-scope for GeoPriv!  My ambiguity argument is
simply describing a use case for lat/long/alt mu=floor in an attempt to stop
the deprecation of such.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Jul 2005 13:46:54 -0400

in-line....

> I am curious, however, how geo can be cheaper for in-building 
> locations in DHCP or elsewhere, given that most people and 
> administrators have a pretty good idea what street address, 
> building name and floor they get mail at or have the FedEx 
> guy go to, but seem to have considerably more difficulty 
> knowing that they might live at 40.85790 N, 73.98857 W.

'Most people' are apparently geo-deprived.

> 
> I have no objection to providing geo where available; I fail, 
> however, to see why in any practical case, providing geo and 
> complete civic for cases where floors matter (office 
> buildings, apartment buildings) would pose any hardship or 
> incremental cost.

MSAG has no cost?

-Marc-

> http://img.slate.msn.com/media/1/123125/2068716/2112810/212238
> 1/2122405/5-A-survivor-of-the-Apple-2.jpg
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jul 2005 14:03:59 -0400

>> buildings, apartment buildings) would pose any hardship or

It is not clear to me that MSAG is a long-term viable solution to  
anything. (Ask Brian to give you his sermon on this topic; he'll give  
you a much better spiel than I can.) There are likely to be better  
ones, already paid for (hint: contact your local postal authority).  
Since addressing letters and packages to geo coordinates is still a  
ways off, the cost of that database has already been paid, so the  
incremental cost is close to zero.

Secondly, it is naive to believe that geo does not require  
validation. Given how easy it is to screw up random-looking numbers,  
you need validation for geo to make sure that the coordinates that  
look precise to the tenth digit actually represent what you wanted to  
represent.

You might ask the Canadian soldiers that got bombed by friendly (US)  
forces about the problem of mistaken geo coordinates (that is, the  
ones still around to be  asked).

Henning