From: Lev Bishop (lev.bishop_at_yale.edu)
Date: Fri Jul 12 2002 - 02:22:33 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id E419814AB1 for <cavexml-outgoing_at_ethz.ch>; Fri, 12 Jul 2002 02:32:39 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id BE38014A6E; Fri, 12 Jul 2002 02:32:37 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 8DB7614AB1 for <cavexml-loopcheck_at_ethz.ch>; Fri, 12 Jul 2002 02:32:36 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 630B87D8C; Fri, 12 Jul 2002 02:32:34 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 1BF0E14AB1 for <cavexml_at_cartography.ch>; Fri, 12 Jul 2002 02:32:34 +0200 (CEST) Received: from pantheon-po04.its.yale.edu (pantheon-po04.its.yale.edu [130.132.50.23]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 4CA507D84 for <cavexml_at_cartography.ch>; Fri, 12 Jul 2002 02:32:31 +0200 (CEST) Received: from ares.its.yale.edu (ares.its.yale.edu [130.132.52.16]) by pantheon-po04.its.yale.edu (8.11.6/8.11.6) with ESMTP id g6C0MWG26380 for <cavexml_at_cartography.ch>; Thu, 11 Jul 2002 20:22:32 -0400 (EDT) Received: from localhost (lsb32_at_localhost) by ares.its.yale.edu (8.11.6/8.11.6) with ESMTP id g6C0MXr26475 for <cavexml_at_cartography.ch>; Thu, 11 Jul 2002 20:22:33 -0400 X-Authentication-Warning: ares.its.yale.edu: lsb32 owned process doing -bs Date: Thu, 11 Jul 2002 20:22:33 -0400 (EDT) From: Lev Bishop <lev.bishop_at_yale.edu> To: cavexml_at_cartography.ch Subject: Re: comments on the data model In-Reply-To: <3D2B6641.9030101_at_xmission.com> Message-ID: <Pine.LNX.4.44.0207111947050.19775-100000@ares.its.yale.edu> Content-Type: TEXT/PLAIN; charset=US-ASCII X-YaleITSMailFilter: Version 1.0c (attachment(s) not renamed) X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
On Tue, 9 Jul 2002, P A Hill & E V Goodall wrote:
(heavily snipped)
> Note: I'd leave room for stuffing nearly anything in here, in a
> mime-type like style of "If you understand what this tags attribute means,
> you probably can figure out the content of the this block, otherwise
> you are welcome to ignore it", but you might want to keep it for someone
> who does understand it.
That's a good idea. For example if you have digital surveying instruments
this would be the place to store the directly downloaded from the
instrument data, which might be useful to retain in the case that it
stores additional information for which there are no corresponding fields
in survex (eg internal calibrationparams, or something). THough I thik
that it would be good to specify one particular format for scanned data as
being "recommended". An "if you only support one format for raster data in
your survey software, make it this one" sort of thing. Something open like
PNG.
Even if software doesn't understand the format of the data, the advantage
of puttingit in the xml file is that you can store some standard xml
information regarding the datat. Eg, a description of what the data are
("cross section scanned from fieldbook" (with a link to the fieldbook
entity in question, and a link to the point/interpoint entity at which the
sketch was drawn), "cross section drawn from memory by Lev Bishop" (with
a link to the person entitiy corresponding to "lev bishop", "digital
photograph taken from survey station a pointing in such-a-direction" (with
a link to the relevant station info), etc) , who created the file,
creation time, etc.
> 4. processed form, i.e. still CaveXML data structures with room for
> everything from text stories, to GIS information, cave inventory items,
> cross sections, loop closure statistics, error matricies, contectivity
> information etc. this is where all the weird stuff lives, even if
> it didn't exist before.
agreed.
> I don't see that this pahse 4 "processed version" of CaveXML as
> SVD plus some extras. I see this Step 4 "processed" data more like CaveXML
Me too.
> But on beyond "processed" maybe there is another form,
> just like at the beginning we have a place to put any
> pre-CaveXML form, at the other end of the processing model
> there might be a level 5 data which would be something generated
> from the CaveXML but it is in some other format. This is were
> some neat SVG model, of simple box walls, or complex walls,
> or a plan view, a stick figure, a cut away would live. This is
> a place to put whatever some tool is capable generating from the
> "processed" caveXML.
Also a good idea. THat way you can specify suh standard information as:
creation person, creation time, which version of the dataset was used to
produce this data (eg, if there are different fixed-up type (2) datasets
for different purposes, or perhaps different surface survey
benchmarks/dataums, or different reduction techniques, etc. THis is
something that's difficult to keep track of normally unless you are very
disciplined about recordkeeping).
With both the type (1) data and type (5) if it were stored in this way,
then software that didn't know how to use the data could use the smae sort
of concept as web browsers and mail clients and launch helper applications
to deal with the foreign data.
Lev
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST