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

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Wed Dec 01 2010 - 10:26:36 EST

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
Received on Wed, 1 Dec 2010 10:26:36 -0500

This archive was generated by hypermail 2.1.8 : Wed Dec 01 2010 - 10:27:12 EST