From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Thu Feb 08 2001 - 19:52:46 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA32171 for cavexml-outgoing; Thu, 8 Feb 2001 19:49:08 +0100 Received: from sun0.aic.nrl.navy.mil (sun0.aic.nrl.navy.mil [132.250.84.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA32167 for <cavexml_at_cartography.ch>; Thu, 8 Feb 2001 19:49:06 +0100 Received: from aic.nrl.navy.mil (pc31.aic.nrl.navy.mil [132.250.84.181]) by sun0.aic.nrl.navy.mil (8.9.3+Sun/8.9.3) with ESMTP id NAA19188 for <cavexml_at_cartography.ch>; Thu, 8 Feb 2001 13:49:41 -0500 (EST) Message-ID: <3A82EAFE.10900@aic.nrl.navy.mil> Date: Thu, 08 Feb 2001 13:52:46 -0500 From: Ralph Hartley <hartley_at_aic.nrl.navy.mil> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010124 X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: defaulting units for measurements References: <3A6DD46C.5C6B291E_at_earthlink.net> <3A6EA342.628CEB2D_at_speleonics.com.au> <3A723FA2.F1D861DC_at_xmission.com> <3A74F69C.1010105_at_earthlink.net> <3A824ABC.1ED5C22B_at_xmission.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Paul & Eleanor wrote:
> measurement type="inclination"
> manufacturer ="Suuntos" owner="Paul Hill" manufacturer="..."
> resolution=0.25 units="degrees">
> <!-- resolution (to what measurement the device was read)
> and units are the useful bits for numerical processing
> the rest is for historical, searching and
> data selection purposes only>
> measurement type="distance" instrument="Fiberglass Tape" ...
> resolution=0.25 units="Decimal Feet">
> measurement type="azimuth" resolution="0.5" units="degrees">
> <!-- I'm running with the format suggested by Richard Knapp --!>
> <shot>
> <from value="1"/>
> <to value="2"/>
> <azimuth value="22.5"/>
> <distance value="3.3"/>
> <inclination value="-45"/>
> </shot>
> <!--
> so now what can I do if someone reads the wrong side of the
> clinometer
> --!>
> <shot>
> <from value="2"/>
> <to value="3"/>
> <azimuth value="22.5"/>
> <distance value="3.3"/>
> <inclination value="-100" units="Percent grade">
> <note type"survey blunder">
> What an idiot! Paul obviouly read the wrong scale on the
> instrument!
> </note>
> </inclination>
> </shot>
> ...
> </measurement>
> </measurement>
> </measurement>
Don't use the word "type" for the name of a field. Too many things have
types. How about "modality"?
Also, "measurement" is not the right name, because it gives information
about many measurements; it is not itself a measurement. I would use a
"measurement" element for a single measurement.
<property modality="left" resolution="1" units="feet" at="from" facing="to">
<property modality="inclination"
instrument ="climometer" manufacturer="Suunto" owner="Paul Hill" serialnumber="..."
resolution=0.25 units="degrees">
<!-- resolution (to what measurement the device was read)
and units are the useful bits for numerical processing
the rest is for historical, searching and
data selection purposes only>
<property modality="distance" instrument="Fiberglass Tape" ...
resolution=0.25 units="Decimal Feet">
<property modaility="azimuth" instrument="compass" <!-- compass is default for azimuth anyay --!> resolution="0.5" units="degrees">
<group level="shot"> <!-- A shot is just one way to group data, some programs care, some may not --!>
<property from=<station name="1"\> > <!-- Syntax for an element as value of a field? --!>
<property to=<station name="2"\> >
measurement modality="azimuth" value="22.5"/>
measurement modality="distance" value="3.3"/>
measurement modality="inclination" value="-45"/>
measurement modality="left" value="6"/>
</property> <!-- end of to --!>
measurement modality="up" value="1">
measurement modality="down" value="0">
</property>
</group>
...
</property>
</property>
</property>
</property>
"property" is not quire the right word either. Maybe "defaultset" would
be better.
The program using the data needs to know about all the modalities it can
deal with, but need not pay any attention to the property elements at all.
The parser does not need to know anything about what modalities are
defined, or what they mean. However, when asked for the value of a field
of a measurement, if the measurement has no matching field, it must
return the value specified in the innermost nested property element with
either the same modality as the measurement, or no modality at all.
So in the example, the "left" measurement will effectively have the same
fields as if it were written:
measurement modality="left" value="6" to=<station name="2"> from=<station name="1"> resolution="1" units="feet" at="from" facing="to"/>
Of course if the program wants the original structure it can have that
as well.
>
> Note: the type tag of a measurement would be defined to allow exactly
> the
> set of first level elements that appear inside of a <shot> element
> with the possible exception of cross section information.
> See comment below grouping cross-section information into one
> measurement
> type.
>
> This technique allows you to, if you need to.
>
> 1. override individual units per measurement for just that measurement.
> 2. Change to a different instrument even within the same 'survey'.
> 3. Mix different instruments (but I haven't addressed that interesting
> problem of joining air filled passage surveys to underwater surveys).
> 4. It leaves open the door for extensions, for example a measurement
> tag for laser range finder measured cross-section (to reuse the
> extension example already mentioned in another thread).
> 5. It doesn't require list of units on every shot.
>
> But doesn't require any more bits on a shot than the minimum
> required to convey the data.
>
> With this scheme I notice that now the concept of survey does become
> something of non-struture, there is only the concept of sets of shot
> taken with the same measurement equipment, personel etc.
> So maybe this IS a case where the obvious grouping of
> <survey> does become imaginary (even if I just posted something
> that denied the existance of imaginary groupings :-).
>
>
> A measurement type tag would allow all of the same tags as a shot
> (easy to do in DTD, I assume in a schema also).
>
> What happens if measurement type="inclination" ...> is nested in
> another <meaurement type="inclination">?
>
> I'd assume the inner one always takes precedence, thus allowing an
> alternative way to override not just one shot, but smaller group
> of shots.
>
> By the way, for LRCF you could have.
> measurement type="LRCF" resolution=0.25 units=meters>
> <!-- the cross sections were estimated to the nearest 0.25 meters --!>
>
> If we use this method, someone would have to work out what is the
> right interpretation of:
>
> measurement type="distance" instrument="Fiberglass Tape"
> owner="John Halleck" reader="John Halleck"
> resolution=0.25 units="Decimal US Surveyor Feet">
> <!-- here comes the idiot Paul misreading the wrong scale again! --!>
> measurement type="distance" units="meters" reader="Paul Hill">
> ...
> <!-- so are the measurement here still with a John's Fiberglass
> Tape read to
> the nearest 0.25 feet, or is this second measurement tag an error
> because it
> is incomplete --!>
> ...
> </measurement>
> ...
> </measurment>
My version woild be:
<property modality="distance" instrument="Fiberglass Tape"
owner="John Halleck" reader="John Halleck"
resolution="0.25" units="Decimal US Surveyor Feet">
<!-- here comes the idiot Paul misreading the wrong scale again! --!>
<property modality="distance" units="meters" reader="Paul Hill">
...
measurement modality="distance" value="5"/>
<!-- This is equivalent to
measurement modality="distance" value="5" instrument="Fiberglass Tape"
owner="John Halleck" resolution ="0.25" units="meters" reader="Paul Hill"/>
which is still a little tricky. The resolution should be 0.25 feet but might be interpreted as 0.25 meters, it isn't really right to assume that resolution is in the same units as the measurement itself.
--!>
...
</property>
...
</property>
Ralph Hartley
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET