From: Roger Schuster (roger_at_r-schuster.de)
Date: Wed Feb 07 2001 - 19:05:42 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA21900 for cavexml-outgoing; Wed, 7 Feb 2001 19:05:20 +0100 Received: from mail.arcor-ip.de (mail-ffm-p.arcor-ip.de [145.253.2.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA21896 for <cavexml_at_cartography.ch>; Wed, 7 Feb 2001 19:05:19 +0100 Received: from r-schuster.de (145.253.168.155) by mail.arcor-ip.de; 7 Feb 2001 19:05:27 +0100 Received: from localhost (roger_at_localhost) by r-schuster.de (8.11.0/8.11.0) with ESMTP id f17I5gZ00940 for <cavexml_at_cartography.ch>; Wed, 7 Feb 2001 19:05:42 +0100 Date: Wed, 7 Feb 2001 19:05:42 +0100 (CET) From: Roger Schuster <roger_at_r-schuster.de> To: <cavexml_at_cartography.ch> Subject: Re:Groupings In-Reply-To: <3A8163EB.E5F160D7_at_earthlink.net> Message-ID: <Pine.LNX.4.30.0102071732190.877-100000@r-schuster.de> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
On Wed, 7 Feb 2001 devinkouts_at_earthlink.net wrote:
Hello all,
> HA36 HB1 28 30 265
> >From David MacKenzie's Walls, read as: From Station, To Station,
> Inclination, Distance, Azimuth.
(...)
> 2 4 7.89 254 -11
> >From Olly Bett's Survex, read as From Station, To Station, Distance,
> Azimuth, Inclination
Do you see the difference? We will have serious problems with station names:
Some software allows alphanumeric names, other allows only numeric values
(CaveRender, Toporobot AFAIK). Some programs do support station names up to
eight characters long, others even twelve or more. Some programs use
combined names for stations (survey+station), others doesn't. And so on.
How should we ever import a xml file created with Walls (only an example)
into a software which can't handle alphanumeric station names? The importing
program must completely reorganize the data to fit them into its own data
modell. Names which are too long must be cut, survey names with letters must
be replaced by numbers etc. In other words, after importing the data doesn't
reflect the "natural" way any longer in which they were recorded. This will
open the door for misunderstandings: Is station AB11 the same as 5/11 after
the data are transfered from Walls to Toporobot? Somebody who does look on
two maps of the same cave wouldn't understand that both of them are based on
the same data but generated with different pieces of software.
> But I would consider all of these to be natural representations of the way
> we accomplish and record a "survey shot".
Not really. In "Compass" for example it doesn't matter if you enter the
Distance in meters or in feet and inches, internally it converts any lengths
to decimal feet. Other programs write the data to binary files but my survey
book naturally only contains characters and numbers.
> They all follow a basic model,
> that looks like this:
>
> >From Station, To Station, Distance, Azimuth, Inclination, (and
> optionally) Left, Right, Up, Down
Very general they do.
> All of these constructs follow a model that organizes "shots" and their
> attendant data into surveys. Surveys are expanded over time by one of
> two methods; either (1) opening an existing survey and inserting new
> shots between the delimiters of that survey, or (2) by creating a new
> delimited survey with new shot data, and linking that new collection to
> previously existing surveys.
Most software does allow both ways. Which one is more useful depends on the
exact situation. If I record new data in a passage which is already partially
surveyed I put them into the same survey. If I explore two passages on the
same day with the same team and the same instruments I put the data into two
different surveys. Each passage its own survey.
> Others take the approach that surveys are one monolithic collection of
> shots that you merely append new collections of shots to. Illustrated
> like this:
>
> <survey name="the only survey">
> <shot>first shot on first survey trip</shot>
> <shot>second shot on first survey trip</shot>
> <shot>etc...</shot>
> <shot>first shot on second survey trip</shot>
> <shot>second shot on second survey trip</shot>
> <shot>etc...</shot>
> </survey>
I think it is rather stupid putting anything into the same survey but any
caving software I tested so far does support this already.
> So to state the need: A survey must be capable of delimiting a
> collection of shots. Furthermore , that survey must itself be expandable
> by any of three methods, (1) the inclusion of new shots into the
> existing survey collection, or (2) the inclusion of a new survey into
> the existing survey collection (creating a parent/child relationship),
> or (3) the association (e.g. linking) of one survey to another (creating
> a sibling relationship).
(1) is a necessary feature but (2) and (3) are more difficult. On may say
that a side passage is a "child" of the main branch (because they are
connected) and prefer solution (2). The other caver (especially one infected
by OOP <g>) may say that the side passage doesn't inherit special properties
because it contains only discrete Station Names, Azimuts, Inclinations and
Distances which aren't related to the main branch. She / he would keep the
data of the new passage in its own bunch and only link the surveys (3).
My own experience is that most surveying software already allows (1) and
(3). Survex links the data with its "*equate" command, Compass uses the
Project Manager to put things together and other programs identify a link
because the linking station has the same name in both surveys. I don't know
a program which uses surveys, sub-surveys and sub-sub-surveys like in model
(2).
I prefer solution (3) also because it keeps the structure of the xml file
rather "flat" and easy to read for humans and easy transformable into other
file formats (native / proprietary file formats of survey software,
relational databases etc.).
> Please take some time, kick it around and respond with your thoughts.
Done! :-)
Roger
--
Roger Schuster eMail roger_at_r-schuster.de
Cavepage http://www.karst.net
The very first "Point and Click" technology - a Smith & Wesson!
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET