Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Jul 2005 18:23:33 -0400

> 
> However, altitude expressed in floors within a geo is an idea 
> whose time will never come.
> 

I disagree, but if this is the case, why deprecate?

-Marc- 

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

---

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

In-line.... 

> 
> A) I take issue with your argument.  I do not think it is 
> possible to obtain a geo with a floor measurement except by 
> conversion from a civic or some mashing of a civic and a geo; 
> no device would measure such a thing.  You can compute 
> accurate altitude reasonably easily; just do that.  I don't 
> like conversion, but if you do it, do it with an accurate 
> conversion, and get accurate altitude.

You seem to be implying that entering the floor number with a geo record is
bad thing.  Please explain.

> 
> Knowing that I am at 32 23 12N 12 27 15W has few uses unless 
> I had access to/knowledge of the surveyor/engineering plans 
> for the structure and an accurate internal floor plan.  Add 
> altitude and nothing changes.

So, you believe that current ALI records are better than this?  Lat/long/alt
with mu=floor is better than the majority of MLTS ALI records in use today!

> 
> B) 1)Agree that maintaining civic databases (which is an 
> ecrit, not a geopriv issue) has costs.  Maintaining a GIS 
> with accurate floor plans and surveyor accurate structure 
> locations, all correlated, has more costs.  I like the idea 
> that we get to the latter, but we have the former, and 
> maintaining it for a while seems like a no brainer compared 
> to creating the latter.
> 
> 2) Agree that civic needs precision to be unambiguous.  Agree 
> that validation databases are a necessary evil until we have 
> GIS systems that have parcel, altitude and floor plans.  
> Again, we have the civic databases, we don't have the GIS 
> systems.  Unless you want to wait until we do, give up now.
> 
> 3) I'll accept the argument that geopriv needs to support 
> both geo and civic.  The argument here is whether geo needs 
> to support floors.  Henning, and I, say no, it doesn't.

I count at least 3 that say geo needs floors.  Give up?
 
> 
> 4) Agree that precision is part of a geo spec.  Uncertainty, 
> as you know, is a more complex issue, for which simple bits 
> of precision is inadequate.  Yet another problem with geo.

You seem to confuse problems with measuring geo with the geo grid system in
general.  Stop doing that.
  
> I'm not an expert, so me offering solutions is probably pointless.

-Marc-

