RE: [emergency] Circle and Polygon

["Bullard, Claude L (Len)" <len.bullard@intergraph.com>]

Variations tend to be more complicated given 
an overall system than local complexity in 
an element type.  Given a choice of having 
YetAnotherGeometry for the data (presentation 
being unavoidably variant), I'd choose to 
use the GML.  

This is an information ecology choice.  Which 
part of the overall set of system applications 
do you most want to be aligned with?  This 
cascades up all the way to the personnel implementing 
the system and the code libraries they have to 
work from.   If emergency management systems 
and GIS systems are to be closely aligned, you 
want to stick to the GML by namespace.  Look 
at the point-to-point interchanges and ask 
yourself which systems are communicating at 
what rate.  That will tell you where the hot 
zones are, therefore, what is consuming the 
most resources in all dimensions of the systems.

Granted, providing a separate namespace context 
creates massively verbose files and orthogonal 
semantics, but naming conventions are worse. 
GJXDM is a good example of naming conventions 
become deranged.  It takes an awful amount of 
work to find the integer at the bottom of the 
well.  Assuming maximum independence of local 
data ignores the realities of interoperating 
systems.

len


From: Art Botterell [mailto:acb@incident.com]

On Jun 9, 2005, at 7:57 PM, Renato Iannella wrote:
> Again, my GML expert friend says that a polygon would look like:
>
> <gml:Polygon>
>    <gml:exterior>
>        <gml:LinearRing>
>            <gml:pos>12 4</gml:pos> <gml:pos>12 8</gml:pos> ...
>        </gml:LinearRing>
>    </gml:exterior>
> </gml:Polygon>

Hmmm.  I think one of the keys to the early update of CAP has been  
that simple concepts are represented in simple ways.

Other folks may feel differently, but I'm not certain the EDXL  
routing application really needs the full functionality provided by  
this much bulkier representation.  E.g., in the past we've handled  
included polygons... which much more often involve different  
information or instructions than mere exclusion... by overriding them  
with other blocks referencing other simple polygons.

So it sounds like the TC may need to revisit the question of whether  
we want to follow the GML standards in full, or some other precident,  
or stick to a simplified model.