[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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 -----=20 From: "R. Allen Wyke" <emergency-tc@earthlink.net> To: "Carl Reed" <creed@opengis.org> Cc: "emergency TC lists Oasis" <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: >=20 > > At the last GIS SC meeting we discussed the issue of whether WGS 84 = -=20 > > Lat/Long is adequate for this go around of the CAP specification. = The=20 > > issue was raised with regard to using USNG-NAD83. The unanimous=20 > > consensus of the group was that USNG is for use at the user = interface=20 > > level. Therefore, for a message protocol, such as CAP WGS 84 -=20 > > Lat/Long is adequate and CAP spec should remain the way it is.=20 > > Further, by leaving CAP with WGS 84 - Lat/Long, the CAP spec remains = > > more international in nature and not restricted to the US market=20 > > space. > >=20 > > Also, by way of clarification, Dave Danko (ESRI) added: > > NAD 83 vs WGS 84: Technically these are the same for mapping,=20 > > charting, and navigation purposes. Geodetically, of course they are=20 > > different but I think they are the same for our purposes. To keep = this=20 > > standard international we should use WGS 84. Perhaps in a users = guide=20 > > for the US it could be mentioned that NAD 83 coordinates work fine=20 > > here and that NAD 83 coordinates could be used. However (Carl's = note),=20 > > this would mean that we would need some code to allow the receiving=20 > > application to know that the coordinates are NAD 83 and not WGS=20 > > Lat/Long. > > As we are working at an accuracy level of many feet/meters, the=20 > > geodetic differences are not important. >=20 > While I am certainly no geocoding expert, would Dave's comments not=20 > imply that the "best" way to handle this is to "facilitate the use of=20 > various geocoding standards through the use of a coding identifier=20 > (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=20 > the question. Saying that it is "adequate" gives to much of a feeling=20 > like that is what we ended up with because we didn't take the time to=20 > do it right. >=20 > > We then went on to discuss the issue of "altitude" and "ceiling" = notes=20 > > section. We think the words "per the WGS 84 datum" should be=20 > > removed. We think that this phrase will add communication confusion, = > > especially for the geographically literate. >=20 > I would assume this also means reworking the last sentence of section=20 > 1.3.4 (<area>) as well, correct? >=20 > > The WGS ellipsoid is a best fit around the world and differs from = MSL=20 > > by varied amounts around the world. So does one put a value=20 > > here, including/excluding the delta from the WGS-84=20 > > 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=20 > > the area of interest. (With ellipsoid heights there is a danger of=20 > > having to provide negative values for areas above sea level). This=20 > > would be plenty specific for the purposes intended for this = standard.=20 > > Perhaps this should be corrected in a future version of the = standard. >=20 > 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=20 > proposed language look like, and how will that language address the=20 > section of concern? >=20 > Allen >=20 > -- > R. Allen Wyke > Chair, OASIS Emergency Management TC > emergency-tc@earthlink.net >=20 > ------=_NextPart_000_00D0_01C410BB.E9C754E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV>Allen -</DIV> <DIV> </DIV> <DIV>The key point is that the GIS SC recommends that the use of WGS 84 = is fine=20 for CAP 1.0.</DIV> <DIV> </DIV> <DIV>Moving forward, it is my personal feeling - and I know that others = share=20 the same feeling - that CAP version 1.x will need to be enhanced to use = what you=20 termed a coding identifier. One possible route (and the one I would = favor) would=20 be to use the work of the OGC on Coordinate Reference Systems (CRS). The = OGC CRS=20 abstract and encoding specifications are fully grounded in and = supplements=20 the ISO TC 211 document ISO 19111: Geographic Information =96 Spatial = Referencing=20 by Coordinates. The basic premise is that we use a standard "model" for=20 expressing a CRS and that this model is "well known". </DIV> <DIV> </DIV> <DIV>From the OGC Abstract Model document for CRS: </DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV>This part of the OGC Abstract Specification defines the = conceptual schema=20 for the<BR>description of spatial referencing by coordinates, = optionally=20 extended by temporal<BR>referencing. It describes the minimum data = required to=20 define 1-, 2- and 3-dimensional<BR>coordinate reference systems with = an=20 extension to merged spatial-temporal coordinate<BR>reference systems. = It=20 allows additional descriptive information to be provided. It = also<BR>describes=20 the information required to change coordinate values from one=20 coordinate<BR>reference system to another. It is applicable to = producers and=20 users of geographic<BR>information. Although it is applicable to = digital=20 geographic data, its principles can be<BR>extended to many other forms = of=20 geographic data such as maps, charts, and = text<BR>documents.</DIV></BLOCKQUOTE> <DIV dir=3Dltr>So, how is this abstract model actually implemented? The = OGC=20 membership has approved a recommended normative approach for encoding = CRS=20 information. This can be found in a document titled <A=20 href=3D"http://www.opengis.org/docs/03-010r9.zip"; target=3D_blank><FONT = face=3DVerdana=20 size=3D1>Recommended XML Encoding of CRS Definitions</FONT></A> . A = basic=20 description of this document is:</DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV dir=3Dltr><FONT face=3DVerdana size=3D1>This OpenGIS = Recommendation Paper=20 specifies basic XML encoding of data defining coordinate=20 reference systems and coordinate operations. This = encoding=20 is expected to be adapted and used by multiple OGC Implementation=20 Specifications, by the separate specification of Application Schemas. = This=20 document is a Recommendation Paper because the specified encoding is = more=20 general than an OpenGIS Implementation Specification and more specific = than=20 the OpenGIS Abstract Specification.</FONT></DIV> <DIV dir=3Dltr><FONT face=3DVerdana = size=3D1></FONT> </DIV></BLOCKQUOTE> <DIV dir=3Dltr>The actual normative/best practices coding scheme that we = recommend=20 is EPSG 6.0</DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>Hope this is not all too geo-geeky, but CRS is one of the = big=20 misunderstood areas of spatial processing that is often minimized or = ignored by=20 the larger information processing community. This is very unfortunate as = a=20 properly expressed and used approach to dealing with reference systems = reduces=20 error, increases accuracy, is fully international, is extensible, is = legally=20 defensible . . . need I go on??</DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>Cheers</DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>Carl</DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>PS: One last thing - the definition <STRONG>of a <FONT=20 face=3DTimesNewRoman,Bold>coordinate reference system: = </FONT></STRONG><FONT=20 face=3DTimesNewRoman>coordinate system which is related to the real = world by a=20 datum. So, the datum is only one piece of the equation :-)</FONT></DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>And the definition of <FONT=20 face=3DTimesNewRoman,Bold><STRONG>datum</STRONG></FONT><FONT=20 face=3DTimesNewRoman><STRONG>: </STRONG>parameter or set of parameters = that=20 determine the location of the origin, the orientation and the scale of a = coordinate reference system.</FONT></DIV> <DIV dir=3Dltr> </DIV> <DIV dir=3Dltr>Now, if you want to really get into the issue of defining = elevation=20 - what Dave was alluding to - <B><FONT = face=3DTimesNewRoman,Bold>elevation:=20 </B></FONT><FONT face=3DTimesNewRoman>distance of a point from a chosen = reference=20 surface along the direction of the gravity vector from the point to that = surface.</DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV dir=3Dltr></FONT><FONT face=3DTimesNewRoman size=3D2> <P align=3Dleft>NOTE 1 See ellipsoidal height and gravity-related = height. It=20 should be noted that ellipsoidal height is defined w.r.t. an = ellipsoidal model=20 of the shape of the earth. Ellipsoidal height is measured from the = point along=20 the line perpendicular to the ellipsoid=92s surface.</P> <P align=3Dleft>NOTE 2 Height of a point outside the surface treated = as=20 positive; negative height is also named as = depth.</P></FONT></DIV></BLOCKQUOTE> <DIV>----- Original Message ----- </DIV> <DIV>From: "R. Allen Wyke" <<A=20 href=3D"mailto:emergency-tc@earthlink.net";>emergency-tc@earthlink.net</A>= ></DIV> <DIV>To: "Carl Reed" <<A=20 href=3D"mailto:creed@opengis.org";>creed@opengis.org</A>></DIV> <DIV>Cc: "emergency TC lists Oasis" <<A=20 href=3D"mailto:emergency@lists.oasis-open.org";>emergency@lists.oasis-open= .org</A>></DIV> <DIV>Sent: Tuesday, March 23, 2004 7:06 AM</DIV> <DIV>Subject: Re: [emergency] RE: Notes form last GIS SC meeting</DIV> <DIV><BR></DIV>> On Mar 22, 2004, at 4:39 PM, Carl Reed = wrote:<BR>>=20 <BR>> > At the last GIS SC meeting we discussed the issue of = whether WGS=20 84 - <BR>> > Lat/Long is adequate for this go around of the CAP=20 specification. The <BR>> > issue was raised with regard to using=20 USNG-NAD83. The unanimous <BR>> > consensus of the group was that = USNG is=20 for use at the user interface <BR>> > level. Therefore, for a = message=20 protocol, such as CAP WGS 84 - <BR>> > Lat/Long is adequate and = CAP spec=20 should remain the way it is. <BR>> > Further, by leaving CAP with = WGS 84 -=20 Lat/Long, the CAP spec remains <BR>> > more international in = nature and=20 not restricted to the US market <BR>> > space.<BR>> > = <BR>> >=20 Also, by way of clarification, Dave Danko (ESRI) added:<BR>> = > NAD=20 83 vs WGS 84: Technically these are the same for mapping, <BR>> >=20 charting, and navigation purposes. Geodetically, of course they are = <BR>>=20 > different but I think they are the same for our purposes. To keep = this=20 <BR>> > standard international we should use WGS 84. Perhaps in a = users=20 guide <BR>> > for the US it could be mentioned that NAD 83 = coordinates=20 work fine <BR>> > here and that NAD 83 coordinates could be used. = However=20 (Carl's note), <BR>> > this would mean that we would need some = code to=20 allow the receiving <BR>> > application to know that the = coordinates are=20 NAD 83 and not WGS <BR>> > Lat/Long.<BR>> > As we are = working at an=20 accuracy level of many feet/meters, the <BR>> > geodetic = differences are=20 not important.<BR>> <BR>> While I am certainly no geocoding = expert, would=20 Dave's comments not <BR>> imply that the "best" way to handle this is = to=20 "facilitate the use of <BR>> various geocoding standards through the = use of a=20 coding identifier <BR>> (e.g.: specified in an attribute)"? What we = have make=20 work for us, but <BR>> that is not the question. Does it work for the = target=20 implementers is <BR>> the question. Saying that it is "adequate" = gives to=20 much of a feeling <BR>> like that is what we ended up with because we = didn't=20 take the time to <BR>> do it right.<BR>> <BR>> > We then = went on to=20 discuss the issue of "altitude" and "ceiling" notes <BR>> > = section. We=20 think the words "per the WGS 84 datum" should be <BR>> > removed. = We think=20 that this phrase will add communication confusion, <BR>> > = especially for=20 the geographically literate.<BR>> <BR>> I would assume this also = means=20 reworking the last sentence of section <BR>> 1.3.4 (<area>) as = well,=20 correct?<BR>> <BR>> > The WGS ellipsoid is a best fit around = the world=20 and differs from MSL <BR>> > by varied amounts around the world. = So does=20 one put a value <BR>> > here, including/excluding the delta from = the=20 WGS-84 <BR>> > ellipsoid, a height referenced to the ellipsoid? = What is=20 the meaning <BR>> > of the value here? I think we should just have = it from=20 (local) MSL for <BR>> > the area of interest. (With ellipsoid = heights=20 there is a danger of <BR>> > having to provide negative values for = areas=20 above sea level). This <BR>> > would be plenty specific for the = purposes=20 intended for this standard. <BR>> > Perhaps this should be = corrected in a=20 future version of the standard.<BR>> <BR>> You lost me here in = geo-lingo.=20 What, specifically, does this paragraph <BR>> pertain to (section in = spec,=20 what would a rough first stab at the <BR>> proposed language look = like, and=20 how will that language address the <BR>> section of concern?<BR>> = <BR>>=20 Allen<BR>> <BR>> --<BR>> R. Allen Wyke<BR>> Chair, OASIS = Emergency=20 Management TC<BR>> <A=20 href=3D"mailto:emergency-tc@earthlink.net";>emergency-tc@earthlink.net</A>= <BR>>=20 <BR>> </BODY></HTML> ------=_NextPart_000_00D0_01C410BB.E9C754E0--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]