> 
> 5) Agree geopriv doesn't care if you have a GIS
> 
> Conclusion: Geopriv has to handle civic and geo in all use 
> cases.  Choice of formats is up to the use case, and not up 
> to geopriv.  Arguing one is better than the other is pointless.  
> 
> Brian
> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, July 13, 2005 10:10 AM
> To: 'Brian Rosen'
> Cc: 'GEOPRIV'
> Subject: RE: AW: [Geopriv]
> Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00
> 
> Brian,
> 
> We are talking two different issues.
> 
> A) This thread started with Henning wanting to 'deprecate' 
> the use of the floor measurement unit in the proposed 
> standard RFC-3825.  My argument against this is the use case 
> of a multistory building operator wanting to express location 
> in lat/long/alt.  The very reason for the floor measurement 
> unit in RFC-3825 is to solve the issue of floor number to 
> altitude value.
> Armed with this information, in it's raw form, one *could* 
> find the quadrant/floor of a structure (better than most ALI 
> records today!).
> Knowing that I am 54.2 meters above datum has no correlation 
> to what the floor number is in a building unless you have 
> access to/knowledge of the surveyor/engineering plans for the 
> particular structure.
> 
> I can only guess that Henning's motive for wanting to 
> deprecate the floor MU is due to being too close for too long 
> to the 'civic is the only thing we understand' argument 
> coming from the public safety sector.  I believe this public 
> safety mantra will change as more of them take a closer look 
> at 'the dark side' - geo.
> 
> B) Now, for your argument.
> 
> 1) Supporting all the various MSAG, USPS, municipal, etc. 
> civic databases cost money.  Operating a 'validation' service 
> costs money.  They cost the end-user money directly due to 
> having to support the validation process.
> They cost the end-user money indirectly due to having to 
> support 'someone'
> maintaining the various databases.  You would be hard pressed 
> to convince me this is free even in/on Mars! ;^)  Would this 
> money be better spent converting to geo?
> 
> 2) Why do we need #1???  Because civic is ambiguous (ST vs. 
> STREET; N. Main vs. Main).  Geo is not ambiguous.
> 
> 3) Your mantra of never geo-coding is, IMO, out-of-scope for 
> GeoPriv.  This WG has never been dealing with, nor should 
> they, how you arrive at the value you're expressing in the 
> location object.  RFC-3825 was never intended to deal with 
> this subject.  RFC-3825 assumes that you know the numbers.  
> The binary (bit-length) indicator of precision defined in 
> RFC-3825 was for that sole purpose, indicate the length of 
> believable bits of the value expressed.
> Some have attempted to interpret the precision mechanism as a 
> way to convey the dilution of precision expressed by 
> current-technology geo measurement equipment.  This is not 
> the intention, nor does the RFC-3825 mechanism provide an 
> adequate way to express such.  As stated in the RFC, this was 
> never meant to support mobile/wireless devices (and 
> ever-changing location values/DOP).  Again, RFC-3825 assumes 
> you know the numbers.
> 
> 4) If we need a LO to transmit DOP, then state the use case 
> and design it!
> 
> 5) The protocols that GeoPriv assembles, cannot take into 
> account whether the receiver of the LO has a poor, good, or 
> excellent GIS' interpreting the data.  Not a GeoPriv problem!
> 
> My mantra is based on the fact that geo is not ambiguous, 
> works globally, and the values expressed are small and easy 
> to pack into communications protocols.  As experienced in 
> this WG's efforts, civic has huge problems within national 
> jurisdictions, and even bigger internationally.
> 
> Conclusion: Geo is an excellent way to communicate location 
> values from machine to machine.  If a human cannot interpret 
> geo values, buy a GIS software package.  Welcome to the 20th century!
> 
> If anything *needs* deprecated, it's the use of civic!
> 
> -Marc-
> 
>  
> 
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Wednesday, July 13, 2005 8:37 AM
> > To: 'Marc Linsner'
> > Cc: 'GEOPRIV'
> > Subject: RE: AW: [Geopriv]
> > Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00
> > 
> > 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... 
> > 
> > 
> > > 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
> > > 
> > > -----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,
> > > 
> > > > 
> > > > 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.
> > > > 
> > > 
> > > 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: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jul 2005 18:52:05 -0400

Let's get away from the deprecate discussion. A more productive 
discussion for the pidf-lo profile is to tell people what to do. My 
suggestion is that people should, for buildings where floor information 
is desired, provide both civic and geo information in DHCP and PIDF-LO, 
and send a LO that includes useful, complete information for both. This 
maximizes utility to the receiver and has no incremental cost.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jul 2005 06:31:59 -0400

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2005 6:47 PM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv]

In-line.... 

You seem to be implying that entering the floor number with a geo record is
bad thing.  Please explain.
<br> Because to do that, you have to convert a real geo, or mash a geo and a
civic; I don't want anyone to do that.  If you have a civic, send it.  If
you have a geo, send it; don't mash one into the other.

So, you believe that current ALI records are better than this?  Lat/long/alt
with mu=floor is better than the majority of MLTS ALI records in use today!
<br>Depends a lot on how you got your geo.  If you measure it outside of the
phone, I suspect that due to how the location is actually determined
(wiremap), you probably lose accuracy, because it's very hard to measure
lat/lon in a building, and you aren't fixing the real problem, which is
changes to the wireplant without changes to the wiremap database.  If the
device actually measures geo, then it's giving you altitude in meters, and
turning that into floors is pointless.  If you converted it from a civic,
you definitely lose accuracy.

I count at least 3 that say geo needs floors.  Give up?
<br> So, I'm stubborn.  I don't think you have thought out how you got the
data, and what you want to do with it.  However, I don't think we need to
officially deprecate it, I just don't think we should propagate or recommend
it. 

You seem to confuse problems with measuring geo with the geo grid system in
general.  Stop doing that.
<br>Measuring has two problems, accuracy and uncertainty.  They are separate
problems, but they are both due to the measurement, and not the grid.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 12:00:38 -0400

> you have a geo, send it; don't mash one into the other.

