From: Paul & Eleanor (goodhill_at_xmission.com)
Date: Mon Feb 12 2001 - 09:05:08 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id JAA05228 for cavexml-outgoing; Mon, 12 Feb 2001 09:01:34 +0100 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA05224 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 09:01:33 +0100 Received: from slc378.modem.xmission.com ([166.70.2.124] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.12 #1) id 14SDvR-0001Si-00 for cavexml_at_cartography.ch; Mon, 12 Feb 2001 01:01:34 -0700 Message-ID: <3A879934.44D4C90D@xmission.com> Date: Mon, 12 Feb 2001 01:05:08 -0700 From: Paul & Eleanor <goodhill_at_xmission.com> X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Finding groupings References: <200102081326.OAA29149_at_karto.ethz.ch> <3A85A949.1DCBD783_at_xmission.com> <3A8617A3.1050504_at_europa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Garry Petrie wrote:
>
> Paul & Eleanor wrote:
>
> >
> >> Are the names part of the survey data or how we look at the survey data?
> >
> > Did you not read my posting? I was talking about rooms and pits and
> > sections, and ... It is all part of the survey data! Rooms names,
> > passage names, area names, are things known by the folks who work
> > the cave. How you separate out, some subset of data to form a data
> > view is the choice of someone _consuming_ the data, hopefully the
> > user of the data can use these groupings to form such 'views'.
>
> I do not think Paul really understands the problem. Consider the case
> of Carlsbad Cavern,
> which has been surveyed several times over, by different people, with
> different methods.
Yes, I am aware of such scenerios.
> While Paul might like to group all of the data collected in the "Big Room,"
I NEVER SAID ALL DATA IN A GROUP HAS BE NEXT TO ONE OTHER.
The other day you were worried about repeats of data, now you are saying
I
want to move the shots. The only thing that repeats is the name. The
order
of the points is up to you.
> another
> perfectly useful data set would be the paved trail from the entrance to the lunch > room and
> around the Big Room.
"Around the Big Room" Now how were you doing to put this is the data
without
a tag that says "thus begins some data in what we call the Big Room".
That
is pretty much all I am talking about.
By the way I love your examples, because you are talking about shots in
named areas of the cave. Since you and everyone else does this, I
expect
to find such names in the data somewhere.
> Another data set would be the theotolite (sic) survey from the
> entrance to the elevator in the Big Room, which generally does not share stations > with the
> paved trail. Even within the Big Room with tape and compass surveys, their dates > might be
> twenty years apart and you need to account for the magnetic declination for each > shots.
I think the big problem now is that you seem to be assuming some
exclusive, one time use of names. Do not assume that. My posting
showing how two named sets that overlapped could be worked out
showed redundant use of names, so I don't know from what you are
creating
this assumption. As to mention of date, you are right and I'm surprise
John Halleck even repeated my mistake as an example, since he has
slapped me around with this problem on more than one occasion in the
last 20 years. Dates are not just an interesting piece of historical
data, like the name of something. Dates effect the data, so
maybe dates should not ride with this <group> tag. They go more with
the survey/measurement definitions.
But since there is nothing exclusive about the use of a name
<group name="Big Room" date="1970-07-05">
....
</group>
<!-- 100000 lines later :-) -->
<group name="Big Room" date="1998-8-12">
...
<group>
you could actually allow dates on groupings, but I'm leaning
away from it, so as to make grouping just a naming device.
I re-read my postings and realized I did say (before I posted the bit
about
the separate measurement tag) that attributes of surveys _might_ apply
to
everything in the same set, thus suggesting the name tag was more
closely
tied to a chunk of survey. This discussion has convinced me
that there should be less of a connection between a named section and
any survey attributes that happen to be current in a particular
section of the file.
By the way, numerical attributes COULD apply to all shots in a group,
and all your examples would just be several different groupings, just as
you want. But ignore the idea of connecting measurements attributes
with
named groups, because as you say and I say too,
the sets of shots and points that take the same attributes of
measurement
do not even come close to being the same as a typical name. In little
caves
room names are smaller than a days worth of survey, while in something
like "The Big Room", the room name would apply to various groups of
shots.
> Excuse me, is not the software user in fact the caver we are talking
> about?
No there may be other software users, after all we are talking about
exchanging the data with others.
>We're all for preserving the data, in as original form as possible.
I believe that is still in debate. CaveXML might have a standard form
for units for example. End users of the data probably would find that
useful.
> What we absolutely do not want to do
> is introduce a particular data struction into CaveXML that implies a method
> of processing at the expense of some other method or unforeseen requirement.
Naming sections of data do no such thing. Please describe any such
methods of processing that you think are implied by
<group name=" " type=" ">
</group>
I will continue to demonstrate that I think you must be making some
extra
assumptions. May I suggest when you do think of one, you ask if I was
assuming
such a thing, instead of accusing me and thus putting me on the
defensive.
Work out what I am trying to describe, then blow it out of the water.
By the way, I am fully aware of multiple surveys through the same
passage,
room, etc. There are even cases of multiple surveys that use the same
points.
The only thing I am assuming is that when any processing software
sees <group name=" " type=" " > it means that all of whatever is within
the group, i.e. before the closing </group> tag, can be referred to by
the type/name pair defined as the attributes of that group.
Nested groups? That introduces an additional name, now all points
could be referred to by either type/name pair that is now in scope.
A group within a group is a convenience of the markup language, not an
implied hierarchy of names. For example:
<group name="Entrance Room>
...
<group name="Connection Pit"
...
</group>
...
</group>
...
<group name="Lower Level">
...
<group name="Connection Pit">
...
</group>
...
</group>
Both sets of data with the name "Connection Pit" should be returned
if someone says, "send to my friend all of the Connection Pit", or
"Let's look at which station was used to make the loop connection
in the Connection Pit", or "Please plot the Connection Pit", or
"Can you tell me who surveyed the connection pit?"
Someone else can work out the a good XSL/XSLT definition for the
case "Let's show the walls of the Entrance Room, excluding anything
going down the Connection Pit" :-)
Yes, in a relational database group names would be off in another
table with foreign keys into tables defining points or shots etc.,
but the relational model is another problem for another day.
-Paul
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET