This page is for recording our progress as we work through the above task. The colour codes shown further below indicate the status. For example, black shows items not yet done, and green shows items now done.

Suggested Plan

• We start with the the Cave Survey data model.
• We sort out any tricky non-entity terms which we may need to use during discussions.
• We start at the top of the Cave Survey diagram and discuss each entity in logical order down the page until all definitions and relationships for this data model are agreed. Only a token number of fields would be discussed during this step - just enough to clarify how the entity would fit in.
• Once we have agreed on each entity's definition and how it fits, it will be updated on this web page and on the diagram to show what we have agreed, and its colour set to "Done". Earlier versions will remain available.
• Decide on the next data model (Cave Topology?), and repeat the above steps.
• Repeat the above steps for the Map data model.
• Move on to Task 6.2: Define the various survey types to be covered initially.
• Move on to Task 6.3: List and define the fields needed in each entity in the model(s).

Contents:

• Preamble
• Entity definitions
• Other definitions
• Entity relationships
• Entity-Relationship Diagram (ERD)  Or 

Cave Survey Data Model

In order to construct a robust CaveXML standard where we don't have to make embarrassing and incompatible changes later when we want to add extensions, we need to understand and agree on the structure of the data involved in a cave survey. Although our initial pilot CaveXML standard will address only a simple commonly used surveying technique, we need to be aware of where the further complications lie, so that when we are designing the simpler pilot standard, we can allow for the seamless inclusion of the extras later.

These definitions and the accompanying diagram attempt to model the data in a cave survey up to the point where the station positions have been calculated. Other models will be needed for cave topology/shape, and for the final graphical output, e.g. the map. The closer our models get to the real-world things involved, the more robust the result will be. There are sure to be further entities needed, but the ones shown should do as a framework for starting the discussion. Of course not all these entities would be used in any given survey, or used by any existing survey reduction program or data transfer - one would just use those entities which currently applied.

Once we have a coherent set of entities and their relationships, then we can determine what fields are needed and what entity they belong to (many survey fields have already been enumerated by various people on their websites). We will also need to define the so-called "business rules", i.e. how to handle things when certain conditions apply, such as when a particular surveying technique is being used. Once all this is done we will be in a stable position to design the XML structures to describe, store and convey the survey data.

Although XML is inherently capable of describing complex data relationships more easily than a relational database can, we should still set it out first using relational database methods because survey data will need to be stored in a conventional relational database at various times for various reasons, i.e. both approaches are needed if our work is to be accepted. It is also better to use the harder method first, so that we know all requirements can be covered.

Nothing is set yet of course - all aspects are up for discussion: the entity names, definitions, relationships, and the diagram.

Cave Survey Entities

"Entities" are the real-world surveying things or events which we want to record data about, and a preliminary list for comment is shown below in alphabetical order. These are the boxes shown in the separate Entity-Relationship Diagram (ERD), which shows how these entities are related to each other. Note that these are different to the "entities" referred to in XML and HTML parlance. The detailed fields belonging to each entity are not being considered at this stage. The set below covers the data model for the survey measurements taken and the positions thereby calculated, though not all surveys will involve all of the entities shown. Where a definition uses terms appearing elsewhere in this list, an initial capital letter has been used for those terms. Comments, examples and a few typical fields for each entity have also been included to give a better feel for what the entity is about.

The Diagram

Each square in the Entity-Relationship Diagram represents an entity. The lines represent any relationships between them which are relevant to our purpose. The label on the line gives some idea of the type of relationship.

Where the line has an arrowhead on one end, it means that one of the entities at the non-arrowhead end may be related to more than one of the entities at the arrowhead end, but not vice-versa. This is called a "one-to-many" relationship. For example, a CaveSystem could contain several Caves but a Cave would not normally belong to several CaveSystems.

Where the line has an arrowhead on both ends, it is called (surprise!) a "many-to-many" relationship. For example, one Cave could result in the initiation of several Surveys over the years, and one Survey could include several Caves.

You can also have a "one-to-one" relationship, where one entity at one end of the line is related to only one instance of the entity at the other end.

The original of the diagram is vector-based in StarOffice 5.2 Draw. It is then exported to GIF format for the web page.

Cave Survey Entity Definitions

