MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Circle and Polygon
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]