From: devinkouts_at_earthlink.net
Date: Wed Feb 07 2001 - 22:34:13 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA22545 for cavexml-outgoing; Wed, 7 Feb 2001 22:31:17 +0100 Received: from [209.70.170.131] (brick.cist.saic.com [209.70.170.131]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id WAA22541 for <cavexml_at_cartography.ch>; Wed, 7 Feb 2001 22:31:12 +0100 From: devinkouts_at_earthlink.net Received: from cist.saic.com by [209.70.170.131] via smtpd (for karto.ethz.ch [129.132.127.159]) with SMTP; 7 Feb 2001 21:31:51 UT Received: from earthlink.net (unverified [10.43.39.246]) by exmail.cist.saic.com (EMWAC SMTPRS 0.83) with SMTP id <B0000717437_at_exmail.cist.saic.com>; Wed, 07 Feb 2001 16:33:00 -0500 Message-ID: <3A81BF55.B4CBA3F6@earthlink.net> Date: Wed, 07 Feb 2001 16:34:13 -0500 X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: RE: Groupings 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
>> 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.
Roger, thank you for your wonderful responce. You've brought to light
significant issues that we need to address and understand collectively
before we can make real progress.
First off, you've illuminated a practice that has actually brought us to
the situation we are in today. Specifically, software programs that
place constraints on the way in which surveys are done. You're right,
some software products only allow numeric values, or limit station names
to eight characters, or combine values to create stations. And I hate to
be the bearer of bad news here but, "that's just not good software
engineering practice".
Before I get a bunch of flame mail let me just say that I understand why
things get built the way they are, development envirnoment limitations,
software efficiency considerations, user requirements, and even
developer skill limitations. But none of these are an excuse for making
outdated design the "status quo". Good applications are always evolving
and keeping pace with best practices in software development. That's why
I gave up on SMAPS and went to WinCompass. GUI's rule.
>How should we ever import a xml file created with Walls (only an
example)
>into a software which can't handle alphanumeric station names?
If Walls (or any other app) creates a data file that complies with the
CaveXML data model then it's not CaveXML's problem if another
application can't read it. If Larry Fish (for example) refuses to
advance the capacity of Compass to handle long station names, and people
like to use long names, then his product fails to meet the needs of his
users. This is not a failing in CaveXML. It's a short coming of Compass
(or any other software application).
>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.
Those remarks are all right on the money. If an application doesn't
understand what it is receiving then it must modify what it receives
into something in can understand. Sounds rather kludgy, huh? At some
point it becomes a decision on the developers part, "do I invest
development time building bridges between my proprietary data model and
the Internationally accepted CaveXML standard, or do I just learn to
read and write the CaveXML standard natively"?
>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?
I submit that Toporobot should understand not only station 5/11 but also
AB11. It's a design issue in Toporobot that it can't understand
alphanumeric station names. Similarly WinKarst or Compass should be able
to understand not only AB11, but also 5/11 (a concatination of survey
identifier and station identifier). Again, the fact that this is not
currently the case was a design decision made by the software developer.
>... 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.
This is another design choice on Larry's part. And to be frank it has no
bearing on the format data is stored in. As long as I can enter the data
in the units I want it to be recorded in, and then later move that data
file to another application and see that the units are exactly the same
as I entered them. That includes opening the data file in Notepad.exe
and editting it if I wish.
>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.
This is a good example of local preferance for the conduct of a survey.
I'll admit to doing it that way, and a myriad of other approaches. The
constructs I offered up earlier are just as flexible as the methods
cavers use to conduct surveys.
>I think it is rather stupid putting anything into the same survey but
any
>caving software I tested so far does support this already.
This gave me a giggle Roger because this model is exactly what you said
you do when you wrote "If I record new data in a passage which is
already partially surveyed I put them into the same survey." This just
goes to show that we really do need maximum flexibility in the way we
organize our data.
>(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
...
>data of the new passage in its own bunch and only link the surveys (3).
> I don't know
>a program which uses surveys, sub-surveys and sub-sub-surveys like in
model
>(2).
The ability to link surveys was a clear requirement from the software
developers I spoke to in December last year. We do in fact create
sub-surveys, we just don't call them that. We merely call them surveys
and we either append them to existing surveys, or link them with an
*equate statement or include them in a project (.MAK) file. The
construct is there, just not as easily recognized as the sequential and
sibling relationships.
>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.).
I'm glad you like it, it actually occured to me as the right thing to do
while I pondered you off list email to me the other day. It's an obvious
construct that you see in use all over the data and software worlds. We
just haven't made use of it in cave survey data representation, even
though we do use it in the conduct of surveys.
To be fully capable of dealing with all the methods of creating surveys
(that I know of anyway), all three of the constructs I discussed would
be needed. And I hope the examples illustrate how incredibly easy the
are to implement.
>Done! :-)
Good job! Thanks for the feedback.
Devin
-- Devin Kouts Caver Systems Engineer www.psc-cavers.org
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET