Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

From: Bernard Aboba ^lt;bernard_aboba@hotmail.com>
Date: Wed Dec 01 2010 - 19:48:51 EST

Here's the revised text for Section 2.4.3:

2.4.3. Altitude in Floors (AType = 2)

   A value of two for Altitude Type indicates that the Altitude value is
   measured in floors. Since altitude in meters may not be known within
   a building, a floor indication may be more useful. For AType = 2,
   the Altitude value is expressed as a 30 bit, fixed point, twos
   complement integer with 22 integer bits and 8 fractional bits.

   This value is relevant only in relation to a building; the value is
   relative to the ground level of the building. Floors located below
   ground level are represented by negative values. In some buildings
   it might not be clear which floor is at ground level or an
   intermediate floor might be hard to identify as such. Determining
   what floor is at ground level and what constitutes a sub-floor as
   opposed to an naturally numbered floor is left to local
   interpretation.

   Larger values represent floors that are farther away from floor 0
   such that:

      - if positive, the floor value is farther above the ground floor.
      - if negative, the floor value is farther below the ground floor.

   Non-integer values can be used to represent intermediate or sub-
   floors, such as mezzanine levels. Example: a mezzanine between floor
   1 and floor 2 could be represented as a value of 1.25. Example:
   mezzanines between floor 4 and floor 5 could be represented as values
   of 4.5 and 4.75.

> From: Martin.Thomson@andrew.com
> To: br@brianrosen.net; bernard_aboba@hotmail.com
> CC: geopriv@ietf.org
> Date: Thu, 2 Dec 2010 05:47:47 +0800
> Subject: RE: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS
>
> This is all true. It derives from the fact that floor numbering is entirely nominal.
>
> The absence of a floor 13 and presence of mezzanines are just a few of the problems you might encounter. In some buildings, floors aren't numbered at all.
>
> But this doesn't really help the issue at hand. 3825 defined a way to convey floor numbers, ill-conceived or not. We need to decide what to do about that. As with any other aspect of protocol, we can say ground is 0, but we should also highlight the shortcomings of this convention and state that local conventions dictate what is ground.
>
> After all - it's local context that establishes what "ground" is anyway. I've been places where even that concept is fuzzy. It's the coward's way out. The alternative would be to say that altitude in floors is a bad idea, but we've been over that discussion before.
>
> If you need a text-patch for the problem, here's my suggestion.
>
> In some buildings it might not be clear which floor is at ground level
> or an intermediate floor might be hard to identify as such. Determining
> what floor is at ground level and what constitutes a sub-floor as
> opposed to an naturally numbered floor is left to local interpretation.
>
>
> On 2010-12-02 at 05:30:22, Brian Rosen wrote:
> > The only thing that works is to use the local signage convention.
> >
> > If you have a plan, in a standardized form, which we don't, but if you
> > did, then you could use the notation on the plan.
> >
> > Say that and it works.
> >
> > Brian
> >
> > On Dec 1, 2010, at 12:23 PM, Bernard Aboba wrote:
> >
> >
> >
> > Agreed.
> >
> > On the campus where I work, there is a building built into a
> > slope whose back entrance is on one level, and whose front entrance
> > (the
> > one with the receptionist) is on another (higher) floor.
> >
> > In such a building, it's not obvious whether "0" would be used
> > for the back entrance, or "-1", or whether the front entrance would be
> > "0" or "+1".
> >
> > Is there any text we can add that might make this more clear?
> >
> >
> > > From: br@brianrosen.net
> > > Date: Wed, 1 Dec 2010 10:26:36 -0500
> > > To: rbarnes@bbn.com
> > > CC: geopriv@ietf.org; trac@tools.ietf.org
> > > Subject: Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David
> > Harrington's DISCUSS
> > >
> > > Please don't think that by saying "0" is the ground floor that
> > you have made things definitive and interoperable.
> > >
> > > There are plenty of buildings that are constructed into a
> > sloped site, such that it is not at all clear which floor is "ground".
> > >
> > > By having a numbering system that doesn't match anything else
> > (signage, plans, local knowledge, etc), you pretty much guarantee that
> > no one can actually use it.
> > >
> > > I know that fire brigades often designate their main entrance
> > floor 0 or 1, and count (up/down) from there, but they create a
> > reference that everyone understands, and they train their people to use
> > their convention.
> > >
> > > Absent a very detailed plan, and a way to know for sure which
> > floor is "ground", you create a hard to use mechanism that can have
> > ambiguity.
> > >
> > > Brian
> > >
> > >
> > > On Dec 1, 2010, at 12:20 AM, Richard L. Barnes wrote:
> > >
> > > > Actually, while we're on this, there's another contradiction
> > lurking here:
> > > >
> > > > On the one hand, the option definitions say:
> > > > "Altitude: A 30 bit value defined by the AType field."
> > > > One might read this to mean that the AType value can specify
> > the meaning of all the bits in the field. So if I define AType=7, I
> > could say that the the 30 bits contain a 3-character ASCII code
> > describing the color of the carpet on the floor in question (with each
> > character padded to 10 bits, natch). More to the point, for AType=2
> > (==floors), you might split the field into two integers, one signed and
> > one unsigned, that represent "major" and "minor" floor numbers. That
> > way, you could actually directly represent 1.1, 4.1, 4.2.
> > > >
> > > > On the other hand, Section 2.4 defines the Altitude field as
> > 22/8 fixed point regardless of the AType value -- it's only the
> > semantic
> > of this number that changes. This rules out all of the creative
> > encodings described above, at the cost of forcing everything into a
> > 22/8
> > fixed-point mold.
> > > >
> > > > I'll leave it to the author to decide which of these to go
> > with (I don't think it really matters much). If it's the former, then
> > the 22/8 fixed point thing should be moved down into the subsections of
> > 2.4. If the latter, then it should be moved up to the option
> > definitions, as with the Latitude and Longitude fields.
> > > >
> > > > --Richard
> > > >
> > > >
> > > >
> > > > On Nov 30, 2010, at 10:46 PM, geopriv issue tracker wrote:
> > > >
> > > >> #41: David Harrington's DISCUSS
> > > >>
> > > >>
> > > >> Comment(by bernard_aboba@):
> > > >>
> > > >> [James Polk]
> > > >>
> > > >> #41: David Harrington's DISCUSS Comment(by bernard_aboba at
> > ?):
> > > >> Proposed Resolution: In 2.2.1.2, s/same respoonse. This is
> > not useful
> > > >> since/same response, since/ Replace Section 2.4.3 with the
> > following:
> > > >>
> > > >> A value of two for Altitude Type indicates that the
> > Altitude value is
> > > >> measured in floors. This value is relevant only in relation
> > to a
> > > >> building; the value is relative to the ground level of the
> > building.
> > > >>
> > > >> In this definition, numbering starts at ground level, which
> > is floor
> > > >> 0 regardless of local convention. Floors located below
> > ground level
> > > >> could be represented by negative values.
> > > >>
> > > >> I recommend a change to be definitive here with
> > > >> s/could be/are
> > > >>
> > > >>
> > > >> Larger values represent floors
> > > >> that are above (higher in altitude) floors with lower
> > values.
> > > >>
> > > >> This sentence is written in one direction; i.e., up.
> > > >>
> > > >> I recommend
> > > >> "Larger values represent floors that are farther away from
> > floor 0
> > > >> such that -
> > > >>
> > > >> - if positive, the floor value is farther above the ground
> > floor.
> > > >>
> > > >> - if negative, the floor value is farther below the ground
> > floor."
> > > >>
> > > >>
> > > >> Non-integer values can be used to represent intermediate or
> > sub-
> > > >> floors, such as mezzanine levels. 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.
> > > >>
> > > >> I'm fine with the rest as written.
> > > >>
> > > >> James
> > > >>
> > > >> [Bernard Aboba]
> > > >>
> > > >> Here is a revised proposal for the text of Section 2.4.3:
> > > >>
> > > >> 2.4.3. Altitude in Floors (AType = 2)
> > > >>
> > > >> A value of two for Altitude Type indicates that the
> > Altitude value is
> > > >> measured in floors. Since altitude in meters may not be
> > known within
> > > >> a building, a floor indication may be more useful. This
> > value is
> > > >> relevant only in relation to a building; the value is
> > relative to the
> > > >> ground level of the building.
> > > >>
> > > >> Numbering starts at ground level, which is floor 0
> > regardless of
> > > >> local convention. Floors located below ground level are
> > represented
> > > >> by negative values. Larger values represent floors that are
> > farther
> > > >> away from floor 0 such that:
> > > >>
> > > >> - if positive, the floor value is farther above the ground
> > floor.
> > > >> - if negative, the floor value is farther below the ground
> > floor.
> > > >>
> > > >> Non-integer values can be used to represent intermediate or
> > sub-
> > > >> floors, such as mezzanine levels. Example: a mezzanine
> > between floor
> > > >> 1 and floor 2 could be represented as a value of 1.1.
> > Example:
> > > >> mezzanines between floor 4 and floor 5 could be represented
> > as values
> > > >> of 4.1 and 4.2.
> > > >>
> > > >> --
> > > >>
> > ---------------------------------------+-------------------------------
> > -
> > ----
> > > >> Reporter: bernard_aboba@ | Owner: bernard_aboba@
> > > >> Type: defect | Status: new
> > > >> Priority: major | Milestone: draft-ietf-geopriv-3825bis
> > > >> Component: rfc3825bis | Version: 1.0
> > > >> Severity: Submitted WG Document | Keywords:
> > > >>
> > ---------------------------------------+-------------------------------
> > -
> > ----
> > > >>
> > > >> Ticket URL:
> > <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:3>
> > > >> geopriv <http://tools.ietf.org/geopriv/>
> > > >>
> > > >> _______________________________________________
> > > >> Geopriv mailing list
> > > >> Geopriv@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > > >
> > > > _______________________________________________
> > > > Geopriv mailing list
> > > > Geopriv@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www.ietf.org/mailman/listinfo/geopriv
> >
> >
>
>
>
                                               

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 1 Dec 2010 16:48:51 -0800

This archive was generated by hypermail 2.1.8 : Wed Dec 01 2010 - 19:49:15 EST