Garry Petrie wrote:
> Ralph Hartley wrote:
>
> I agree with what Ralph has written in this message.
>
>> The more I have thought about CaveXML, the more I am drawn to the
>> conclusion that the primary element must be the station, not the shot.
>
> I would add that equally shots and stations are primary data elements.
> Even surveys that don't record stations must do so at junctions to
> connect the network. From a database application point of view, shots
> between the same stations would have records with a different ID.
I have to admit that my statement above is slightly stronger than what I
actually believe. Of course you can't have a survey without both
stations and shots (or at least measurements). I really mean that
stations are *as* important as shots.
I am trying not to express any opinion at all on IDs for shots. I think
shots (and other things as well) should at least have an optional ID
field. I can't see making it mandatory, because some programs might not
even aggregate measurements into distinct "shots" at all. On the other
hand, most stations will be referred to from more than one place in the
file, so all stations really do need an ID so that it can be referred to
uniquely.
What I am really arguing against, and will not accept, is a format in
which stations only appear as "from" and "to" attributes in shots, and
they just contain the "name" of the station. This might be how they are
written in survey books, but the surveyors have a lot of context
information (they know how their survey assigns names etc.) that makes
the survey books unambiguous to them, but without which a file, exported
to a different program on a different continent, would be gibberish.
>
>> The down side of this is that the CaveXML file contains elements that
>> don't come directly from the survey book. An editor, when a shot is
>> added, needs to check if the stations already exist. If so it uses
>> the old id for the station, otherwise it needs to generate a new
>> station element.
>
> I don't think we want to recommend editing CaveXML with a generic text
> editor.
But some people on this list have said they would like to use a rather
generic "XML editor". I don't want to make it harder to do what they
want to do, at least not without reason. Presumably such editors,
knowing (from the DTD or schema) that the "to" and "from" elements or
fields contain IDREFS, would know that there has to be a matching ID
somewhere. I don't know if such tools (which I have never personally
looked at) make it easy to automatically add a station element when needed.
Along with editors, conversion programs would also need to generate
station elements with unique IDs for each station. They may also need to
record in the file the names they use for each station, but that would
not be required.
> I like the idea of unique IDs within a file, for both shots and
> stations. Can we convince those cave data format in which names are
> context based (survex) users to adopt this idea?
At least for stations, and as an option for shots, I'm going to try.
It's the only way I see to make their programs inter operate with other
approaches without forcing anyone to change their basic structures.
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST