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

From: creed@opengeospatial.org
Date: Wed Dec 01 2010 - 16:17:21 EST

Very true! I have seen - in different countries - where G, M, 0, or 1 is
the ground floor.

Carl

> 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:17:21 -0500 (EST)

This archive was generated by hypermail 2.1.8 : Wed Dec 01 2010 - 16:17:37 EST