The definitions below are being set for our specific CaveXML purpose, and may differ from definitions used for other purposes, i.e. we are not here trying to set up normative definitions for cave survey terms for universal use, though hopefully most of them could serve that purpose anyway.

Discussion Colour Codes: Done | Current | Future

Branch

A survey network element which is a sequence of one or more Legs which join two adjacent Nodes in the network.
Typical fields: node1 name, node2 name, leg(s).

Cave

A single cave which is being surveyed.
Typical fields: name, survey IDs, parent cave system, ...

CaveSystem

A collection of related Caves, or a complex Cave, which is being surveyed.
Typical fields: caves, projects.

Fieldbook

A book or identified collection of documents in which the survey readings were originally recorded during the surveying. It may contain material related to several surveys, projects, and/or caves.
Typical fields: book ID, owner, caves.

Instrument

A specific surveying instrument used during a survey Segment. An Instrument's corrections might change from Segment to Segment.
Typical fields: instrument type, serial number, owner, manufacturer, model, date last serviced, date manufactured, corrections and their dates.

Interpoint

(for want of a better word!)

An intermediate point along a Shot or Leg from which additional observations are taken. Interpoint positions can be determined by their distance along a Shot from a specified one or other Station. An Interpoint does not form a necessary part of the survey network structure. For example, additional cross-sections may have been taken at Interpoints by means of Rays.
Typical fields: station from, distance from station, rays taken.

Leg

The set of final consolidated survey Measurements related to the connection between two adjacent Stations according to the surveying Technique being used. For example, it might be the result of traverse readings with multiple Shots or sightings in one or both directions and averaged readings. A Leg could be the set resulting from the survey measurements, or it could be the statistical set resulting from later adjustment of the network.
Typical fields: station from, station to, distance, direction, vertical angle, segment, averaged yes/no.

Map

A visual representation resulting from one or more Surveys.
Typical fields: map ID, name, size, horizontal scale(s), vertical scale(s), drafter(s), producer(s).

Measurement

A Measurement is one of the fundamental quantities which was used to calculate the position of a target, usually a new Station, from the Position of an existing Station. For example, in a normal tape and compass traverse the Measurements between the two Stations would be: direct distance, horizontal direction, and vertical angle. (Other cases: (1) independently determined, e.g. by GPS, (2) by triangulation, etc). A Measurement can be used in both a Leg and a Shot, though in a Leg, the Measurement may be the result of determining the final (statistical) Position of the new Station.
Typical fields: name, value, units, item type being measured, item being measured, technique, method.

Method

The surveying and calculation method actually used for obtaining the values for one of the Measurements of the survey. For example, the "distance" Measurement could be obtained by any of the following Methods: tape or rangefinder (a direct single measurement), topofil (difference of two readings), stadia staff (two intercepts and a vertical angle), etc. The chosen Method will affect how many values are contained in a Shot. There will be a range of Methods defined, and new ones will be needed from time to time. This is a lookup reference entity rather than containing values from any specific survey.
Typical fields: name, qty of measurements required, instrument types(s) required.

Node

A survey network element which is a Position of a Station which is the meeting point of more than two Legs, or which is otherwise needed in manipulating the network.
Typical fields: name, legs connected.

Organisation

An organisation associated with any aspect of a Survey or survey Project.
Typical fields: name, code, initials, members.

Person

A person participating in any aspect of a Survey or survey Project.
Typical fields: name, contact details, orgs associated with.

Point

A physical point occupied by one or more Stations. It may or may not have a physical marker. It may have multiple sets of Position co-ordinates from its occupying Stations. It may have several names ranging from an official government designation to a series of cave survey station names.
Typical fields: name(s)+ nametype(s), marker type, date marked, person placing mark, org placing mark.

Position

A calculated location for a Station or Interpoint. There may be several Positions for the one Station, each derived from, for example, different Segments and/or adjustment Techniques.
Typical fields: easting, northing, co-ord system used, altitude, height datum used, units, latitude, longitude, station, program, program version, adjustment technique, date calculated, program operator, segment.

Project

A cave/karst survey and mapping project considered to require extended work over multiple Trips and possibly comprising multiple Surveys.
Typical fields: name, date started, leader, org(s) involved, cave system.

Ray

A set of Measurements from a Station or Interpoint to a target point where the latter does not occupy a formal Station. For example, "left", "right", "up" or "down" sightings would each be an example of a Ray where only one Measurement was recorded, the other Measurements and target being implied. A Ray is a specialised kind of Shot which is different enough to warrant its own entity.
Typical fields: ray type, distance, station from, interpoint from, target, horizontal direction, vertical angle.

Role

One of the types of task being performed in a particular survey segment. Examples: compass reader, elevation reader, tape reader, sketcher, recorder, data processor, etc. The key for a Role would be a combined segment+person, with role-type as a field. If the role-type was unknown in a particular instance, this field could be left blank or given a value of, say, "Unknown".
Typical fields: segment used in, person, role name.

Segment

Part or all of a cave/karst survey Trip which is carried out under a single set of conditions such as Team members, Instruments, Technique, Methods, instrument corrections, etc. That is, a Segment is the largest component in a Survey (highest part in the hierarchy) to which these other values can be attached. A Segment could consist of Stations but no Legs, if the Station Positions were being determined directly. A single Leg later joining two Segments would be a new Segment. Because a Segment has a single set of conditions, it could be manipulated as a single unit if desired.
Typical fields: leg(s), role(s), trip, instrument(s), technique, ray type.

Shot

A set of the actual survey readings resulting from one sighting between two adjacent Stations before any Instrument or other corrections have been applied. The number of readings in the set for a Shot will be determined by the Technique and Methods being used, and hence the number of different Measurements required and the number of readings needed for each Measurement, e.g. two for a Topofil length. Repeated sets of readings for the purpose of averaging are considered to be separate Shots. In the simplest case, a single Shot becomes the Leg between two Stations.
Typical fields: station to, station from, tape distance, magnetic bearing, vertical angle.

Spur

A survey network element which is a sequence of one or more Legs and which is connected to the rest of the network by only one end.
Typical fields: node, leg(s).

Station

A named end of a survey Leg or a directly established point, at a particular physical Point. Its location could be the result of Shots from or to other Stations, or of independent observations such as by GPS or by radio or electromagnetic methods. A Station may have one or more Positions, for example the original position calculated by the the survey field measurements, and also as the result of correction processes such as loop closure or statistical adjustment of the survey mesh, or by later resurveys. The same Station could be in more than one Segment.
Typical fields: name, point, leg(s), shot(s), position(s).

Survey

A related collection of cave/karst survey data which can stand alone, or may form part of a larger survey Project.
Typical fields: cave(s), project, trip(s), location of data, date started.

Team

A semi-permanent group of People who carry out cave surveys. A particular Segment may have been surveyed by a particular Team, or by a group of people not belonging to any formal Team. The informal "team" of People who have carried out the surveying in a particular Segment can be found by examining all the Roles related to that Segment.
Typical fields: name, members, formation date.

Technique

The type of surveying technique used in a surveying Segment to enable the calculation of the position of each Station, and also the calculation technique possibly used later in its mathematical adjustment. Technique examples are traverse, triangulation, resection, GPS, and the various survey adjustment techniques. A survey Technique will require a particular set of Measurement types, and each Measurement type will be obtained by using a particular Method. If a survey Segment field recorded the use of a particular Technique, then a program would use the "rules" for that Technique to guide its subsequent action on the various Measurements. This is a lookup reference entity rather than containing values from any specific survey.
Typical fields: name, measurement type(s), purpose.

Trip

A cave survey trip in which one or more Segments of survey for a Survey or Project are carried out during one nominally continuous time period.
Typical fields: name, start date, end date, survey belonged to.

Other definitions

These are other, non-entity, definitions which we may need to use in our discussions, and hence will need to agree on. We will of course end up eventually defining all the fields which belong to the entities, but these ones below may need clarification early on. Any others? We can accumulate them here until they get covered in specific field definitions.

Azimuth

The direction of a line measured clockwise from the North line in the range 0-360 degrees or equivalent. It will be a True, Grid, Magnetic, or Assumed Azimuth depending on whether the North line is True, Grid, Magnetic, or Assumed.

Bearing

