From: Alexander Nickolsky (nickol_at_argussoft.ru)
Date: Tue Jul 09 2002 - 13:26:51 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 0EFDB15917 for <cavexml-outgoing_at_ethz.ch>; Tue, 9 Jul 2002 13:34:40 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id DA17515904; Tue, 9 Jul 2002 13:34: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 CE64C15917 for <cavexml-loopcheck_at_ethz.ch>; Tue, 9 Jul 2002 13:34:36 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id A5A0515903; Tue, 9 Jul 2002 13:34: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 5681A15917 for <cavexml_at_cartography.ch>; Tue, 9 Jul 2002 13:34:34 +0200 (CEST) Received: from ns.argussoft.ru (ns.argussoft.ru [195.7.171.132]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id E621914ADC for <cavexml_at_cartography.ch>; Tue, 9 Jul 2002 13:34:30 +0200 (CEST) Received: from cachet (cachet.argussoft.ru [195.7.171.199]) by ns.argussoft.ru (8.9.1/8.9.1) with SMTP id OAA11358 for <cavexml_at_cartography.ch>; Tue, 9 Jul 2002 14:23:54 +0300 (MSK) Message-ID: <002901c2273b$8558d3a0$c7ab07c3@argussoft.ru> From: "Alexander Nickolsky" <nickol_at_argussoft.ru> To: <cavexml_at_cartography.ch> References: <Pine.LNX.4.44.0207080213330.14089-100000_at_ares.its.yale.edu> Subject: Re: comments on the data model Date: Tue, 9 Jul 2002 15:26:51 +0400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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
----- Original Message -----
From: "Lev Bishop" <lev.bishop_at_yale.edu>
To: <cavexml_at_cartography.ch>
Sent: Tuesday, July 09, 2002 12:50 AM
Subject: comments on the data model
> I just read the data model and it seems pretty good, general enough for
> most purposes I can think of, except that I think it doesn't make enough
> of a distinction between what I'll call "field" data and "raw" data. By
> "field" data, I mean the numbers, sketches, observations, etc, as actually
> recorded (in the notebook or whatever) in the field, whereas by "raw" data
> I mean the information which you want to feed to your network adjustment
I'd add here that the "final" data should also be stored at the same place.
The final data is the same data AFTER processing by some loop closure
program or anything else. This is necessary because : 1) loop closing
is an essential part of the survey as we do it now. 2) different processing
programs uses different algorithms and different assumptions even with
the same data. 3) and the most important. We are creating XML format
for what ? To establish a standard for a future software. There are two data
sets used by general cave mapping program : input data and output data.
I do not ignore the benefits of XML, but there exists a standard de-facto
for input data. It is the columnary format tha is 90% the same for all
existing software. However, there is no standard for output data at all.
So it is more useful to create the standard where it doesn't exist.
> 1) scanned images from your notebook;
I'm not sure that it is practical. It will add a lot of trouble dealing with
graphic formats,
but will add little to the concept. I think that (1) is the survey points
AS THEY WERE RECORDED + AS THEY WERE READ
> 2) direct digital transcriptions of (1) (ie vector tracings of
> sketches, ascii versions of tables of numbers);
> 3) fixed-up versions of > (2).
> Downloaded data from digital survey devices would count as (2). (1)
> and (2) are the "field" data; the "raw" data consists of (3). You want to
> be able to have multiple (3)'s associated with each (2) in case of
> different levels of fixing-up for different purposes. I guess in theory it
> might make sense to allow multiple (2)'s to associate with each (1), for
> the case that there can be disagreement over the transcription of a
> notebook (eg one person thinks that a muddy number is a '7' whereas
> another is convinced that its a '1'), but perhaps that would be taking
> things too far.
This could be easier achieved by entering a comment in (1) 'unclear writing'
and entering suggesed correct data in (3).
>
> Just to be absolutely clear, I'm thinking that both (2) and (3) will have
> the same format, will store the same information (instrument readings,
> calibrations, sketches, etc) and in many cases may even be identical to
> each other. In the case that they are different, the conversion of (2) to
> (3) will necessarily involve a lot of human input, rather than automated
> conversion tools.
>
Finally we have (1) and (2) together, (3) as final data and (4) as
processed data.
Renumber.
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST