[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

*Subject*: **[emergency] RE: Some comments/thoughts on EDXL) DistributionElement, v. 1.0**

*From*:**Rex Brooks <rexb@starbourne.com>***To*: "Carl Reed OGC Account" <creed@opengeospatial.org>, <emergency@lists.oasis-open.org>*Date*: Mon, 16 Jan 2006 15:25:49 -0800

Thanks Carl, Never too late to get straight, even if topolographically there are nothing but curves. (Intentional misspelling ;-) ) Ciao, Rex At 3:04 PM -0700 1/16/06, Carl Reed OGC Account wrote: >First, apologies for not having brought these discussion points up >before. Have been busy dealing with OGC standards facilitation >activities :-) > >Have been browsing Emergency Data Exchange Language (EDXL) >Distribution Element, v. 1.0, Committee Draft, 28, December 2005. A >couple of (minor?) points: > >1. Page 26, line 22. "geo-spatial" should be "geospatial". Common >use is no "-". > >2. In targetArea section, WGS 84 is referenced. I would encourage an >informational note akin to what is in CAP providing a more thorough >description and perhaps a reference, such as the definition NGA >WGS-84 document. The CAP 1.1 informational section states, >"Geographic locations in CAP are defined using WGS 84 (World >Geodetic System 1984), equivalent to EPSG (European Petroleum Survey >Group) code 4326 (2 dimensions). CAP does not assign >responsibilities for coordinate transformations from and to other >Spatial Reference Systems." > >3. For polygon, there is the statement that a "space delimited >series of . . ." and then the example includes commas. I would >suggest that the correct phrasing should be "space seperated list of >latitude-longitude pairs, with each pair separated by whitespace" or >something along those lines. I would discourage commas as ISO, W3C, >and the OGC have all determined that space separated/white space is >best practice. I know that this is also a bit different that CAP, >which is comma delimited. I would propose that this also be changed. >Finally, check out georss.org - Simple. The georss encoding proposal >is the result of a collaboration between RSS folks, W3C members, OGC >members and some input from the IETF. > >4. For circle and polygon, the definition of latitude/longitude is >ambiguous. CAP 1.1 has an informational section on the semantics of >expression. For example, in the EDXL document, there is no guidance >as to whether lat/long is expressed as decimal degrees or <degrees, >minutes, seconds>. The best semantical definition I have seen for >describing the semantics of lat/long usage on a global basis is (and >derived from ISO): > >Values for latitude and longitude shall be expressed as decimal >fractions of degrees. Whole degrees of latitude shall be >represented by a decimal number ranging from 0 through 90. Whole >degrees of longitude shall be represented by a decimal number >ranging from 0 through 180. When a decimal fraction of a degree is >specified, it shall be separated from the whole number of degrees by >a decimal point (the period character, "."). Decimal fractions of a >degree should be expressed to the precision available, with trailing >zeroes being used as placeholders if required. A decimal point is >optional where the precision is less than one degree. Some effort >should be made to preserve the apparent precision when converting >from another datum or representation, for example 41 degrees 13 >minutes should be represented as 41.22 and not 41.21666, while 41 >13' 11" may be represented as 41.2197. > >Latitudes north of the equator MAY be specified by a plus sign >(+), or by the absence of a minus sign (-), preceding the >designating degrees. Latitudes south of the Equator MUST be >designated by a minus sign (-) preceding the digits designating >degrees. Latitudes on the Equator MUST be designated by a latitude >value of 0. > >Longitudes east of the prime meridian shall be specified by a >plus sign (+), or by the absence of a minus sign (-), preceding >the designating degrees. Longitudes west of the prime meridian MUST >be designated by a minus sign (-) preceding the digits >designating degrees. Longitudes on the prime meridian MUST be >designated by a longitude value of 0. A point on the 180th meridian >shall be taken as 180 degrees West, and shall include a minus sign. > >Sorry, but ambiguity leads to non-interoperability that can lead to >increased threat, damage, or loss of life! > >5. For Circle, why a radius expressed only in kilometers?? And there >is no statement as to the precision for kilometers. Is the nearest >Kilometer enough or should accuracy be properly expressed - like >down to meters. We need some informational guidance here. > >6. For polygon, the document states, "an ordered set of vertices". >This is ambigous. Is the ordered set clockwise or counterclockwise? >For example, the following definition for a polygon is from the ESRI >Shapefile technical manual - and is entirely consistent with ISO >19107 - Geometry. > >A polygon consists of one or more rings. A ring is a connected >sequence of four or more points that form a closed, >non-self-intersecting loop. A polygon may contain multiple outer >rings. The order of vertices or orientation for a ring indicates >which side of the ring is the interior of the polygon. The >neighborhood to the right of an observer walking along the ring in >vertex order is the neighborhood inside the polygon. Vertices of >rings defining holes in polygons are in a counterclockwise >direction. Vertices for a single, ringed polygon are, therefore, >always in clockwise order. The rings of a polygon are referred to as >its parts. > >The ESRI definition is (English wise) much easier to understand than >the ISO "A GM_Polygon (Figure 21) is a surface patch that is defined >by a set of boundary curves and an underlying surface to which these >curves adhere. The default is that the curves are coplanar and the >polygon uses planar interpolation in its interior." > > :-) > >Some might say that the above informational guidance should be in an >implementors guide. However, in terms of compliance, international >standards best practice, lack of ambiguity, and so forth such >guidance MUST be included in the actual standard and not in >non-normative supporting documentation. > >Carl > >From CAP 1.1: > >3.3.1. WGS-84 Note > >Geographic locations in CAP are defined using WGS 84 (World Geodetic >System 1984), equivalent to EPSG (European Petroleum Survey Group) >code 4326 (2 dimensions). CAP does not assign responsibilities for >coordinate transformations from and to other Spatial Reference >Systems. > > > >Carl Reed, PhD >CTO and Executive Director Specification Program >OGC > >The OGC: Helping the World to Communicate Geographically > >--------------------- > >This communication, including attachments, is for the exclusive use >of addressee and may contain proprietary, confidential or privileged >information. If you are not the intended recipient, any use, >copying, disclosure, dissemination or distribution is strictly >prohibited. If you are not the intended recipient, please notify the >sender immediately by return email and delete this communication >and destroy all copies. > >"The important thing is not to stop questioning." -- Albert Einstein -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309

**References**:**RE: Some comments/thoughts on EDXL) Distribution Element, v. 1.0***From:*"Carl Reed OGC Account" <creed@opengeospatial.org>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]