That's what I've been trying to say: There are two cases for indoor 
multi-story buildings:

- You have civic only --> send that

- You primarily care about geo --> use the DHCP civic option to convey 
building name, floor, etc.; use the geo option to convey 
long/lat/altitude in meters [where available; might be useful for the 
guy on the ladder on the outside of the building]. Use a PIDF-LO that 
contains a *complete* civic and geo record.

This avoids having incomplete data or, worse, a fragment of civic-like 
data (floor) plus a full civic address, also with floor information. 
Good luck if they contradict each other.

You will need this in any event since you can't encode floor 
designations like 'mezzanine', 'penthouse', 'subbasement' or 'garage' in 
RFC 3825. Those are the designations that the fireman will find in the 
elevator of the hotel that's on fire...

Henning

---

From: John Schnizlein <[email-masked]>
Date: Thu, 14 Jul 2005 12:44:31 -0400

> Good luck if they contradict each other.

If multiple reports of location differ, the emergency responder might 
just want to know about it.

> designations like 'mezzanine', 'penthouse', 'subbasement' or 'garage' 
> in RFC 3825. Those are the designations that the fireman will find in 
> the elevator of the hotel that's on fire...

Why do you assert that "you can't encode ..." when the RFC says just 
how it is done?

IMHO a fireman might want to know between which floors the mezzanine is.

RFC 3825, page 7:
    This document defines a number; one must arrive at the number by
    counting floors from the floor defined to be 0.0.

    The values represented by this AT will be of local significance.
    Since buildings and floors can vary due to lack of common control,
    the values chosen to represent the characteristics of an individual
    building will be derived and agreed upon by the operator of the
    building and the intended users of the data.  Attempting to
    standardize this type of function is beyond the scope this document.

    Sub-floors can be represented by non-integer values.  Example: a
    mezzanine between floor 1 and floor 2 could be represented as a value
    = 1.1.  Example: (2) mezzanines between floor 4 and floor 5 could be
    represented as values = 4.1 and 4.2 respectively.

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 12:54:37 -0400

> just want to know about it.

They don't add any value - it's just two places with supposedly the same 
information.

> IMHO a fireman might want to know between which floors the mezzanine is.

The numeric representation is essentially meaningless to outsiders. The 
visitor or fireman will have no clue that floor 1.5 means the mezzanine 
- it won't be on any door label, directional sign or elevator button.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 14 Jul 2005 13:16:44 -0400

A fireman would be able to tell that the mezzanine is between floor 1 
and 2 because he would walk up the stairs past floor 1.  When I worked 
on building control and security systems it was made pretty clear that 
firemen don't go to the elevator and look for a button to push.

Even the labeled buttons in the elevator - which the EMT uses to get to 
the heart-attack victim - are usually in a meaningful order even if 
they have named labels.  This is much more useful than a situation 
where the emergency report says "mezzanine" and the buttons in the 
elevator have just labels like "palisade", "colonnade" and "gallery".

John

On Jul 14, 2005, at 12:54 PM, Henning Schulzrinne wrote:
> ...
> The numeric representation is essentially meaningless to outsiders. 
> The visitor or fireman will have no clue that floor 1.5 means the 
> mezzanine - it won't be on any door label, directional sign or 
> elevator button.
>
>
>> RFC 3825, page 7:

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Jul 2005 14:30:29 -0400

I don't agree.

1) It's out of scope for GeoPriv to dictate how location data is derived
(measured, mashed, geocoded, soothsayered, just-plain made-up, etc.).

2) It is GeoPriv's responsibility to design a flexible architecture such
that unknown/little-known/new mechanisms for deriving location data will be
able to be supported within the protocols GeoPriv creates.

3) The discussion of lat/long/alt mu=floors took place over 2 years ago and
was WG/IESG consensus-accepted for RFC-3825.  It appears (may need wg chair
decision here) there is still more support for this mechanism than against.

4) PIDF-LO must support the lat/long/alt mu=floors in it's architecture.

