From: Alexander Nickolsky (nickol_at_bigfoot.com)
Date: Mon Jan 21 2002 - 11:04:17 CET
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 C6A779D91 for <cavexml-outgoing_at_ethz.ch>; Mon, 21 Jan 2002 11:12:35 +0100 (CET) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id DEC739D8E; Mon, 21 Jan 2002 11:12:32 +0100 (CET) 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 CA2FD9D91 for <cavexml_at_cartography.ch>; Mon, 21 Jan 2002 11:12:31 +0100 (CET) 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 5E28A9D74 for <cavexml_at_cartography.ch>; Mon, 21 Jan 2002 11:12:28 +0100 (CET) Received: from wlbs (cachet.argussoft.ru [195.7.171.199]) by ns.argussoft.ru (8.9.1/8.9.1) with SMTP id NAA04429 for <cavexml_at_cartography.ch>; Mon, 21 Jan 2002 13:05:07 +0300 (MSK) Message-ID: <007501c1a262$fdde3ee0$c7ab07c3@argussoft.ru> From: "Alexander Nickolsky" <nickol_at_bigfoot.com> To: <cavexml_at_cartography.ch> Subject: About data model Date: Mon, 21 Jan 2002 13:04:17 +0300 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
The main topic says:
Before being able to successfully design a standard format it seems
necessary to reach concensus on a common data model
This is a good point for begin. As I can realize from various cave mapping
programs,
the authors of the cave mapping software often understands their task wrong.
They offer a very simple way of entering the data and pretend that their
program
'will do all the rest'. This is plain wrong. The process of cave surveying
has at least three
stages, each of them having its own data model.
At the first stage, the raw data is obtained. This is the basis of all
future map
and generally, it is the only data that we have. This means that the way
of entering this data should be as close as possible to the actual
measurements done.
This allows to find any mistakes, introduced when copying data from
surveying log into computer simply by comparing them record-by-record.
Any calculations, required to convert between various methods of surveying
(i.e. we could measure GPS coords of two entrances of the cave)
should be done in the software. Also, the outline of the cave should
be entered somehow at this stage.
At the second stage, the actual map of the survey is being built.
Here two kinds of errors could be found - blunders, such as compass
misreadings
and statistical errors, derived from loops.
If an obvious blunder is found, what to do then ? I think, it is very
incorrect to modify
the source data. There are two reasons for this : first is that the
correction for a blunder
could be incorrect itself, and the second is that the corrected data is less
relevant
than measured. This allows surveyors to repeat this measurement if needed.
Some anomalies and systematic errors can be corrected by hand.
Anyway, this shows that ANOTHER set of data is needed for this stage.
However, for this data set it is unnecessary to reflect the measurement
process.
It is enough to give dx, dy and dz - distances for every measurement, but
this
derived data should be linked to initial one.
Then the outline of the cave is drawn.
Actually, the outline is useful at the second stage already, to detect some
blunders, to say, when the outlined passage turns left, but measured turns
right,
we can determine that the measurement is wrong.
But the actual outline could be completed only when the process of 'moving
and adjusting' of measured points is finished. Completing the outline is
not such a critical task as adjusting measured points, because it usually
has so much less precision. I doubt, whether it is reasonable to keep
the initial outline data, I think it is not.
How I can imagine the process of working with topo, using some
ideal software :
1) I am entering the data using some program that allows me to
choose the order of columns and to see rough check of correctness
of the data.
The result is an XML file with my data, like this
<leg from="21" to="22" dist="10" brg="20" height="1">
2) I am doing an iterative process of calculating loops and hand-editing
the map. The result is THE SAME XML file, with some data added
<leg from="21" to="22" dist="10" brg="90" height="1" dx="10" dy="0" dz="1">
when I'll get some new data, I'll add them to the initial set.
3) I am correcting the outline.
4) Some server program makes SVG from this XML
or produces the filtered output like this
<leg from="21" to="22" dx="10" dy="0" dz="1">
and feeds it into client java applet, that will draw the map.
Also, there were questions about instrument errors.
To my mind, it is impossible to tell compass' actual
variance not having any statistical data. So,
here the same method could be used : enter
the scale factor of the compass, the program
should gather the statistical data for it and record
it in the same XML file.
Few words about our group :
We are working at artificial caves (souterrains) and our maps
usually consists of many (tens to hundreds) closed loops.
This archive was generated by hypermail 2b30 : Thu Jan 31 2002 - 23:00:01 CET