From: martinl_at_talk21.com
Date: Thu Feb 08 2001 - 02:53:28 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA23527 for cavexml-outgoing; Thu, 8 Feb 2001 02:56:33 +0100 Received: from t21mta01-app.talk21.com (mta01.talk21.com [62.172.192.171]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA23523 for <cavexml_at_cartography.ch>; Thu, 8 Feb 2001 02:56:32 +0100 From: martinl_at_talk21.com Received: from t21mtaV-lrs ([10.216.84.18]) by t21mta01-app.talk21.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20010208015516.QIQF20154.t21mta01-app.talk21.com_at_t21mtaV-lrs>; Thu, 8 Feb 2001 01:55:16 +0000 X-Mailer: talk21 v1.12 - http://www.talk21.com To: cavexml_at_cartography.ch, cavexml_at_cartography.ch X-Talk21Ref: none Date: Thu, 8 Feb 2001 01:53:28 GMT Subject: Re:Groupings Message-Id: <20010208015516.QIQF20154.t21mta01-app.talk21.com@t21mtaV-lrs> Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Although this thread has at times seemed to be getting rather twisted, repetitious, and occasionally more relevant to the cave-surveying list than to this one, it is good to see some agreement on:
1: the need to define intrinsic data groupings in terms of elements/entities and attributes informed by, but not controlled by, experience of the capabilities,
or deficiencies, of existing procedures and processing applications
2: the seperation of information (structured data) from views of that data
However, I think there are some points either not raised or being forgotten, so here's some more food for thought:
a) While [from to distance bearing inclination]* (where I use the [] to indicate that the order is immaterial when expressed in XML as either as attributes or subelements) must be the most common form of basic recorded data, we have had examples of at least one other form, viz diving data [from to distance bearing depth], which would, I think, also be the format for a levelled survey. There was also that stuff about just using distances - I forget its name...
b) If the same survey method applies to a set of readings (eg 'all readings are forward' or 'all readings are leapfrogged') the data could be reduced to [distance bearing inclination]* or [distance bearing depth]*, provided also that the readings are in sequence. The station names are only 'real' for permanently marked stations, otherwise they are convenient but not essential.
c) Raw readings may not be available at all either because the surveyors won't release them (as is the case for at least one significant cave in Wales) or because only historic drawn-up surveys exist (maybe a lost cave
discovered by miners or a cave where access is denied). In these cases, as well as with 'surveying machines' like that used at Wakulla Springs last year the 'raw' data available to be interchanged is likely to be as 3D coordinates: [point E N V]* or [E N V]*. Stations fixed by GPS, radio-loaction etc also come as coordinates in 'standard' instrument surveys.
d) A third possibility is that only cross-section data [point orientation cross-section]* needs to be passed
to produce a 3D model...
e) While there has been a lot of discussion devoted to asserting that interchanged data should be as nearly as possible unprocessed, I see no reason why processed data should not be interchanged as well. It would need to sit in its own grouping with something to identify the processing it had undergone (it has already been suggested that the program (better: a sequence of processes) used to produce
the dataset be recorded). A serious question is whether there is any need to seperate raw readings from the coordinates produced from them, or whether there is any merit in combining the two in one file. Current processes usually (always?) use seperate files (and file types) for input and output. Why might you want both together: coordinates alone give no indication of the topology of the cave; from and to (together with the coordinates having station identifiers), determine the connectivity if the information is ever to be used to draw survey lines.
f) Talking of topology, I think that is what prompted the Toporobot rules on data grouping. A cave could be described just in terms of the number of 1-nodes (entrances, & passage ends) and n nodes (where n>2) it has. (The case of a 2-node is special: it is an ordinary mid-passage station not at a junction - in survey reduction it drops out of consideration for closing loops). So, Toporobots's rules were for probably imposed for processing convenience but they also reflect a real unit of the cave, a non-branching passage. A cave is a set of non-branching passages joined at junctions. We could do with a good term here! Tube is a possibility, as is tunnel, or pipe; arc fits the
topological theme but is too theoretical in tone; passage itself suffers from its tendency to be used to designate a set of 'tubes' which form a morphological unit off which other passages branch ('... Main Passage continues beyond the connection to the Streamway on the right until it chokes after ...').
g) Part of Mike Lake's intention before he discovered XML was to describe (and then perhaps interchange) not so much the survey data (raw, processed or any mixture) as data on how to produce a 2D drawing of the cave. As such, that might involve literally passing data on line features (walls, drops, etc), area features (sand, gravel, water...), point features (stal, fixed stations, ...), text, ... We could include that in the remit of 'CaveXML', or could decide that Scalable Vector Graphics (maybe
with input from Geographical Markup Language) seems
admirably fitted to that end, and treat interchange of drawings as a sub-project.
Martin Laverty
--------------------
talk21 your FREE portable and private address on the net at http://www.talk21.com
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET