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