The direction of a line measured from a North, South, East or West line in the range 0-90 degrees or equivalent. It will be a True, Grid, Magnetic, or Assumed Bearing depending on whether the line is True, Grid, Magnetic, or Assumed. Example: Bearing E30S (which is azimuth 120 degrees). (This is not common usage of the term in cave surveying of course, but we may need to discuss such measurements and will need a term for it, so we might as well use the correct one. "Bearings" may arise if integrating professional surveys, some historic, with our cave surveys.)

Traverse

A general term for a contiguous series of Legs in a survey. It may span several Trips and several Methods, etc.

Entity Relationships

The draft below describes how the various survey entities could relate to each other. This is a text representation of the Entity-Relationship Diagram.
"Many" below means more than one. The Entities are shown within square brackets [ ].

Alphabetically by entity:

[Branch]
- connects to two [Nodes]
- contains one or more [Legs]

[Cave]
- could belong to a [Cavesystem]
- could have initiated many [Surveys]
- could be recorded in one or more [Fieldbooks]

[CaveSystem]
- contains one or more [Caves]
- could have initiated many [Projects]

[Fieldbook]
- records one or more [Segments]
- could belong to one [Person]
- could belong to one [Organisation]
- could record many [Caves]

[Instrument]
- used in one or more [Segments]
- used by one or more [Methods]

[Interpoint]
- belongs to one [Shot]
- contains one or more [Measurements]
- located at one or more [Positions]
- could connect to many [Rays]

[Leg]
- belongs to one [Segment]
- connects two [Stations]
- contains one or more [Measurements]
- contains one or more [Shots]
- could be part of one [Branch]
- could be part of one [Spur]

[Map]
- is contributed to by one or more [Surveys]
- is contributed to by one or more [People]
- could be produced by many [Organisations]

[Measurement]
- used by one [Technique]
- could form part of one [Leg]
- could form part of one [Shot]
- could form part of one [Ray]
- could form part of one [Interpoint]
- uses one [Method]

[Method]
- used by one or more [Measurements]
- uses one or more [Instruments]

[Node]
- is located at one [Position]
- is connected to by one or more [Branches]
- could be connected to by one or more [Spurs]

[Organisation]
- associated with one or more [People]
- could be involved with many [Projects]
- could own many [Fieldbooks]
- could have produced many [Maps]

[Person]
- could be a member of many [Teams]
- could be associated with many [Organisations]
- could be performing many [Roles]
- could contribute to many [Maps]
- could be involved in many [Projects]
- could own many [Fieldbooks]

[Point]
- is coincident with one or more [Stations]

[Position]
- belongs to one [Segment]
- could have resulted from a calculation or loop adjustment by 
  one [Technique]
- could be the location for one [Station]
- could be the location for one network [Node]
- could be the location for one [Interpoint]

[Project]
- initiated for one [Cavesystem]
- initiates one or more [Surveys]
- involves one or more [People]
- could involve many [Organisations]

[Ray]
- could connect to one [Interpoint]
- could connect to one [Station]
- contains one or more [Measurements]

[Role]
- utilised by one [Segment]
- performed by one [Person]

[Segment]
- is surveyed on one [Trip]
- could be surveyed by one [Team]
- is surveyed using one [Technique]
- utilises many [Roles]
- is surveyed using one or more [Instruments]
- contains one or more [Positions]
- could contain many [Legs]
- is recorded in one or more [Fieldbooks]
- contains one or more [Stations]

[Shot]
- belongs to one [Leg]
- connects two [Stations]
- contains one or more [Measurements]
- could contain many [Interpoints]

[Spur]
- contains one or more [Legs]
- connects to one [Node]

[Station]
- is located by one or more [Positions]
- could be connected to by many [Legs]
- could be connected to by many [Shots]
- is coincident with one [Point]
- could connect to many [Rays]
- belongs to one or more [Segments]

[Survey]
- could include many [Caves]
- could be initiated by one [Project]
- could contribute to many [Maps]
- initiates one or more [Trips]

[Team]
- could survey many [Segments]
- consists of one or more [People]

[Technique]
- used for calculation or loop adjustment of one or more [Positions]
- used for surveying in one or more [Segments]
- uses one or more [Measurements]

[Trip]
- contributes to one [Survey]
- surveys one or more [Segments]