|
|
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:br@xxxxxxxxxxxxxx]
>Sent: Wednesday, December 28, 2005 7:06 AM
>To: Roger Marshall; 'Winterbottom, James'; 'James M. Polk'
>Cc: ecrit@xxxxxxxx
>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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx]
>On Behalf Of Roger Marshall
>Sent: Tuesday, December 27, 2005 6:38 PM
>To: Winterbottom, James; James M. Polk
>Cc: ecrit@xxxxxxxx
>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:James.Winterbottom@xxxxxxxxxx]
>>Sent: Thursday, December 22, 2005 4:52 PM
>>To: James M. Polk; Roger Marshall
>>Cc: ecrit@xxxxxxxx
>>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: ecrit-bounces@xxxxxxxx [mailto:ecrit-bounces@xxxxxxxx]
>>On Behalf
>>Of
>>> James M. Polk
>>> Sent: Friday, 23 December 2005 11:32 AM
>>> To: Roger Marshall
>>> Cc: ecrit@xxxxxxxx
>>> 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
>>> >Ecrit@xxxxxxxx
>>> >https://www1.ietf.org/mailman/listinfo/ecrit
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@xxxxxxxx
>>> 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
>Ecrit@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ecrit
>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|