Subject: Re: [Geopriv] New 3825 'bis'

From: <[email-masked]>
Date: Tue, 20 Jan 2009 08:20:09 +0100

Hi Martin,

I very much support to change the encoding from RFC3825 to the encoding you propose in this document. Doing it quickly would be very helpful as other SDOs (eg IEEE) re-use the encoding and those SDOs are reluctant changing it unless they see IETF doing it first.

I am however, against deprecating altitude type 2. It is true that this type is meaningful only in relation to a building, but that;s where humans spend most of their time. Floor selection is essential in positioning inside buildings, as floorplans of different floors of the same building may be different. If you deprecate it, then the client would require, in addition to this option, also the civic address option and only the floor number from there, extract the floor number, and then position the user using the geocoordinates. It makes no sense to remove ALT=2 from this document.

The encoding could be defined in a standalone document, instead of binding it to dhcp. It that way the other SDOs would not need to take out the encoding from the dhcp option and replicate it in their standard, but instead reference the RFC. If we do that the encoding could include azimouth info as well.

Regards,
- gabor

  >-----Original Message-----
  >From: [email-masked] [mailto:[email-masked]] On
  >Behalf Of ext Thomson, Martin
  >Sent: Sunday, January 18, 2009 2:37 PM
  >To: GEOPRIV
  >Subject: [Geopriv] New 3825 'bis'
  >
  >Hi All,
  >
  >I've submitted a new version of draft-thomson-geopriv-3825bis.  Just so
  >there are no misunderstandings I am not doing this to start fires.  The
  >document stands as a position on the debate and I didn't want it to
  >expire.  Until the group has a good compromise, which I hope is soon,
  >I'll maintain this document.
  >
  >Besides, the old version had a bug in the DHCPv6 option that needed
  >correcting.
  >
  >Cheers,
  >Martin
  >
  ><http://tools.ietf.org/html/draft-thomson-geopriv-3825bis>
  >
  >-------------------------------------------------------------------------
  >-----------------------
  >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]
  >_______________________________________________
  >Geopriv mailing list
  >[email-masked]
  >https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Jan 2009 11:32:02 +0200

Hi Gabor, 
Hi Martin, 

working with Klaus Darilion I have recently implemented the DHCP geo
encoding and it is not fun. 

If someone changes the semantic of the values (and adds new fields) then
I would suggest to make some more improvements, namely
* make sure that the values in there have some reasonable alignment
(byte-alignment at least)
* long, lat, and alt are represented as double datatype. This requires a
few more bits but it far simpler from an implementation point of view
(encoding and decoding). If you don't believe me then just try to
implement RFC 3825. 

Given that a decision has been made about this work a long time ago
already and that there was essentially no progress so far (depite
several working group members expressing a strong desire to fix it) I
suggest to get this thing finally going. 

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext 
>[email-masked]
>Sent: 20 January, 2009 09:20
>To: [email-masked]; [email-masked]
>Subject: Re: [Geopriv] New 3825 'bis'
>
>
>Hi Martin,
>
>I very much support to change the encoding from RFC3825 to the 
>encoding you propose in this document. Doing it quickly would 
>be very helpful as other SDOs (eg IEEE) re-use the encoding 
>and those SDOs are reluctant changing it unless they see IETF 
>doing it first.
>
>I am however, against deprecating altitude type 2. It is true 
>that this type is meaningful only in relation to a building, 
>but that;s where humans spend most of their time. Floor 
>selection is essential in positioning inside buildings, as 
>floorplans of different floors of the same building may be 
>different. If you deprecate it, then the client would require, 
>in addition to this option, also the civic address option and 
>only the floor number from there, extract the floor number, 
>and then position the user using the geocoordinates. It makes 
>no sense to remove ALT=2 from this document.
>
>The encoding could be defined in a standalone document, 
>instead of binding it to dhcp. It that way the other SDOs 
>would not need to take out the encoding from the dhcp option 
>and replicate it in their standard, but instead reference the 
>RFC. If we do that the encoding could include azimouth info as well.
>
>Regards,
>- gabor
>
>
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 20 Jan 2009 10:06:30 -0500

I have recently spent more time than I would have thought possible on the
subject of floors.

Here are some issues:

The biggest is numbering.  There are lots of ways to number floors in a
database
a) start at the lowest possible floor, and go up sequentially
b) start at 1 on the "ground" floor, go up and down from there
c) use whatever is on the signage/elevator
d) start at 1 where the responders enter, go up and down from there

The actual way it's used is d: the incident commander designates a side of a
building, and the entrance there is floor 1.

The worst possible way is c, but that's what most people think it ought to
be.  The problem is that the signage may not be visible to responders
a) is often quite hard, because it's not clear what a floor is with some
buildings (half level sub-basements, non uniform basement depth, ...
b) is impossible, because in many buildings, there is no real "ground
floor", or its different on different entrances

Of course you don't know in advance what d) is.

There is also the conversion problem: how do you convert real altitude to
floors?
Note that if you have a building plan, you can convert to something
(although you have the numbering problem).  

There's more, but that gives you the flavor of the problems.

Brian

> Behalf Of [email-masked]
> Sent: Tuesday, January 20, 2009 2:20 AM
> I very much support to change the encoding from RFC3825 to the encoding
> you propose in this document. Doing it quickly would be very helpful as
> other SDOs (eg IEEE) re-use the encoding and those SDOs are reluctant
> changing it unless they see IETF doing it first.
> 
> I am however, against deprecating altitude type 2. It is true that this
> type is meaningful only in relation to a building, but that;s where
> humans spend most of their time. Floor selection is essential in
> positioning inside buildings, as floorplans of different floors of the
> same building may be different. If you deprecate it, then the client
> would require, in addition to this option, also the civic address
> option and only the floor number from there, extract the floor number,
> and then position the user using the geocoordinates. It makes no sense
> to remove ALT=2 from this document.
> 
> The encoding could be defined in a standalone document, instead of
> binding it to dhcp. It that way the other SDOs would not need to take
> out the encoding from the dhcp option and replicate it in their
> standard, but instead reference the RFC. If we do that the encoding
> could include azimouth info as well.
> 
> Regards,
> - gabor
> 
> 
> 
>

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 20 Jan 2009 09:13:24 -0600

Just to add a bit of spice to the selection, should you consider
basement, sub-basement, etc (-1, -2?)

Marc B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Tuesday, January 20, 2009 9:07 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] New 3825 'bis'

I have recently spent more time than I would have thought possible on
the
subject of floors.

Here are some issues:

The actual way it's used is d: the incident commander designates a side
of a
building, and the entrance there is floor 1.

The worst possible way is c, but that's what most people think it ought
to

There is also the conversion problem: how do you convert real altitude
to
floors?
Note that if you have a building plan, you can convert to something
(although you have the numbering problem).  

Brian

> I very much support to change the encoding from RFC3825 to the
encoding
>   >I've submitted a new version of draft-thomson-geopriv-3825bis.
Just
> so

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Jan 2009 09:49:21 -0600

>building, and the entrance there is floor 1.

Perhaps in the US, but most frequently I've noticed, in Europe, is 
the ground floor (i.e., the entrance of the building) is marked on 
the elevator as floor 0 (i.e., zero).

