The map of a large cave, or of a cave system, is a big project, and needs some data organization to easy its management. The map is usually splitted in a large number of files, both for the survey, and for the scraps. What follows are merely advices, and you might find better solutions. [Feel free to tell me your ideas, so that i can improve these notes].

The survey of a big cave, or of a system of caves, is made of a large number of individual surveys, each being the result of a survey trip. These individual surveys are then grouped in surveys of branches of the cave, and these are then collected into the cave survey. The surveys of the caves are finally put together to compose the survey of the whole system, by connecting the cave entrances with surface surveys or georeferencing them.

As you can see there is a hierarchical organization of the data. Therion uses a simila hierarchy to assing names to the survey items. The survey object is the container of survey items, or os other surveys. The name of the survey is used to refer to the items from outside the survey itself, like the family name (last name) is used to refer to the persons that belong to a family, and the first names are used to distiguish them within the family.

There is a difference, however. A survey may contain other surveys, therefore the hierarchy is not limited to two levels, but can extend to arbitrary number of levels. This is necessary in order to deal with the several levels of hierarchy that make the survey of a big cave, or a system.

For example, the stations defined in a centerline block of a survey can be referred to with just the station name, from within the survey, since there is no ambiguity. However, when you put together two or more surveys into a container survey, you must refer to the individual survey stations with the station name and the survey name. For example, 10@topo1 denotes the station "10" of survey "topo1". Another example: 8@topo2.whiteriver denotes the station "8" of survey "topo2", which is a subsurvey of survey "whiteriver". Similar syntax is used for the other map items, lines, maps, and so on.

The exact syntax to use to refer to an item depends on the point where the reference is made. For instance, in the last example, inside the survey "whiteriver" you refer to the station as 8@topo2. Inside the survey "topo2" you simply refer to it as 8.

The namespace option of the survey command specifies whether the survey creates a namespace or not (the default is on). For example if you have a survey that does not define a namespace, and you include it into another survey, then you refer to the items of the survey with -namespace off without the survey name. In the following code we can refer to station "1_1" in survey "t1" from the outer survey "main" without specifying "t1" in its name.

  survey t1 -namespace off
    centerline
      data ...
      1_1 1_2 10 0 0
      ...
    endcenterline
  endsurvey

  survey main 
    input t1.th
    ...
    equate 1_1 ...
  endsurvey

If you have unique station names and specify -namespace off for all surveys, all the stations belong to the top level, and you do not need the commands equate to identify stations in different surveys.

The same applies to other items: points names lines names, map names, and so on. This is important when you need them for equate commands, join commands, or for other maps.

It is quite natural to organize survey data in survey containers, that reflect the survey trips. Similarly you should organize the scraps in maps. The map command is a "container" of scraps or other maps.

By arranging scraps in maps you can control more easily their composing. Using the map is essential when you want to offset a portion of the survey to the side because otherwise the drawing would be too cluttered. To do this you need the map command.

Namespace