From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Thu Feb 22 2001 - 21:07:36 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA25771 for cavexml-outgoing; Thu, 22 Feb 2001 21:04:15 +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 VAA25767 for <cavexml_at_cartography.ch>; Thu, 22 Feb 2001 21:04:13 +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 PAA01687 for <cavexml_at_cartography.ch>; Thu, 22 Feb 2001 15:04:07 -0500 (EST) Message-ID: <3A957188.8010309@aic.nrl.navy.mil> Date: Thu, 22 Feb 2001 15:07:36 -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: Stations are primary References: <3A91BC7D.7060804_at_earthlink.net> 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
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.
The main point is that stations have names, and may need to be referred
to from many places, but shots are almost never named except by the
stations they connect. While might be desirable to have an independent
unique id for each shot, for stations it is indispensable.
Representing stations as a field who's value is the station's name
doesn't deal with one station with many names, or multiple stations with
the same name.
Also, different programs may each need to have their own names for the
stations, and the names may not be compatible (one may require names to
start with a letter, another may use numbers only), or the names might
overlap (foo and bar both have a station named "1" but they are
different stations).
Here is a piece of a DTD:
<!ELEMENT Station (#PCDATA|SationName|Equivalent|Location)* >
<!ATTLIST Station id ID #REQUIRED>
<!ELEMENT StationName EMPTY>
<!ATTLIST StationName
station IDREF #IMPLIED <!-- may be omitted only if nested
within a Station element --!>
namesystem IDREF #IMPLIED <!-- if present tells what set of
names this name belongs to.
Redundant if nested within a
NameSystem element --!>
Value CDATA #REQUIRED>
<!-- Names don't have to be unique. The NameSystem element is intended
to allow
a particular set of station names to be used, e.g. by conversion programs.
A particular program can use the namesystem attribute to identify what
name it wants to
use for each station. There are other ways to do this, but it must be
done. --!>
<!ELEMENT NameSystem (#PCDATA|StationName)* >
<!ATTLIST NameSystem
id IDREF #IMPLIED
name CDATA #IMPLIED>
<!ELEMENT Equivalent EMPTY> <!-- specifies that two station elements
represent the same actual
station. This is totally independent
of having the same name. --!>
<!ATTLIST Equivalent
station IDREF #IMPLIED <!-- may be omitted only if nested
within a Station element --!>
target IDREF #REQUIRED>
<!ELEMENT Location EMPTY>
<!ATTLIST Location
station ID #IMPLIED <!-- may be omitted only if nested
within a Station element --!>
<!-- insert all other attributes relevant to measurements
(units etc.) here --!>
Northing CDATA "0" <!-- default might not be good idea --!>
Easting CDATA "0" <!-- do only numbers make sense? --!>
Elevation CDATA "0">
<!ELEMENT From (#PCDATA)*>
<!ATTLIST station IDREF #REQUIRED>
<!ELEMENT To (#PCDATA)*>
<!ATTLIST station IDREF #REQUIRED>
Here is an example fragment:
<Station id="2">
<StationName Value="FOO1">
</Station>
<Station id="1">
<Location Northing="0" Easting="0" Elevation="0">
<StationName Value="FOO2"
</Station>
<StationName station="1" value="datum"> <!-- another name for FOO2 --!>
<!-- But program bar doesn't allow letters in station names, it needs
its own names. --!>
<NameSystem name="bar">
<StationName station="1" Value="002"> <!-- aka "FOO2", aka "datum",
id is "1" --!>
<StationName station="2" Value="001">
</NameSystem>
<Shot> <!-- from FOO1 to FOO2 --!>
<From station="2">
<to station="1">
...
</Shot>
Alternatively, From and To could be attributes with type IDREF. That
depends on how grouping and default values for measurements are done,
which is an orthogonal issue.
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.
The up side is that all this is very easy to generate automatically.
Starting with unique station names, it is easy to generate station
elements using those names for both the id and a name. If data comes in
from different sources, name collisions don't cause a problem because
the station ids can be reassigned from scratch (they are strictly local
to a file) without loosing track of any of the old names.
I don't see a real need for the station id's to follow any particular
pattern, sequential numbers, globally unique identifiers etc., but of
course that is permitted, or they can be added as another set of names.
All that is *needed* is that ids be unique within one file. Stations in
other files could be handled by a station element that contains a
reference to the other file; within this file it would be referred to by
its local id.
With stations as first class elements, there is also very little
standing in the way of including processed data. In fact the only thing
needed is a way to mark that a set of elements *is* processed data, (and
who processed it, and how). The most important data is the locations of
stations and a set of shots (a graph or tree), and we need both of those
to describe the raw data anyway.
Ralph Hartley
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET