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

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 21:09:39 -0500

At 11:37 AM 7/15/2005 +1000, James Winterbottom wrote:

>To clarify a comment from James's recent email, floor is currently defined 
>as a string in the PIDF-LO draft, so 2.2 etc is okay.

I know that all elements are considered strings, but the spirit or essence 
of what civic will provide (and something Henning has stated repeatedly) is 
that geo (and 3825) doesn't provide the "mezzanine" name or attribute, 
therefore it is less desireable.

With that said (repeated), a <FLR/> element of 2.2 defeats the advantage 
sought by civic in this context.

The civic ID does have a place for the word "mezzanine", but we cannot 
calculate or compute or assume the first subfloor between the 1st and 2nd 
floor is the "mezzanine", and the second subfloor is the "entresol" - so 
floor 2.2 is just that, it's floor 2.2; and neither geo or civic has an 
advantage over the other.

However, floor names do change, and unless the build falls down, the number 
of floors doesn't - so the 3825 definition of the counting of floors seems 
the more precise (if that matters here).

>-----Original Message-----
>From: Henning Schulzrinne 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Friday, 15 July 2005 11:27 AM
>To: Winterbottom, James [WOLL:5500:EXCH]
>Cc: James M. Polk; Marc Linsner; 'GEOPRIV'
>Subject: Re: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-l 
>o -profile-00
>
>James Winterbottom wrote:

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 22:22:50 -0400

James M. Polk wrote:

> However, floor names do change, and unless the build falls down, the 
> number of floors doesn't - so the 3825 definition of the counting of 
> floors seems the more precise (if that matters here).

I'm not sure what "precise" means here. Also, floors do get added on 
occasion.

I don't think this is a discussion that is going to get us very far. 
Some people believe that recipients prefer room locations measured in 
geo and in fractional floors, others have their doubts as to the 
practicality of that. Experience will tell and the discussion seems to 
be of interest only to about 4-5 people.

I'd like to avoid needless complexity for the presumably common case 
that both exist and would rather avoid the "mine is better" arguments in 
making decisions on routability. Both need some degree of specificity to 
be routable, down to house numbers for civic and probably at least 100' 
anywhere on the globe for geo (whatever that translates to in terms of 
bits).

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 22:31:40 -0500

Henning

I wasn't claiming "mine is better", I was just defending 3825 as suitable, 
when more than one seemed to claim it was not.

I agree we need consensus on what level of precision for each format needs 
to be present to satisfy certain functions (like routing to a PSAP). That 
seems like a meaningful discussion - and hopefully a more peaceful one  ;-)

At 10:22 PM 7/14/2005 -0400, Henning Schulzrinne wrote:
>I'm not sure what "precise" means here. Also, floors do get added on occasion.
>
>I don't think this is a discussion that is going to get us very far. Some 
>people believe that recipients prefer room locations measured in geo and 
>in fractional floors, others have their doubts as to the practicality of 
>that. Experience will tell and the discussion seems to be of interest only 
>to about 4-5 people.
>
>I'd like to avoid needless complexity for the presumably common case that 
>both exist and would rather avoid the "mine is better" arguments in making 
>decisions on routability. Both need some degree of specificity to be 
>routable, down to house numbers for civic and probably at least 100' 
>anywhere on the globe for geo (whatever that translates to in terms of bits).
>
>Henning

cheers,
James

                                 *******************

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Jul 2005 08:05:32 -0400

James M. Polk wrote:
> Henning
> 
> I wasn't claiming "mine is better", I was just defending 3825 as 
> suitable, when more than one seemed to claim it was not.

The other James was.

> 
> I agree we need consensus on what level of precision for each format 
> needs to be present to satisfy certain functions (like routing to a 
> PSAP). That seems like a meaningful discussion - and hopefully a more 
> peaceful one  ;-)

Since the PIDF-LO data may be used for functions other than PSAP 
routing, this might actually belong in an ECRIT document, but I don't 
much care either way.

For geo, the problem is that different jurisdictions have different 
requirements for accuracy, e.g., the FCC rules for wireless devices that 
speak of probabilities for different accuracy levels. Since 
jurisdictional boundaries for PSAPs are typically aligned on property 
lines, i.e., individual residences, for residential or commercial use, 
you could have a 1 foot error put you erroneously in the wrong county 
and PSAP. I don't think this matters in practice, but it indicates that 
picking a number will be rather difficult. I suspect that in almost all 
cases, people will simply provide whatever accuracy they can get from 
their GPS or other location device and set the bit count to "max", 
regardless of whether this is actually true or not. (Converting the 
circular accuracy estimates you get from your GPS unit to the units used 
in 3825 requires a bit of spherical geometry calculations that I don't 
see your average local wiremap maintainer performing.)

Henning

---

From: Brian Rosen <[email-masked]>
Date: Fri, 15 Jul 2005 09:00:52 -0400

Two thingo:

There are many uses for location information.  Some of them require 
calculations, and some of them require human interaction.  For the 
latter, you always need a representation a human can deal with. 
Specifically, ifthe floor is labeled some way, you need to know that. 
The example is that you are given a location that is floor 22. You go in 
an elevator and press 22.  If you arrive, all the markings say floor 
22.

Now, if your pidf has floor 22, I think you want that to be the same 
floor, even if the building does not have a floor 13, which is often the 
case.

What you do with a geo with mu=floors?

The other issue is getting both a civic and a geo in a pidf.  If you 
have both, you have converted one from the other. It must be possible to 
determine which was the original, and which was derived from it.

If you route, specifically for emergency calls,you must route on the 
original.

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Jul 2005 09:14:24 -0400

Hang on.....

> 
> For geo, the problem is that different jurisdictions have 
> different requirements for accuracy, e.g., the FCC rules for 
> wireless devices that speak of probabilities for different 
> accuracy levels. Since jurisdictional boundaries for PSAPs 
> are typically aligned on property lines, i.e., individual 
> residences, for residential or commercial use, you could have 
> a 1 foot error put you erroneously in the wrong county and 
> PSAP. I don't think this matters in practice, but it 
> indicates that picking a number will be rather difficult. I 
> suspect that in almost all cases, people will simply provide 
> whatever accuracy they can get from their GPS or other 
> location device and set the bit count to "max", regardless of 
> whether this is actually true or not. (Converting the 
> circular accuracy estimates you get from your GPS unit to the 
> units used in 3825 requires a bit of spherical geometry 
> calculations that I don't see your average local wiremap 
> maintainer performing.)

I accept the fact that RFC-3825 obviously fails in expressing this
adequately, my bad.

HEAR YE, HEAR YE:

RFC-3825 is not intended to convey the accuracy anomalies associated with
the measuring geo coordinates.  Nor, is RFC-3825, in it's current state,
intended to convey 'bounding boxes' typically associated with geo
triangulation measuring techniques.

Rationale: As stated in RFC-3825, although subtly:

"The goal of this option is to enable a wired Ethernet host to obtain its
location,"

It is/was assumed by the authors of RFC-3825 that operators of multi-story
structures *may* have at their disposable geo information that is more
accurate than a 2 second fix from a consumer grade gps standing outside of
their respective structure (although a 20 second fix is pretty good, and
well within *most* location use cases, with today's technology).  IF such
geo information is available, maybe from the surveyor/engineer associated
with the building, this data *should* not include accuracy components.  (If
you hire a surveyor that supplies you with an accuracy component, disregard
the data and hire another one! (Hmm, I think your property line is here and
I think your building is there!))

"This resolution sub-field accommodates the desire to easily adjust the
precision of a reported location."

The intended resolution sub-field purpose:

1) The ability to convey the data more accurately - The data I have does not
match the resolution the LO is capable of conveying (don't believe the
lower-order bits).

2) To satisfy the privacy requirements within GeoPriv during the RFC-3825
timeframe (the ability to 'hide').

I hope this helps in further understanding use cases for RFC-3825.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Jul 2005 09:19:39 -0400

In-line.... 

> There are many uses for location information.  Some of them 
> require calculations, and some of them require human 
> interaction.  For the latter, you always need a 
> representation a human can deal with. 
> The example is that you are given a location that is floor 
> 22. You go in an elevator and press 22.  If you arrive, all 
> the markings say floor 22.
> 
> Now, if your pidf has floor 22, I think you want that to be 
> the same floor, even if the building does not have a floor 
> 13, which is often the case.
> 

Is this the $100 question on millionaire?

In this example, the value you might consider populating in the alt field
may be the binary equivalent of decimal 22.

What am I missing?

-Marc-

---

From: Tom Taylor <[email-masked]>
Date: Fri, 15 Jul 2005 10:21:58 -0400

See below, marked with [PTT]

Brian Rosen wrote:
> an elevator and press 22.  If you arrive, all the markings say floor 22.
> 
[PTT] Good point -- this needs to be specified.
> If you route, specifically for emergency calls,you must route on the 
[PTT] The assumption of conversiuon has been implicit in a number of 
your postings.  I don't think it's necessarily true.  DHCP (to take an 
example) could have information from different sources.  Of course, the 
problem then is to decide which source is more reliable if they disagree.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 15 Jul 2005 10:39:55 -0400

Because 3825 counts floors; there would be a 13th floor.

I think this is hard to deal with.  It's precise, but impossible to use 
without more data, for which we don't have a practical way to provide.

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Jul 2005 11:47:00 -0400

RFC3825 provides a mechanism to convey a binary alt value that can represent
a floor.  Since there is no RFC police, it would seem that building
engineers and operators *may* implement the mechanism in 3825 to best match
their local situation.  There may be a case where the ground floor may be 0
and the 22nd floor (missing floor label 13) may well be 22.  I can't imagine
the IETF or anyone else claiming 'your building is out of 3825 compliance'
with this approach.  Ascii floor labels were examined in length during the
3825 process and deemed insigificant wrt the overall intent of the
architecture.  A larger requirement was to maintain a small compact object.

It was never the intent of 3825 to influence the engineering of building
floors and labels as conveyed with, "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."

If in fact, you get your desires, and the receiver of the data derived from
the 3825 object actually has a modern GIS system, why can't the 3825 data
simply be used as a db key to lookup the 'human-useful' data?  And as a side
benefit, in the interim, the 3825 LO does convey more data than is available
in the majority of the records of the current ALI system.

-Marc-

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Friday, July 15, 2005 10:40 AM
> To: Marc Linsner; James M. Polk; James Winterbottom; Henning 
> Schulzrinne
> Cc: GEOPRIV
> Subject: Re: AW: [Geopriv] 
> Quickrandomcommentsondraft-ietf-geopriv-pdif-l o-profile-00
> 
> I think this is hard to deal with.  It's precise, but 
> impossible to use without more data, for which we don't have 
> a practical way to provide.
> 
> Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Jul 2005 23:04:26 -0400

> determine which was the original, and which was derived from it.

Not necessarily. Civic might have been derived by looking at the floor 
plan and the door signs; geo by some technician schlepping an indoor GPS 
unit from room to room. They are essentially both original data, each 
with their own set of potential reliability issues (measurement errors, 
transcription problems, disagreements between door label and floor plan, 
etc.).

Henning