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

From: "Roger Marshall" <[email-masked]>
Date: Tue, 27 Dec 2005 15:37:32 -0800

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 28 Dec 2005 10:05:32 -0500

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): 

Comments, anyone?

Roger Marshall.