From: Devin Kouts (devinkouts_at_earthlink.net)
Date: Wed Jan 24 2001 - 01:23:55 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id BAA05572 for cavexml-outgoing; Wed, 24 Jan 2001 01:20:12 +0100 Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA05568 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 01:20:11 +0100 Received: from earthlink.net (sdn-ar-003varestP011.dialsprint.net [168.191.219.19]) by hawk.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA15104 for <cavexml_at_cartography.ch>; Tue, 23 Jan 2001 16:18:47 -0800 (PST) Message-ID: <3A6E209B.9080907@earthlink.net> Date: Tue, 23 Jan 2001 19:23:55 -0500 From: Devin Kouts <devinkouts_at_earthlink.net> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: ko,en To: cavexml_at_cartography.ch Subject: CaveXML>Misc. Discussion>Data model, Concepts Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
In the subject discussion (at
http://www.karto.ethz.ch/~an/caving/cavexml/issues.html ) Martin and
Andreas makes several points. Some I would like to second and put my
support behind. Others I would like to comment on and discuss further.
These include:
>define a set of data structures to represent cave survey data.
>concentrate on data of approaches currently used and leave more
ambitious future oriented concepts for the next releases.
>concentrates on current development and implementation of a standard
compatible with existing software and current survey methods.
>not ... burden the first attempt by including concepts that still need
further research and development of sophisticated algorithms.
>... a comprehensive data model ... would include the original survey
data ... derived 3D-model and ... visualizations. It would make sense to
>separate the data into three entitities: Survey, Model and View.
I concur with and support all of these statements.
>One of the major challenges will be to include all the manually drawn
map elements back into the model - and ideally have them reajusted in
>every loop closing process.
Interestingly, Ralph Hartley, author of Carto (www.psc-cavers.org/carto)
and contributor to this discussion group is working on something that
could eventually evolve into just such a capability. Carto, at present,
has the ability to adjust manual cave sketches as surveys change due to
loop closure impacts. The knowledge Ralph builds of this process may
prove invaluable later on.
>One of the main architectural issue seems to be the different ways the
current data is structured in the various existing data-sets and programs.
> We ought to support both philosophies and create a standard format
that resembles the original data in both forms closely.
>We therefor need two different grouping tags,
>CaveXML should therefor have the capability to represent series
directly or through an additional modelling section.
Hmmm, not too sure about this last bit. The architectural issues you
describe are an artifact of the way we like to "look" at our data. I.e.
the users of Toporobot and Caverender like to "see" their data in a
series structure that resembles the morphology of the cave. Other
software users like to "view" their data in a form more reminiscent of
how it was written into the survey book. In reality, both are the result
of bad data engineering practices. That is to say the data's
organization is not optimized for the benefit of the machine (e.g. quick
access, retrieval and update), but instead optimized for the "visual"
comprehension of a human reader. In this instance, human readers with
two seperate prefered "views".
I'm emphasizing the use of "visual" words here for a reason. The
incompatability we see between architectures is merely an incongruity in
the visual representation of the data. In fact I would imagine the basic
elements of survey data in Toporobot are no different from elements of
survey data stored in WInKarst, Compass, OnStation or Survex formats
(although I've never studied a Toporobot file, can anyone send me an
example?).
I think we should, with this CaveXML effort, work toward a single
representation of data, that is independant of personal "visualization"
biases. This is in keeping with our goals for machine and software
independance. Let's add human-bias independance to that list, too. The
creation of two different "grouping tags" (if I understand your
implications correctly), would merely serve the purpose of visually
displaying the data in two different arrangements.
Visual display of data is a human bias driven issue that should more
appropriately be handled at the application layer. It's the thing that
lets a user pick one application over another, i.e. a preference for how
a particular application displays the data in it's data editor, for
instance. That data visualization should not be enforced upon the data
store itself.
If two (or more) methods of viewing the data are ultimately desireable,
then translation from one common schema into other "preferred" schemas
can be accomplished with technologies like XSLT. Maybe the suggestion of
an additional modelling section can be accomplished with an XSLT type of
transformation capability. This would certainly serve to keep the
CaveXML standard as efficient as possible.
Please expand more upon your thoughts for "two different grouping tags".
Maybe your description left out some information that could be used to
pursuade me differently.
Devin Kouts
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET