Hi Omri
These files are part of my ‘new project’ template, so they rea ready to go, as
is (provided you have a similar folder layout to what I use). For me a project
is usually a catchment or small caving region. Of course within that there are
individual caves, so these files are more or less ‘one for each cave’. Except
for the zipped files, which are ‘one for the project’.
The only change I make when I bring these into use is to find and replace each
instance of ‘NameOfCave’ and change it to whatever the ‘shortcode’ name of the
cave or catchment is. ie only the thconfig file.
All of these layout files are referenced (input) in the thconfig file.
>From then on, any of the layout definitions can be invoked at will (using copy
>statement).
So it is more like your second statement below.
In case you are interested, I have included a default project readme file. It
is an attempt to ensure all contributors to a particular mapping project are
pulling the donkey (all of the donkeys) in the same direction. The data
arrangement suggested is the only one that ticks all of the boxes for me, but
it is far from universally accepted outside my circle of influence. Other
arrangements are perfectly valid.
Bruce
From: עמרי גסטר <[email protected]>
Sent: Tuesday, 11 June 2019 06:27
To: [email protected]
Subject: Re: [Therion] code for Map layout
I need to separate each layout to a different file and then call it with the
copy command right?
or can I specify the file name and then call a specific layout from the file?
On Mon, Jun 10, 2019 at 12:18 AM Bruce Mutton <[email protected]
<mailto:[email protected]> > wrote:
Omri
Here is how I do it. My aim is to have it modular and flexible, so it is easy
to get many types of pdf output from the same project, either simultaneously or
with minimal easy edits between compiles. Refer attached.
Quite a lot of experimental noise in there, particularly in
LayoutStandards.thc, but you should find something of use.
Some probably outdated explanatory information here
https://therion.speleo.sk/wiki/templates
And here https://therion.speleo.sk/wiki/bds
Bruce
Filename: _Readme_th-TherionProjectBazaar Conventions.txt
---------------------------------------------------
(you may need to view this file with 'word wrap' on)
These are aspirational guidelines, some are followed in this dataset. They are
open for discussion if you disagree.
They start out describing general information, then specific information
relevant to this project.
What to store and what not (Generic)
--------------------------
We aim to produce a somewhat self documenting file structure that contains self
documented files. Hence plenty of (concise) commentary is encouraged within
the data files.
Each cave folder should be self contained, referring only to files within and
below it, with two exceptions.
1. In order to maintain consistency of behaviour and appearance across the
project we refer to standard Layouts in a folder, \StdFiles, at the top level
of the project. This means that the typical project map appearance can be
controlled by editing files in one place.
2. Terrain model(s) and surface images are stored in a folder, \Surface, at the
top level of the project. The images should cover a larger area than the
terrain model, as Therion clips the image to the size of the terrain model.
Overland surface surveys are (so far) to be stored with the cave folders in
this project.
What to store and what not (Generic)
------------------------------------
While Therion makes many assumptions about the default values (such as
projections, survey grade, units, etc etc), we state them explicitly so that
the intention is obvious to the user, and as protection against possible future
changes in default behaviour.
In general we want to store (and track with version control),
-All electronic data from data collection at source, to data which
controls creation of the map outputs
-Plain text files and bitmap images (png, jpg preferred) at about
100dpi (surface images should be higher resolution to get best results.
-All metadata (personnel, dates of discovery, survey and authorship,
instruments used, copyright, surface survey, entrances etc) that is readily
available for each survey, scrap drawing and other Therion entity.
-We err on the side of entering as much metadata as Therion allows us
to collect. This enables the potential for more useful visualisationsâ of
the cave as Therion's capabilities develop in the future.
And AVOID,
-Non-text files such as MS Word, Excel, pdf etc (these cannot be
tracked effectively by version control).
-Outputs (we have versioned folders to hold them temporarily, but
outputs are expendable and never tracked by version control)
-Temporary files generated by software
-Scans of survey notes and photographs related to the cave (while these
might be nice to store with the survey data, they are not of primary importance
to the map generation, and there is benefit to keeping the versioned dataset
size to a minimum). Scans and photos are important however, and tend to be
static data, so are better stored separate to our versioned data.
Preferred folder structure (Generic)
-------------------------
A flat structure is preferred over a deeply nested folder structure.
Within the th-Project folder we have a branch folder (trunk, etc) to facilitate
usage of bazaar version control software.
Within the branch we have Therion files relating to generation of whole cave
system maps and outputs, a folder for each cave, a surface folder, an outputs
folder and a 'standard files' folder. We can also make general information
files such as _To Do Issues and Resolutions.txt and this Readme Conventions
file.
Within each cave Area folder, we have an Outputs folder,
- if there are manual surveys we have a sketches folder to hold scans
of paper sketches,
- if there are PocketTopo paperless surveys we have a ptopo folder to
hold *.top files, archived TEXT and THERION exports from PocketTopo and xvi
files generated from *.top files (either by Therion or by TopParser).
Each discontinuous set of PocketTopoopo files needs a folder of it's own. We
try to manage PocketTopo prefixes so that they are unique within a cave. This
is so they could me merged in the future, should they join up.
Name Conventions (Generic)
----------------
Each file is named so that it is descriptive of what it contains, a survey
prefix followed by a short English description.
Within Therion files, all survey and map objects are named by mimicking the
file name and appending standard descriptive words. See
http://therion.speleo.sk/wiki/doku.php/drawingchecklist#scrap as an example.
See http://caves.org.nz/wiki/?section=files-content-and-naming-convention for
details.
Files that tie together large chunks of data are prefixed with INDEX (prefixed
because this will make them alpha sort together).
Files that contain layouts (control how 2d outputs are laid out) are prefixed
with Layout.
Files that contain extended elevation centreline control sequences are prefixed
Extend-.
Files that control how a particular set of maps and outputs are compiled are
prefixed with thconfig-
And if you happen to need to rename a file, make sure you use the Bazaar mv
(stands for move or rename) function to enable Bazaar to track the file's
history across the rename. This also prevents bazaar from treating it as a
'delete + add' which is wasteful of repo storage space.
Therion Survey file structure (Generic)
-----------------------------
Therion accommodates many ways of setting up and connecting data files.
We put our low level map definitions in the survey.th file at the END OF and
OUTSIDE of, the survey-endsurvey block.
ie SM-ITF-OS = Scraps and Maps - Inside Trip File - Outside Survey
eg preferred structure...
Trip File: 01-Cave.th
survey 01
centreline #many of these if changes in metadata within
one survey
..
endcentreline
endsurvey 01
input 01-CavePlan.th2
input 01-CaveElevEXT.th2
map 01-CavePlan -proj plan
.. #refer to scraps in 01-CavePlan.th2
endmap
map 01-CavePlanCL -proj plan #allows individual survey centrelines to
be turned on or off in output maps
01
endmap
map 01-CaveElevEXT -proj extended
.. #refer to scraps in 01-CaveElevEXT.th2
endmap
map 01-CaveElevEXTCL -proj extended
01
endmap
#End of file
The survey network and map hierarchies are then tied together in INDEX.th files
----------------------------------------------------------------------------------
Preferred projections and scales (SPECIFIC to THIS project)
----------------------------------------------------------------------------------
plan: 1:500 ??? (but bearing in mind that this is likely to need to be
presented at 1:1000 sometimes)
extended: 1:500 ???
Extended elevations are the main view (because it is a vertical
cave), and are defined in a file Extend-*.th
It is called from within the 1978Cave survey in INDEX1978Cave.th
All extend statements that TopParser places in survey files are
to be commented out, and transferred to Extend-1978Cave.th. The reason is to
centralise and disassociate extended centreline drawing from the survey, and
allow future creation of multiple extended elevations of the same piece of
passage, using projection indexes.
projected elevations: not a focus at this stage, may create at various
projections for parts of the cave in future.
Survey and Drawing Conventions
------------------------------
Be rigorous about setting station flags for;
entrances
continuations, complete with data set out for point continuations here
http://therion.speleo.sk/wiki/doku.php/drawingchecklist#points
etc
Be rigorous about setting survey flags for;
surface
duplicate
approximate
Survey markers and cairns:
mark fixed - use to indicate a man-made feature is the survey station ie
cairn or bolt
mark natural - can be used to indicate a natural feature is the survey station
ie large pointy rock or stal with flagging tape on it
Be rigorous about point symbol and label alignments ie -align left -align
topleft etc
ie be mindful that drawing can in future be compiled at many scales, so
placing the symbol point as close as possible to where you want it anchored is
required.
You can then use the most appropriate of the nine align properties to
make sure the symbol or text is positioned as well as possible regardless of
the scale eventually used.
Text and Labels
Use point remark to describe rigging, scale xs
(remark is italic by default, and by using 'remark' to describe ONLY
rigging, it is easy to switch off rigging display if we do not want it)
When rigging is shown, include rigging comment in header
map-comment
(Use RiggingChangesBranch to track rigging changes with bazaar
version control)
Use point label scales
xs for station-names, dates, altitudes, rigging, minor comments
s for comments and pitch or climb labels NOT on main route(s)
m (default) for pitch labels, climbs and place names on main route(s)
l for significant place names, cave entrances
As you work
-----------
Refer to and update the _To Do Issues and Resolutions.txt file as necessary.
Make sure you update your bazaar commit message as you work, and commit
snapshots of your project at milestones or before you make changes you might
want to back out of.
Before you send patches (if you have repo read-only access) or merge with your
trunk (if you are the project owner and have write access to the repo), try to
set thconfig files and layout files to produce nice tidy outputs that you would
want to find in the central trunk if you were pulling from it. ie don't leave
your temporary hacks in the way of other users getting nice outputs.
END
_______________________________________________
Therion mailing list
[email protected]
https://mailman.speleo.sk/listinfo/therion
