MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] RE: Notes form last GIS SC meeting
Ahhh, ok. I am following you. Now, I have one question based on what
you both said. And just so there is no confusion, because I know this
email came before another one I sent, I am NOT talking about CAP 1.0 -
I am talking about something to put in CAP 1.NEXT.
Dave, you said in #3 below that this is "what the US military does/is
trying to do - after learning the hard way." Does that mean, in your
opinion, that #3 is better than #2 for CAP 1.NEXT? After reading the
posts that both of you provided, architecturally, it seemed that #2
would represent a more flexible and accurate design, but would take
some extra coding. Extra code that at least seemed like would be worth
it.
Allen
On Mar 23, 2004, at 6:22 PM, David Danko wrote:
> There are three ways of doing this - from the very beginning we've
> followed
> the KISS principle - simple and unambiguous communication.
>
> 1. allow people to use any coordinate reference system and make them
> identify the one they used. The problem is not everyone receiving the
> message will be using a GIS and may not be able to handle that
> particular
> CRS. If they knew ahead of time what CRS will always be used they will
> be
> prepared for it.
>
> Or
> 2. (as Carl mentions below -Recommended XML Encoding of
> CRS Definitions) have the people use whatever they want and include the
> whole description of the CRS - Then there is no miscommunication about
> the
> definition of all the parameters in the CRS, trouble is, half the
> people
> wouldn't know what to do with them.
>
> Or
>
> 3. Make everyone use the same coordinate reference system - so there
> is no
> mis-communication - users would know what to expect, that's what we've
> done
> in this version of CAP. That's what the US military does/is trying to
> do -
> after learning the hard way.
>
>
> Dave
>
>
>
>
>
>
> -----Original Message-----
> From: Carl Reed
> To: R. Allen Wyke
> Cc: emergency TC lists Oasis
> Sent: 3/23/04 11:47 AM
> Subject: Re: [emergency] RE: Notes form last GIS SC meeting
>
> Allen -
>
> The key point is that the GIS SC recommends that the use of WGS 84 is
> fine for CAP 1.0.
>
> Moving forward, it is my personal feeling - and I know that others
> share
> the same feeling - that CAP version 1.x will need to be enhanced to use
> what you termed a coding identifier. One possible route (and the one I
> would favor) would be to use the work of the OGC on Coordinate
> Reference
> Systems (CRS). The OGC CRS abstract and encoding specifications are
> fully grounded in and supplements the ISO TC 211 document ISO 19111:
> Geographic Information - Spatial Referencing by Coordinates. The basic
> premise is that we use a standard "model" for expressing a CRS and that
> this model is "well known".
>
> From the OGC Abstract Model document for CRS:
>
> This part of the OGC Abstract Specification defines the conceptual
> schema for the
> description of spatial referencing by coordinates, optionally extended
> by temporal
> referencing. It describes the minimum data required to define 1-, 2-
> and
> 3-dimensional
> coordinate reference systems with an extension to merged
> spatial-temporal coordinate
> reference systems. It allows additional descriptive information to be
> provided. It also
> describes the information required to change coordinate values from one
> coordinate
> reference system to another. It is applicable to producers and users of
> geographic
> information. Although it is applicable to digital geographic data, its
> principles can be
> extended to many other forms of geographic data such as maps, charts,
> and text
> documents.
>
> So, how is this abstract model actually implemented? The OGC membership
> has approved a recommended normative approach for encoding CRS
> information. This can be found in a document titled
> <http://www.opengis.org/docs/03-010r9.zip> Recommended XML Encoding of
> CRS Definitions . A basic description of this document is:
>
> This OpenGIS Recommendation Paper specifies basic XML encoding of data
> defining coordinate reference systems and coordinate operations.
> This
> encoding is expected to be adapted and used by multiple OGC
> Implementation Specifications, by the separate specification of
> Application Schemas. This document is a Recommendation Paper because
> the
> specified encoding is more general than an OpenGIS Implementation
> Specification and more specific than the OpenGIS Abstract
> Specification.
>
>
> The actual normative/best practices coding scheme that we recommend is
> EPSG 6.0
>
> Hope this is not all too geo-geeky, but CRS is one of the big
> misunderstood areas of spatial processing that is often minimized or
> ignored by the larger information processing community. This is very
> unfortunate as a properly expressed and used approach to dealing with
> reference systems reduces error, increases accuracy, is fully
> international, is extensible, is legally defensible . . . need I go
> on??
>
> Cheers
>
> Carl
>
> PS: One last thing - the definition of a coordinate reference system:
> coordinate system which is related to the real world by a datum. So,
> the
> datum is only one piece of the equation :-)
>
> And the definition of datum: parameter or set of parameters that
> determine the location of the origin, the orientation and the scale of
> a
> coordinate reference system.
>
> Now, if you want to really get into the issue of defining elevation -
> what Dave was alluding to - elevation: distance of a point from a
> chosen
> reference surface along the direction of the gravity vector from the
> point to that surface.
>
> NOTE 1 See ellipsoidal height and gravity-related height. It should be
> noted that ellipsoidal height is defined w.r.t. an ellipsoidal model of
> the shape of the earth. Ellipsoidal height is measured from the point
> along the line perpendicular to the ellipsoid's surface.
>
> NOTE 2 Height of a point outside the surface treated as positive;
> negative height is also named as depth.
>
> ----- Original Message -----
> From: "R. Allen Wyke" < emergency-tc@earthlink.net
> <mailto:emergency-tc@earthlink.net> >
> To: "Carl Reed" < creed@opengis.org <mailto:creed@opengis.org> >
> Cc: "emergency TC lists Oasis" < emergency@lists.oasis-open.org
> <mailto:emergency@lists.oasis-open.org> >
> Sent: Tuesday, March 23, 2004 7:06 AM
> Subject: Re: [emergency] RE: Notes form last GIS SC meeting
>
>> On Mar 22, 2004, at 4:39 PM, Carl Reed wrote:
>>
>>> At the last GIS SC meeting we discussed the issue of whether WGS 84
> -
>>> Lat/Long is adequate for this go around of the CAP specification.
> The
>>> issue was raised with regard to using USNG-NAD83. The unanimous
>>> consensus of the group was that USNG is for use at the user
> interface
>>> level. Therefore, for a message protocol, such as CAP WGS 84 -
>>> Lat/Long is adequate and CAP spec should remain the way it is.
>>> Further, by leaving CAP with WGS 84 - Lat/Long, the CAP spec remains
>
>>> more international in nature and not restricted to the US market
>>> space.
>>>
>>> Also, by way of clarification, Dave Danko (ESRI) added:
>>> NAD 83 vs WGS 84: Technically these are the same for mapping,
>>> charting, and navigation purposes. Geodetically, of course they are
>>> different but I think they are the same for our purposes. To keep
> this
>>> standard international we should use WGS 84. Perhaps in a users
> guide
>>> for the US it could be mentioned that NAD 83 coordinates work fine
>>> here and that NAD 83 coordinates could be used. However (Carl's
> note),
>>> this would mean that we would need some code to allow the receiving
>>> application to know that the coordinates are NAD 83 and not WGS
>>> Lat/Long.
>>> As we are working at an accuracy level of many feet/meters, the
>>> geodetic differences are not important.
>>
>> While I am certainly no geocoding expert, would Dave's comments not
>> imply that the "best" way to handle this is to "facilitate the use of
>> various geocoding standards through the use of a coding identifier
>> (e.g.: specified in an attribute)"? What we have make work for us, but
>
>> that is not the question. Does it work for the target implementers is
>> the question. Saying that it is "adequate" gives to much of a feeling
>> like that is what we ended up with because we didn't take the time to
>> do it right.
>>
>>> We then went on to discuss the issue of "altitude" and "ceiling"
> notes
>>> section. We think the words "per the WGS 84 datum" should be
>>> removed. We think that this phrase will add communication confusion,
>
>>> especially for the geographically literate.
>>
>> I would assume this also means reworking the last sentence of section
>> 1.3.4 (<area>) as well, correct?
>>
>>> The WGS ellipsoid is a best fit around the world and differs from
> MSL
>>> by varied amounts around the world. So does one put a value
>>> here, including/excluding the delta from the WGS-84
>>> ellipsoid, a height referenced to the ellipsoid? What is the meaning
>
>>> of the value here? I think we should just have it from (local) MSL
> for
>>> the area of interest. (With ellipsoid heights there is a danger of
>>> having to provide negative values for areas above sea level). This
>>> would be plenty specific for the purposes intended for this
> standard.
>>> Perhaps this should be corrected in a future version of the
> standard.
>>
>> You lost me here in geo-lingo. What, specifically, does this paragraph
>
>> pertain to (section in spec, what would a rough first stab at the
>> proposed language look like, and how will that language address the
>> section of concern?
>>
>> Allen
>>
>> --
>> R. Allen Wyke
>> Chair, OASIS Emergency Management TC
>> emergency-tc@earthlink.net <mailto:emergency-tc@earthlink.net>
>>
>>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/emergency/members/
> leave_workgroup.php.
>
>
--
R. Allen Wyke
Chief Technology Officer
awyke@blue292.com
919.806.2440
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]