RE: [emergency] Circle and Polygon

[Rex Brooks <rexb@starbourne.com>]

I tend to listen closely when Len speaks up.

Ciao,
Rex

At 8:26 AM -0500 6/10/05, Bullard, Claude L (Len) wrote:
>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.
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309