-Marc-

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, July 14, 2005 12:01 PM
> To: Brian Rosen
> Cc: 'Marc Linsner'; 'GEOPRIV'
> Subject: Re: AW: [Geopriv] 
> > <br> Because to do that, you have to convert a real geo, or 
> mash a geo 
> > and a civic; I don't want anyone to do that.  If you have a civic, 
> > send it.  If you have a geo, send it; don't mash one into the other.
> 
> That's what I've been trying to say: There are two cases for 
> indoor multi-story buildings:
> 
> - You primarily care about geo --> use the DHCP civic option 
> to convey building name, floor, etc.; use the geo option to 
> convey long/lat/altitude in meters [where available; might be 
> useful for the guy on the ladder on the outside of the 
> building]. Use a PIDF-LO that contains a *complete* civic and 
> geo record.
> 
> This avoids having incomplete data or, worse, a fragment of 
> civic-like data (floor) plus a full civic address, also with 
> floor information. 
> designations like 'mezzanine', 'penthouse', 'subbasement' or 
> 'garage' in RFC 3825. Those are the designations that the 
> fireman will find in the elevator of the hotel that's on fire...
> 
> Henning

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Jul 2005 15:55:35 -0400

On Jul 14, 2005, at 2:30 PM, Marc Linsner wrote:

> It appears (may need wg chair

A WG chair decision?  But that may end this lovely debate... and this  
working group is behind on its list traffic quota. :)

Seriously, I believe the consensus to be with keeping the floor in  
geo.  But I have to ask one of those chair type questions: what is  
the harm with keeping it in, especially if there is a belief that it  
will never be used?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 16:00:37 -0400

This, unfortunately, isn't the question of interest. I had made a 
concrete proposal, which doesn't involve ditching geo floors at all. It 
simply RECOMMENDs (using 2119 capitalization) that PIDF-LO contain both 
complete geo and civic data, rather than full geo and partial civic.

Andrew Newton wrote:
> geo.  But I have to ask one of those chair type questions: what is  the 
> harm with keeping it in, especially if there is a belief that it  will 
> never be used?
> 
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 14 Jul 2005 16:14:46 -0400

On Jul 14, 2005, at 4:00 PM, Henning Schulzrinne wrote:

> concrete proposal, which doesn't involve ditching geo floors at  
> all. It simply RECOMMENDs (using 2119 capitalization) that PIDF-LO  
> contain both complete geo and civic data, rather than full geo and  
> partial civic.

That certainly seems like a better topic.  But the conversation so  
far does not seem to be about this.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 14 Jul 2005 16:24:44 -0400

> This, unfortunately, isn't the question of interest. I had 
> made a concrete proposal, which doesn't involve ditching geo 
> floors at all. It simply RECOMMENDs (using 2119 
> capitalization) that PIDF-LO contain both complete geo and 
> civic data, rather than full geo and partial civic.

How about PIDF-LO supporting a full geo of lat/long/alt mu=floors?

-Marc-

---

From: John Schnizlein <[email-masked]>
Date: Thu, 14 Jul 2005 17:39:22 -0400

Unfortunately, the "concrete proposal" seems to have an interpretation 
of "full geo and partial civic" attached to one of the altitude types 
defined in RFC 3825.  The authors of RFC 3825 disagree that including 
AT = Floors constitutes "partial civic" when the result is RECOMMENDing 
against its use.  We would not want to sneak this reinterpretation of 
part of RFC 3825 into a decision on the "concrete proposal" phrased to 
obscure it, would we?

The other substantive question in the "concrete proposal" is whether 
the cost of RECOMMENDing both civic and geographic locations is 
justified.  The need to maintain a registry of English (and other 
languages, it seems) words that implementations would have to track 
appears to some of us to be a burden that those who find geographic 
locations useful should not have to bear.

John

On Jul 14, 2005, at 4:00 PM, Henning Schulzrinne wrote:

> concrete proposal, which doesn't involve ditching geo floors at all. 
> It simply RECOMMENDs (using 2119 capitalization) that PIDF-LO contain 
> both complete geo and civic data, rather than full geo and partial 
> civic.
>
> Andrew Newton wrote:

---

From: Greg Troxel <[email-masked]>
Date: 18 Jul 2005 08:24:16 -0400

Many people said "fireman".

If the word is used in the draft, note that the term (in the US, as
preferred by those in the field) is "firefighter".  A fireman tends a
boiler.

-- 
        Greg Troxel <[email-masked]>