This muddles both b, c and d - which is bad, and confusing 
(especially when there is a floor 0 as the ground floor, and then a 
floor 1 as the 2nd floor - which is counted as floor 2 even though it 
is marked floor 1 (and so on up the building).  Then there is the 
issue of most buildings that have a 13th floor, but no marked 13th 
floor (for superstition reasons) ...

Option a isn't so good either due to the sheer number of sub-floors 
that some buildings have and others do not.

Compounding this is whether or not to include parking sub-floors and 
actual floors, or whether non-parking floors are to be considered the 
actually start of floors to be counted (i.e., floor 1 in this context).

Then there are the buildings that have sub-floors between floor 1 and 
floor 2. 3825 deals with this in coding, but it isn't as clear for responders.

>Of course you don't know in advance what d) is.

the bigger problem is for buildings, such as those in San Francisco, 
that have entry points on different floors - depending on which side 
of the building you enter (because of the hills within the city mean 
the building was built where on one side of the building has a fairly 
formal entry 1 or 2 floors above or below the formal entry on the 
other side of the building). This is common downtown at the larger 
hotels - which is exactly the kind of building we're attempting to 
address here.

>There is also the conversion problem: how do you convert real altitude to

There is no uniform way to do this - given that floor heights are 
different for pretty much every building.  What about convention 
centers or stadiums that have wildly different designs with greatly 
varying floor heights?

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Jan 2009 09:52:26 -0600

>basement, sub-basement, etc (-1, -2?)

RFC 3825 already does this. In fact, it allows for the breakdown of 
sub-floors (above or below ground) as x.99, .... x.2, x.1, floor 1, 
-x.1, -x.2 ...-x.99

floor 0 is possible too in this progression above

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Jan 2009 16:09:22 -0600

I have one proposal that should help: use RFC 4776, CAType 27.  You can use "G", "Mezzanine", "Basement" or whatever is least ambiguous, because it's just text.  Now this isn't a problem for the geodetic representation.

I can't agree with Brian's emergency-centric viewpoint.  Problems with labelling might briefly confuse responders in occasions where the occupant/designer of the building has used a non-intuitive labelling scheme, but the alternative is just as bad for all the other use cases.  Any confusion with the first can be addressed by use of a fairly simple procedure, or by better labelling.  Not that this discussion really makes much difference - people will make up their own minds about what is "best" and use that.

As for Hannes' viewpoint, I can't help but sympathise with the plight of implementers.  Octet alignment helps a great deal.  However, one of the aims of my proposal was to keep binary compatibility and most of the semantic compatibility with what is already in place.  If a complete overhaul was decided upon, I'm certain that it would look very different indeed.

M
 
> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 21 January 2009 2:52 AM
> To: Marc Berryman; Brian Rosen; [email-masked]; Thomson, Martin;
> [email-masked]
> > > you propose in this document. Doing it quickly would be very
> helpful
> >as
> > >   >there are no misunderstandings I am not doing this to start
> fires.
> > > The

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

---

From: <[email-masked]>
Date: Wed, 21 Jan 2009 07:44:19 +0100

RFC3825 tells you what the number is intended to mean: " Inside a building, 0.0 represents
   the floor level associated with ground level at the main entrance.
   This document defines a number; one must arrive at the number by
   counting floors from the floor defined to be 0.0."

I do not intend to debate the above text, for me it does not matter what the rfc says it means. I only want a floor number when the (long, lat) point, as determined by the datum, is within the contours of a building. RFC3825 does have this capability, and I'd like that to be preserved in the update, instead of being deprecated.

- gabor

  >From: ext Brian Rosen [mailto:[email-masked]]
  >Sent: Tuesday, January 20, 2009 7:07 AM
  >To: Bajko Gabor (Nokia-CIC/MtView); [email-masked];
  >[email-masked]
  >Subject: RE: [Geopriv] New 3825 'bis'
  >

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Jan 2009 01:48:29 -0600

> c) use whatever is on the signage/elevator

This is the only option that local sysadmins are likely to get right.

In many buildings, especially in the government sector, there are  
classified floors, usually subterranean (but occasionally partway up  
taller buildings). This precludes sysadmins from knowing the actual  
floor count in the building unless they have clearance, and would  
preclude giving an "accurate" floor number to everybody who could read  
DHCP . . .

--
Dean