Simple uses of mp's config file

Simple uses of the config file

The config file can be complicated, as its documentation attests. However there are a few simple ways you can use it to make your work easier:

Using extensions
Using a profile
Naming output files using templates

Using extensions

Tkme and mp were designed to allow extensions. However the characteristics of the extended elements must be specified in an extension file and the name of the extension file has to be included in a configuration file. The extension file tells tkme and mp what the new element names are, where they go in the metadata structure, and how they relate to one another (meaning you can nest extended elements within other extended elements). You can use more than one extension file, so the config file contains lines that tell mp which extension files to read. For example, on <https://geo-nsdi.er.usgs.gov/> I use extensions for geologic age and for data set structure. My config file contains lines like this:

input
  extensions /var/lib/metadata/tools/ext/geo-age.ext
  extensions /var/lib/metadata/tools/ext/parts.ext

I typically name this config file standard.cfg, but you can name yours whatever seems appropriate. Note that your extensions probably won't be stored in the directory /var/lib/metadata; if you're running Windows, you probably will use C:/USGS/ instead, so the same config file on your system would look more like this:

input
  extensions C:/USGS/tools/ext/geo-age.ext
  extensions C:/USGS/tools/ext/parts.ext

When I run Tkme, I do it with the -c switch:

$ tkme -c standard.cfg

The same config file and extension files work under Windows:

C:> tkme -c standard.cfg

But I normally run Tkme from a shortcut. In that case, I put the -c standard.cfg into the Target field of the shortcut's property sheet.

The same method is used for mp:

$ mp -c standard.cfg input_file.met ...

C:> mp -c standard.cfg input_file.met ...

Note that you always need to use these extension files once you put the extended elements into the metadata, so it's important to choose and document your extensions carefully.

For example extension files, see the files *.ext that are within the tools/ext directory of mp's unpacked files. In general, you need to specify the long and short name of each element, its parent, and its children (if any). The only constraints are that you can't name an extension the same name as a standard element, and the extension's parent must be compound (meaning it can't be an element that holds a value, like Supplemental_Information; instead it has to be something like Description, which contains other elements).

You can read about how I use extensions at the URL <https://geo-nsdi.er.usgs.gov/how.html>

Using profiles

At this writing three profiles of the FGDC standard are officially approved and are supported directly by mp:

Biological data
Shoreline
Remote sensing

You can tell mp to use any one of these profiles with the profile directive of the input section in your config file:

input
  profile bio

You don't need to (and shouldn't) specify the biological profile elements as extensions when you do this.

For the shoreline profile, use profile sh; for the remote-sensing profile, use profile rs.

Naming output files using templates

A side benefit of the config file is that you can use it to simplify mp's command line. In its output section, you can specify the names of the html files and other outputs:

input
  extensions /var/lib/metadata/tools/ext/geo-age.ext
  extensions /var/lib/metadata/tools/ext/parts.ext
output
  errors %s.err
  text
    file %s.txt
  html
    faq %s.faq.html
    file %s.html
    err %s.err.html
  xml
    file %s.xml
  dif
    file %s.xml

This config file causes mp to write errors, text, 2 forms of HTML, xml, and a DIF. The %s is replaced with the file name, including directories. So I can run it like this:

$ mp -c standard.cfg project1/data/file1.met

and it will produce

  project1/data/file1.err
  project1/data/file1.txt
  project1/data/file1.faq.html
  project1/data/file1.html
  project1/data/file1.xml
  project1/data/file1.dif

This saves me from having to type, all on one line, the following:

$ mp project1/data/file1.met -e project1/data/file1.err
-t project1/data/file1.txt -f project1/data/file1.faq.html
-h project1/data/file1.html -x project1/data/file1.xml
-d project1/data/file1.dif

I can use this config file to simplify the use of err2html as well:

$ err2html -c standard.cfg project1/data/file1.err

From this I get project1/data/file1.err.html, an easier-to-read rendition of the error report from mp. Try it!