Subject: RE: [Ecrit] Issue 22: 3D of location

From: "Roger Marshall" <[email-masked]>
Date: Wed, 28 Dec 2005 11:20:18 -0800

Brian:
I like the ideas you've conveyed below.  I've included some replacement
text below, in which I've tried to capture your thoughts:

Change FROM:
"Lo-x.  3D Location:  The third dimension of a location MAY be 
included (e.g. altitude, floor, etc.) within the mapping protocol, in 
addition to its base (two dimensional geographic, or civic 
street-type) location information."

Change TO:
"Lo-x.  3D Sensitive Mapping:  The mapping protocol MUST accept 
either a 2D or 3D mapping request, and return an appropriate 
result, based on which type of input is used."

"Motivation:  It is expected that provisioning systems will accept 
both 2D and 3D data. When a 3D request is presented to an area 
only defined by 2D data, the mapping result would be the same as 
if the height/altitude dimension was omitted on the request."

Roger Marshall.

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Wednesday, December 28, 2005 7:06 AM
>To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk'
>Cc: [email-masked]
>Subject: RE: [Ecrit] Issue 22: 3D of location
>
>Saying "may be included" is not sufficient.  The behavior of 
>the protocol has to be defined to be 3D (that is, you may get 
>a different mapping with one "height" value, than you do with 
>another), and the protocol has to define what happens if you 
>omit the 3rd dimension on a query.
>
>So:
>The mapping protocol must be defined to be a 3D sensitive mapping.  
>
>The protocol must accept a 2D or 3D mapping request and return 
>a reasonable result when only 2 dimensions are presented.
>
>The protocol provisioning systems must accept both 2D and 3D 
>data.  When a 3D request is presented to an area only defined 
>by 2D data, the mapping result shall be the same as if the 
>height/altitude dimension was omitted on the request. 
>
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Roger Marshall
>Sent: Tuesday, December 27, 2005 6:38 PM
>To: Winterbottom, James; James M. Polk
>Cc: [email-masked]
>Subject: RE: [Ecrit] Issue 22: 3D of location
>
>James (W): 
>Indeed we have a requirement for WG84, and it reads: 
>
>"Lo3.  Reference Datum: The mapping server MUST understand 
>WGS-84 coordinate reference system and may understand other 
>reference systems."
>
>Making reference to WGS-84 alone doesn't imply 3D to the 
>implementer of the mapping protocol.  Proof of that is today's 
>current wireless, which refers to surveyed points as wgs-84, 
>but almost never includes the third coordinate in a resultant 
>position set.  What is not explicity mentioned already in the 
>req. draft is the language that states that sending 3-D is OK 
>(as is sending 2-D without having the third dimension).  In 
>order to say that each form is acceptable (2D or 3D for either 
>civic or geo, despite which CRS used), I have suggested the 
>added requirement: 
>
>"Lo-x.  3D Location:  The third dimension of a location MAY be 
>included (e.g. altitude, floor, etc.) within the mapping protocol, in
>
>addition to its base (two dimensional geographic, or civic 
>street-type) location information."
>
>Comments, anyone?
>
>Roger Marshall.
>
>
>
>
>>-----Original Message-----
>>From: Winterbottom, James [mailto:[email-masked]]
>>Sent: Thursday, December 22, 2005 4:52 PM
>>To: James M. Polk; Roger Marshall
>>Cc: [email-masked]
>>Subject: RE: [Ecrit] Issue 22: 3D of location
>>
>>I was under the impression that WGS-84 had already been agreed to as 
>>the MUST be supported CRS. This includes what an altitude is. To my 
>>understanding there is no way to express what you are talking about 
>>below in a civic representation, so I am wondering how you plan to 
>>express it in the forms that we currently have.
>>
>>Cheers
>>James
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>On Behalf
>>Of
>>> James M. Polk
>>> Sent: Friday, 23 December 2005 11:32 AM
>>> To: Roger Marshall
>>> Cc: [email-masked]
>>> Subject: RE: [Ecrit] Issue 22: 3D of location
>>> 
>>> Roger
>>> 
>>> I'm glad you brought this up. I agree that the altitude dimension
>>should
>>> be
>>> addressed. I think we ought to consider that any x.y is only as good
>>as
>>> it's datum.  I think this applies to the z coordinate as well.
>>> 
>>> So, just as you define latitude and longitude (N/S of equator or E/W
>>from
>>> prime meridian), we might want to state Altitude is above or below
>>what is
>>> considered zero altitude, knowing this may be different in many 
>>> situations.
>>> 
>>> There's:
>>> 
>>> - mean sea level
>>> - mean low tide
>>> - mean lowest low tide
>>> - mean high tide
>>> - pressure altitude (flight level)
>>> - absolute altitude (above a ground reference point)
>>> - true altitude (above mean sea level - which doesn't really work
>>inland)
>>> 
>>> I don't mean to make this complicated, but we can say that
>>altitude is
>>> above or below some "known reference", be it the ground, or 
>mean sea 
>>> level, or whatever.
>>> 
>>> I also agree that this ought to be a "...MAY be included..." - which
>>means
>>> a recipient must be prepared to receive this information,
>>even if not
>>> acting on it.
>>> 
>>> 
>>> At 02:21 PM 12/22/2005 -0800, Roger Marshall wrote:
>>> >Issue 22: Missing requirement for 3D in location.
>>> >
>>> >Rohan added this point to the tracker, based on the last IETF mtg.
>>> >
>>> >...from the issue tracker: 
>http://www.ietf-ecrit.org:8080/ecrit-req/
>>> >
>>> >22. Author: rohan Date: 2005-11-07.22:21:27 Sometimes 2D location 
>>> >information is insufficient to send help (for example, ina large 
>>> >office building).  Where provided in civic or geo formats,
>>there
>>> >is a
>>> >requirement to get 3D information in some locations.  Also in the 
>>> >terminology section the definition of "location" is 2D-limited.
>>> >
>>> >Rohan brings up a valid point, so consider the following suggested
>>text,
>>> >in order to try to satisfy the proposed requirement:
>>> >
>>> >
>>> >NEW REQUIREMENT:
>>> >Lo-x.  3D Location: The third dimension of a location MAY
>>be included
>>> >(e.g. altitude, floor, etc.) within the mapping protocol,
>>in addition
>>to
>>> >its base (two dimensional georaphic, or civic street-type) 
>location 
>>> >information.
>>> >
>>> >Motivation: This may be helpful for emergency responders when an 
>>> >emergency request is made from an upper floor, tower, or
>>subterranean
>>> >position.
>>> >
>>> >
>>> >If everyone likes this, then we should also change the definition
>>> >(slightly) in the case of the term, location, in order to
>>include 3D
>>> >examples (as is shown in the text below):
>>> >
>>> >location: A geographic identification assigned to a region
>>or feature
>>> >based on a specific coordinate system, or by other precise 
>>> >information such as a street number and name (and possibly, floor).
>>In
>>> >the geocoding process, the location is defined with an x,y (and 
>>> >potentially, z) coordinate value according to the distance 
>north or 
>>> >south of the equator and east or west of the prime meridian.
>>> >
>>> >
>>> >Please comment if objectionable.
>>> >
>>> >Roger Marshall.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >_______________________________________________
>>> >Ecrit mailing list
>>> >[email-masked]
>>> >https://www1.ietf.org/mailman/listinfo/ecrit
>>> 
>>> _______________________________________________
>>> Ecrit mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>
>>---------------------------------------------------------------
>>---------------------------------
>>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]
>>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 28 Dec 2005 14:31:12 -0500

Well, generally I don't like the motivation defining requirements
(provisioning system accepts both 2D and 3D), but it's okay.  Certainly,
anyone reading it will understand the intent completely, and that is what
matters.

Brian

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Wednesday, December 28, 2005 2:20 PM
To: [email-masked]; Winterbottom, James; James M. Polk
Cc: [email-masked]
Subject: RE: [Ecrit] Issue 22: 3D of location

Brian:

Change FROM:

Change TO:

Roger Marshall.