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

From: "Roger Marshall" <[email-masked]>
Date: Thu, 22 Dec 2005 14:21:32 -0800

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Dec 2005 18:32:16 -0600

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.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 22 Dec 2005 18:52:02 -0600

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

------------------------------------------------------------------------------------------------
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]

---

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

That's right. It's the reason why I reworded your text to read "expected
that", but doesn't say "MUST provision", etc.

Roger.

>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Wednesday, December 28, 2005 11:31 AM
>To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk'
>Cc: [email-masked]
>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
>
>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]
>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.
>
>>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]
>>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.
>>
>>
>>
>>Of Roger Marshall
>>Sent: Tuesday, December 27, 2005 6:38 PM
>>To: Winterbottom, James; James M. Polk
>>Cc: [email-masked]
>>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.
>>
>>
>>
>>
>>>From: Winterbottom, James [mailto:[email-masked]]
>>>Sent: Thursday, December 22, 2005 4:52 PM
>>>To: James M. Polk; Roger Marshall
>>>Cc: [email-masked]
>>>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 
>>>> addressed. I think we ought to consider that any x.y is 
>only as good
>>>as
>>>> So, just as you define latitude and longitude (N/S of 
>equator or E/W
>>>from
>>>> 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
>>>> >...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
>>>> >terminology section the definition of "location" is 2D-limited.
>>>> >
>>>> >(e.g. altitude, floor, etc.) within the mapping protocol,
>>>in addition
>>>to
>>>or feature
>>>> >based on a specific coordinate system, or by other precise 
>>>> >information such as a street number and name (and 
>possibly, floor).
>>>In
>>>This message is for the designated recipient only and may contain 
>>>privileged, proprietary, or otherwise private information.
>>immediately
>>>and delete the original.  Any unauthorized use of this email is 
>>>prohibited.