From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Tue Jun 25 2002 - 22:20:38 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 3BA7214ACD for <cavexml-outgoing_at_ethz.ch>; Tue, 25 Jun 2002 22:39:23 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 1809814A44; Tue, 25 Jun 2002 22:39:21 +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 BBDB214ACD for <cavexml-loopcheck_at_ethz.ch>; Tue, 25 Jun 2002 22:39:19 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 99CF114A3E; Tue, 25 Jun 2002 22:39:17 +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 39E0714ACD for <cavexml_at_cartography.ch>; Tue, 25 Jun 2002 22:39:17 +0200 (CEST) Received: from relay1.melbpc.org.au (unknown [203.12.152.9]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id A916214A0F for <cavexml_at_cartography.ch>; Tue, 25 Jun 2002 22:39:13 +0200 (CEST) Received: from localhost.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by relay1.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g5PKKMQO095391 for <cavexml_at_cartography.ch>; Wed, 26 Jun 2002 06:20:22 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 26 Jun 2002 06:20:38 +1000 From: Peter MATTHEWS <matthews_at_melbpc.org.au> In-Reply-To: <20020624141426.7999614ACD_at_karmail.ethz.ch> Message-Id: <5.1.0.14.1.20020626060316.01d76400@popa.melbpc.org.au> Received: from relay1.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by localhost.melbpc.org.au (AvMailGate-6.13.0.2) id 95388-5276CABD; Wed, 26 Jun 2002 06:20:03 +1000 Received: from peter.melbpc.org.au (a2-12.melbpc.org.au [203.12.157.12]) by relay1.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g5PKJxsm095382 for <cavexml_at_cartography.ch>; Wed, 26 Jun 2002 06:20:01 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) References: <5.1.0.14.1.20020620051819.01d78ec0_at_popa.melbpc.org.au> Subject: Re: Progress report - cave survey data model To: cavexml_at_cartography.ch X-AntiVirus: OK! AvMailGate Version 6.13.0.26 at relay1.melbpc.org.au has not found any known virus in this email. X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Sender: matthews_at_popa.melbpc.org.au 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
Sorry, Richard, I should have been a bit clearer in my email. The things I
listed were just the draft names of the "entities" I have included, i.e.
the things or events which we want to record data about. They are not the
fields, but each of them will have several fields. When I post the draft
for discussion, the draft definitions of each entity will of course be
included, because that is what we will need to discuss, as well as of
course their names.
Once we are happy that we have included and defined all necessary entities
and the relationships between them, then we can start deciding which fields
belong to each entity and define these fields. Then we will be in a
position to set out the XML to describe all this, and to discuss things
like whether a particular field should be expressed as an XML attribute or
an XML element.
And of course it doesn't help that XML uses the terms "attribute" and
"entity" in a different way to database terminology!
Peter
At 05:40 24-06-02 -0400, you wrote:
>Peter,
>
>An excellent start. Some ramblings....
>
>On the next draft, could you include some simple definitions for the
>elements? There are
>some elements that appear unrelated (Spur, Segment, etc).
>
>(Again, just ramblings.)
>
>
>Will "Name" (for Branch, Cave, etc) be made an attribute or an element?
>
>Comment seems to be missing.
>
>Will Coordinate data be stored as and attribute of a Station or as a
>Point? One of the
>problems I have with COMPASS is it never displays the actual error it
>finds on loops; all
>loops are assumed closed because it has no way to hold multiple end points
>for a single
>station. Karst had a nice feature of showing the non-aligned points and
>then drew dark
>blue, dashed lines between lines the points. Coodinate data would also be
>useful for
>locating the Entrance.
>
>Will Measurement hold all shot attributes (length, direction, azimuth,
>etc.)? That's a
>rather clean way to hold the information.
>
>How about passage dimensions? Will they be put as a measurement or
>something else? I
>think it would be good to allow people to measure passage dims with
>spherical coordinates
>if desired. One of the problems discussed on CaversDigest was taking LRUDs
>at a pit or
>other very high angle/incline shots. There really is no Left or Right
>since the survey
>line goes straight down. LRUD could still be used but it would just be
>shorthand for 90
>deg off the last shot at zero inclination. If the surveyor wanted other
>dimensions
>recorded (for solid modeling or whatever), they could be added:
>
> azimuth = "135" incline="+45" distance="10.5"
> azimuth = "215" incline="-45" distance="40"
>
>It is like having spray shots for passage dimensions. If such information
>is associated
>with a Shot element, then having the reference point specified would be
>necessary as well
>(at="").
>
>Would survey date (or processing date) be a separate element or attribute?
>
>Declination?
>
>I see Person but not Role/Job/Position. If those items are just an
>attribute, then a
>survey member can only have one position during a survey. However, there
>are many times
>when one person does many things: sketch, backsights, and lead tape or
>frontsights and
>inventory.
>
>Will things like Book Format (one or two line data collection), Tape
>Method, BackSight
>Method, PassageDimensions, etc. be put under the Survey as attributes? Or
>will these be
>under Method?
>
>Will there be a way to specify the order and units of each data item? This
>would be
>similar to the FORMAT directive in COMPASS and would allow the "view" of
>the data to
>alter without effecting the DOM. Specifying units with each measurement
>removes any
>implied units and the need to include on each measurement element.
>
>Will there be a Survey header to collect all the header info and keep
>those elements
>separate from the Data section or will it just be Survey?
>
>Should consideration be given now to simple "inventory" data like
>temperature, wind
>velocity, humidity? If a precision survey is being done (theodelite),
>temperature may be
>required to process the data.
>
>What is the root element? I thought there was some agreement that a
>CaveXML element would
>exist containing version information.
>
> > To give you an idea of what I will be covering in the initial draft, here
> > are the entities currently included. Of course their names will also be
> > subject to discussion. If I have left out any obvious entities please let
> > me know by return so I can include them in the first draft.
> >
> > Branch
> > Cave
> > CaveSystem
> > Fieldbook
> > Instrument
> > Interpoint
> > Leg
> > Map
> > Measurement
> > Method
> > Node
> > Organisation
> > Person
> > Point
> > Project
> > Role
> > Segment
> > Shot
> > Spur
> > Station
> > Survey
> > Team
> > Technique
> > Trip
This archive was generated by hypermail 2b30 : Wed Jul 10 2002 - 21:35:00 CEST