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