I was assuming again, sorry. The assumption: any change in the circle
(or any Location element) must ipso facto take place in the OASIS where
profile. I would certainly not support having a balkanization of
Location definitions with a tweak here and there.
Cheers,
Rex
McGarry, Donald P. wrote:
> So this is on the list. I was planning to advocate moving to our GeoOASIS where GML profile for targetarea geographic objects.
>
> -Don
> Office: 315-838-2669
> Cell: 703-595-9375
>
>
>
> -----Original Message-----
> From: Rex Brooks [mailto:]
> Sent: Thursday, June 24, 2010 1:03 PM
> To: Carl Reed
> Cc: McGarry, Donald P.; Gilmore, Timothy;
> Subject: Re: [emergency] RE: EDXL-DE 2.0 for the F2F - Objectivity, Subjectivity and Interpretation.
>
> I concur.
>
> Cheers,
> Rex
>
> Carl Reed wrote:
>
>> Not to stir the pot, but if nay (minor) changes are made to the
>> definition of the circle element, would be nice to at least structure
>> the content to be consistent with the PIDF-LO definition so that CAP
>> and EDXL 2.0s are aligned with NENA Next Generation 911 specification
>> of the use the Location Object.
>> To whit:
>>
>> The circular area is used for coordinates in two-dimensional CRSs to
>> describe uncertainty about a point. The definition is based on the
>> one-dimensional geometry in GML, gml:CircleByCenterPoint.
>>
>> The centre point of a circular area shall be specified using a two
>> dimensional CRS; in three dimensions, the orientation of the circle
>> cannot be specified correctly using this representation. A point with
>> uncertainty that is specified in three dimensions SHOULD use the
>> Sphere shape type.
>>
>> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
>> xmlns:gs="http://www.opengis.net/pidflo/1.0"
>> xmlns:gml="http://www.opengis.net/gml">
>> <gml:pos>
>> 42.5463 -73.2512
>> </gml:pos>
>> <gml:radius uom="urn:ogc:def:uom:EPSG::9001">
>> 850.24
>> </gml:radius>
>> </gs:Circle>
>> The only change I would recommend would be to use an http URI for the
>> CRS and uom definitions. Anyway, please note the lat-long order and
>> the use of white space. GML uses white space.
>> Also, FYI, this schema snippet for circle is almost identical to what
>> the schema will look like in the GML OASIS where document.
>> Cheers
>> Carl
>>
>> ----- Original Message -----
>> *From:* McGarry, Donald P. <mailto:>
>> *To:* Gilmore, Timothy <mailto:> ;
>>
>> <mailto:>
>> *Sent:* Thursday, June 24, 2010 3:54 AM
>> *Subject:* [emergency] RE: EDXL-DE 2.0 for the F2F - Objectivity,
>> Subjectivity and Interpretation.
>>
>> Tim-
>>
>> I wholeheartedly agree!
>>
>> I did bring this up for discussion earlier and we agreed that a
>> circle /should/ be
>>
>> <circle>lat','lon<space>radius</circle>
>>
>> Which makes comment 1 and the example wrong (extra space in both
>> between the lat and lon).
>>
>> This is on the issues list for 2.0. I will add the point about the
>> radius, because as stated it should be an *unsigned* integer with
>> a maximum value less than that of a normal signed or unsigned int.
>>
>> Are you suggesting that we use different wording for the OPTIONAL,
>> MAY use multiple? That was a little confusing to me at first, so
>> input would be appreciated.
>>
>> I have added these topics to the issues list
>>
>> -Don
>>
>> Office: 315-838-2669
>>
>> Cell: 703-595-9375
>>
>> <mailto:>
>>
>> *From:* Gilmore, Timothy [mailto:]
>> *Sent:* Wednesday, June 23, 2010 10:24 AM
>> *To:*
>> *Subject:* [emergency] EDXL-DE 2.0 for the F2F - Objectivity,
>> Subjectivity and Interpretation.
>>
>> All,
>>
>> Some of the things we look at are objectivity and subjectivity due
>> to our accreditation under the American Association for Laboratory
>> Accreditation (A2LA) for NIMS STEP and IPAWS Conformity Assessment
>> (CA) testing. Many elements under the OASIS EDXL suite of
>> standards including CAP use words such as "SHOULD" and "MAY" which
>> are clearly subjective in nature. One of our engineers pointed out
>> some issues that we should keep in mind when going over the
>> EDXL-DE 2.0 document during the F2F.
>>
>> For CAP:
>>
>> /What we're looking for are rules or constraints that are open to
>> interpretation, or not fully specified, rather than being
>> completely "nailed down."/
>>
>> / /
>>
>> /For example, consider the <circle> element. Is the following a
>> "correct" <circle> element?/
>>
>> / /
>>
>> / <circle> 0, 0, 150000000 </circle>/
>>
>> / /
>>
>> /It certainly fits the descriptions in that element's comments:
>> (1) it's in the form "latitude, longitude, radius"; (2) the
>> central point conforms to WSG84; (3) the radius value is expressed
>> in kilometers; and/
>>
>> /(4) it is a properly escaped XML string./
>>
>> / /
>>
>> /Then again, the radius of the circle is approximately the
>> distance between the Earth and the Sun. Note that the given
>> definition includes the word "geographic" (twice!) and that the
>> center of the circle is specified as longitude and latitude, all
>> of which indicates to me that the circle ought be to Earth-bound.
>> Someone else may interpret the standard differently, and the
>> standard doesn't put a real limit on the radius of the circle./
>>
>> / /
>>
>> /The point is that the standard doesn't really specify enough for
>> a tester to determine whether or not a <circle> element is
>> conforming./
>>
>> /The tester has to make up his (or her!) own rules to complete the
>> test./
>>
>> /Multiple testers will certainly come to different conclusions,
>> and all will be correct to within the subjectivity allowed by the
>> standard./
>>
>> / /
>>
>> /(And that all said, note that the given example doesn't match the
>> form given in comment 1; the comma between the longitude and the
>> radius is missing. Since all of section 3 of this standard is
>> normative, this is a bug in this standard.)/
>>
>> / /
>>
>> /For another example, consider the <senderRole> element. The
>> standard says "OPTIONAL, MAY use multiple." Despite the words
>> "OPTIONAL" and "MAY," an individual tester can determine without a
>> doubt whether a given message contains zero or more <senderRole>
>> elements, and an infinite number of testers (all else being equal)
>> will come to exactly the same conclusion./
>>
>> Perhaps something to think about at the F2F.
>>
>> Thanks,
>>
>> *Timothy D. Gilmore* | SAIC
>>
>> Sr. Test Engineer | ILPSG | NIMS Support Center |
>>
>> IPAWS CA / NIMS STEP
>>
>> phone: 606.274.2063 | fax: 606.274.2025
>>
>> mobile: 606.219.7882 | email:
>> <mailto:>
>>
>> P Please consider the environment before printing this email.
>>
>>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
>
>
>
>
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
