devinkouts@earthlink.net wrote:
> We're all on the same page. If you want to stuff your post processing
> data back into the original data file in one neat package that should be
> o.k. XML is extensible like that. But that's exactly the point. Those
> kinds of construct are "extensions".
But to me it is the processed data that is basic!
If including processed data is not easy enough, or standard enough, that
most converters (at least optionally) convert it, then I have no use for
or interest in CaveXML. From my point of view (which may very well be a
minority of one, but shouldn't be), the whole PURPOSE of CaveXML is to
facilitate the transfer of processed data.
Screw the raw data! Carto doesn't need that anyway.
I suppose if people want to include raw data, they can define an
extension that allows it, but I wouldn't want to let the basic format
get bogged down in all the features that would imply. After all
different groups of surveyors use different techniques to record
different information, and they organize it in different ways. If the
format is to support all of them, it could be very cumbersome.
OK OK so maybe an alien intelligence took over my keyboard for a minute.
I don't actually hold all of the opinions expressed above, at least not
in such an extreme form.
> We haven't even solved the
> fundamental issue of what goes into the basic data storage file and
> we're already trying to incorporate, closed loops, calculated cartesian
> coordinates, etc. What's next, stick the CaveMapXML tags into CaveXML
> too?
Actually processed data requires little or nothing to be added to the
format. Lets look at what is really needed:
A) Some way to describe the provenance of the data. I don't know if we
have discussed this but the source of the data is an integral part of
the data (perhaps the most important part). So you need something
(vaguely) like:
<source name="Devin Kouts" URL="http://www.psc-cavers.org/kouts">
<source program="Compass" converter="Compass2XML">
<source description="Notebook found under a rock">
... data from Devin, that he claims was found under a rock, entered
into Compass, and converted with Compass2XML ...
</source>
<source name="GVKS">
... more data from Devin, that he claims came from GVKS, and was
processed the same way ...
</source>
</source> <!-- This might want to be "Flatter" but --!>
</source> <!-- the idea is that each "pair of hands" the data passes
through should add a layer of nesting --!>
If you agree something like this is needed (it is essential) it is easy
to allow:
<source program="Compass" state="unclosed" > <!-- state is one of
raw(default), unclosed, or closed --!>
B) A way to specify the coordinates of stations.
<Location easting="23" northing="-127" elevation="6.2"/> <!-- if not
nested in a station element needs to specify one --!>
We need that even for raw data, because data from outside sources will
often be in that form.
C) A way to specify a "tree" of shots. This could be done several ways,
but a simple standard could be a preorder list of the shots. I think we
all agree that the format needs to support lists of shots (that's what
the raw data is).
For "basic" processed data, that's all we need. Some might want to add
more (covariance matrices, etc.), but ALL survey programs produce data
that can be boiled down to that fairly easily.
> Before we get too wrapped up in what "else" we can put in CaveXML maybe
> we should solve what goes "first" into CaveXML.
Processed data comes first for me, because that's what I need. You
already have a way to exchange raw data (re enter it by hand), but there
is currently NO way to convert the output data. (There's the alien again
:-).
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST