From: devinkouts_at_earthlink.net
Date: Thu Jan 25 2001 - 21:14:00 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA18240 for cavexml-outgoing; Thu, 25 Jan 2001 21:12:03 +0100 Received: from [209.70.170.131] (brick.cist.saic.com [209.70.170.131]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id VAA18236 for <cavexml_at_cartography.ch>; Thu, 25 Jan 2001 21:12:00 +0100 From: devinkouts_at_earthlink.net Received: from cist.saic.com by [209.70.170.131] via smtpd (for karto.ethz.ch [129.132.127.159]) with SMTP; 25 Jan 2001 20:12:05 UT Received: from earthlink.net (unverified [10.43.39.246]) by exmail.cist.saic.com (EMWAC SMTPRS 0.83) with SMTP id <B0000711914_at_exmail.cist.saic.com>; Thu, 25 Jan 2001 15:13:05 -0500 Message-ID: <3A708907.3B21D56C@earthlink.net> Date: Thu, 25 Jan 2001 15:14:00 -0500 X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: CaveXML>Misc. Discussion>Data model, Concepts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
I sent this message a couple days ago but it seems to have been lost in
all the chatter. Atleast one person confessed to not having seen it come
across. I'll submit it again in case anyone cares.
DSK
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 one of the
things 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
-- Devin Kouts Caver Systems Engineer www.psc-cavers.org
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:53 CET