Re: About data model

New Message	Reply	About this list	Date view	Thread view	Subject view	Author view

From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Tue Jan 22 2002 - 08:25:21 CET

Next message: Andreas Neumann: "webmail interface is now working again"
Previous message: Alexander Nickolsky: "About data model"
In reply to: Alexander Nickolsky: "About data model"

Message-Id: <5.1.0.14.1.20020122182220.04984ec0@popa.melbpc.org.au>
Date: Tue, 22 Jan 2002 18:25:21 +1100
To: cavexml_at_cartography.ch
From: Peter MATTHEWS <matthews_at_melbpc.org.au>
Subject: Re: About data model
In-Reply-To: <007501c1a262$fdde3ee0$c7ab07c3_at_argussoft.ru>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-cavexml_at_karmail.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch

Hi Alexander,

Welcome to the group! You make some good points which it will be good to
discuss in more detail when we soon come to sort out the data model.

Best wishes,

Peter

At 13:04 21-01-02 +0300, Alexander Nickolsky wrote:
>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.

Next message: Andreas Neumann: "webmail interface is now working again"
Previous message: Alexander Nickolsky: "About data model"
In reply to: Alexander Nickolsky: "About data model"

New Message	Reply	About this list	Date view	Thread view	Subject view	Author view

This archive was generated by hypermail 2b30 : Thu Jan 31 2002 - 23:00:01 CET