Re: [emergency] RE: Some comments/thoughts on EDXL) Distribution Element, v. 1.0

[Art Botterell <acb@incident.com>]

Carl et al. -

A few quick queries and comments...

On Jan 16, 2006, at 1/16/06 2:04 PM, Carl Reed OGC Account wrote:
> 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.

CAP uses commas within lat/lon pairs, but spaces between those  
pairs.  Not sure I understand the distinction you seem to be drawing  
between "space" and "whitespace." Are you suggesting just an  
alternation of lats and lons with spaces between all... i.e., no  
difference between the intra-pair and inter-pair delimiters?  Seems  
like that would make converting the string into an array of lat/lon  
pairs harder.  Maybe an example of what you mean would be helpful.

> 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.

It's in kilometers because that's the unit we decided on.  It's ONLY  
in kilometers because we didn't want to complicate things by  
requiring clients to know how to convert among a variety of units.   
(Nautical miles? Leagues? Rods? Furlongs?)  It seemed more reasonable  
to require the sender to convert from its local units, once and for  
everyone.

As for precision... the only guidance we offer in CAP is that the  
presented precision should not exceed the actual precision of the  
measurement.  Other than that, seems like each source should be  
allowed to be as precise or imprecise as its information happens to  
be.  Certainly there's no requirement that the radius be an integer.

> 6. For polygon, the document states, "an ordered set of vertices".  
> This is ambigous. Is the ordered set clockwise or counterclockwise?

It's not ambiguous... the vertices need to be in sequence.  We  
discussed this for CAP and concluded that there was no actual  
requirement to enforce a direction of ordering.... most software and  
most algorithms seemed able to cope with either direction.  I would  
agree, however, that we could probably be more specific about our  
usage of the term "polygon," which refers to what ESRI calls a ring  
(i.e., single, and non-self-intersecting.)

> 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, we've always relied on the GIS subcommittee to give us guidance  
on these issues.  It's regrettable that these inputs are arriving so  
late in the process, and I guess the TC will have to decide whether  
they justify further delay in approving EDXL-DE 1.0.  Anyway, not  
sure what your basis is for using the imperative MUST in this  
regard... seems like we're talking about a matter of opinion here.

- Art