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=3D7, 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=3D2 (=3D=3Dfloors), 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@=85):
> >>
> >> [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
> >> =3D 1.1. Example: (2) mezzanines =
between floor 4 and floor 5 could be
> >> represented as =
values =3D 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 =3D 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@=85 | Owner: =
bernard_aboba@=85
> >> Type: =
defect | Status: new
> >> Priority: =
major | Milestone: draft-ietf-geopriv-3825bis
> >> =
Component: rfc3825bis | Version: 1.0
> >> Severity: =
Submitted WG Document | Keywords:
> >> =
---------------------------------------+----------------------------------=
--
> >>
> >> Ticket =
URL: <
h=
ttps://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.or=
g/mailman/listinfo/geopriv> >
> > =
_______________________________________________
> > Geopriv =
mailing list
> >
Geopriv@ietf.org> >
https://www.ietf.or=
g/mailman/listinfo/geopriv>
> =
_______________________________________________
> Geopriv mailing =
list
>
Geopriv@ietf.org>
https://www.ietf.or=
g/mailman/listinfo/geopriv