OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: RE: [emergency] Circle and Polygon

I tend to listen closely when Len speaks up.


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

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

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