option resulting action -------------------------------------------------------- -l code use language indicated by code (en,es,id,fr) -c cfile obtain configuration information from cfile -e efile direct syntax errors to efile -t tfile create text output in tfile -h hfile create html output in hfile -f ffile create FAQ-style html in ffile -s sfile create sgml output in sfile -d dfile create DIF output in dfileThe name of the input file that contains formal metadata is given on the command line but is not preceded by a switch. The input file name must not begin with a hyphen. Example:
mp -c config.dat foo -e foo.err -t foo.txt -h foo.html -f foo.faq.html -s foo.sgml -d foo.difThis command causes mp to read options from the file config.dat and metadata from the file foo. Errors are directed to the file foo.err, and output is directed to the following files:
foo.txt ASCII, using the input format foo.html Hypertext Markup Language foo.faq.html FAQ-style Hypertext Markup Language foo.sgml Standard Generalized Markup Language foo.xml Extensible Markup Language foo.dif Directory Interchange FormatNames of output files may be omitted if the corresponding information is included in the configuration file, which is described in section 3 below. Errors are printed to the error file or, if none was specified, to the standard error device (stderr), which is usually the console or the terminal from which the program was launched. Error messages and warnings refer to the line in the input metadata file by number (i.e. "Error (line 1):" refers to the first line in the input file). Warnings are issued when conditions that are considered unusual are detected; errors indicate a condition that runs counter to the dictates of the FGDC standard. 2. Input file format Since the FGDC Content Standards for Digital Geospatial Metadata, as the name implies, specifies only the contents of metadata files and not their encoding, it is necessary to choose or devise a specification for metadata encoding in order to create formal metadata. The encoding format interpreted by this compiler is purely textual. It describes the hierarchical structure of the metadata using indentation, in which the members of compound elements are indented more than their parent element and all of the elements at the same level in the hierarchy are indented alike. The full hierarchy is specified, even elements like Contact_Information that exist only to contain other elements and would not normally be needed by a human reader. The format is designed to be both parseable and human- readable, with a minimum of unnecessary jargon and code, but the requirement to be parseable makes it a lot more structured than ordinary text. Precise rules governing the format of the input file are as follows: Terms: tab := ASCII 9 space := ASCII 32 element name := A sequence of bytes consisting of alphanumeric characters, the underscore, hyphen, and forward slash. This sequence is one of the formal names given to metadata elements in the standard. Examples:
Citation Identification_Information Data_Set_G-Polygon_Outer_G-Ring Range_of_Dates/Timesvalue := A text string associated with an element by the originator of the metadata. Arrangement: a. Metadata files are plain text without markup. Non-ASCII character may be used and will be passed through to the output files but in the HTML output these may be interpreted as having ISO-8859-1 encoding by subsequent software. b. The number of characters per line is not limited. c. Indentation is accomplished using tabs, spaces, or a combination of the two, but for purposes of determining indentation level, one tab equals one space. d. Blank lines may occur anywhere in the file. e. Element names are spelled out in the metadata file exactly as in the syntax rules of the metadata content standard. Where the descriptive portion of the standard differs from the syntactical rules, the syntactical rules are regarded as authoritative, e.g. Attribute_Units_of_Measure is correct. f. A single colon or equal sign may follow each element name but is not required. g. Whitespace may occur between element name and colon or equal sign, and may occur after the colon or equal sign. h. Values are associated with an element in one of three ways: (1) The value begins at the first nonblank following the element name (or following colon or equal sign) and extends to the end of the line. (2) The value begins on the line following the element name. It is indented more than the element name, i.e. there are more spaces or tabs preceding the value than precede the element name. (3) The value begins on the line containing the element name. It extends onto subsequent lines, where it is indented more than the element name, i.e. there are more spaces or tabs preceding the value on lines following the element name than precede the element name. i. Values of compound types occur on successive lines using the same degree of indentation. Example:
Citation_Information: Originator: Publication_Date: Publication_Time: Title: Type_of_Map: Serial_Information: Serial_Name: Issue_Identification: Publication_Information: Publication_Place: Publisher: Other_Citation_Details: Online_Linkage: Larger_Work_Citation:3. Configuration file format Described in https://geology.usgs.gov/tools/metadata/tools/doc/config.html 4. Local extension file format The local extension file is encoded like the metadata; hierarchical structure is indicated using indentation.
local: name <element name> sgml <tag name> parent <element name> child <element name>Compound types:
local = name + (sgml) + 1{parent}n + 1{child}nScalar types: name The name of the element as it will appear in the metadata. This must consist only of upper- and lower-case letters, numbers, and the underscore character. sgml The element tag to be used for output in SGML. If omitted, the full name is used. parent The name of the element under which this element may appear. These names may be standard elements or local extensions. child The name of an element which may appear under this element.
Online Links:
Spanish-language element names kindly provided by Dr. Ing. Carlos López of the Clearinghouse Nacional de Datos Geográficos, Uruguay <http://www.clearinghouse.gub.uy/> Indonesian-language element names kindly provided by the Indonesian National Coordination Agency for Surveys and Mapping BAKOSURTANAL French-language element names kindly provided by Environment Canada (John Cree) German-language element names kindly provided by Peter Korduan (University of Rostock) Portuguese-language element names kindly provided by Luis Cavalcanti (Bahiana Pesquisador em Informações Geográficas, IBGE- Coordenação de Geografia Brazil)
Throughout the 1980s and early 1990s, the improving capability of desktop computers to carry out complex analyses has increased the popularity of geographic information systems (GIS). As they became familiar with GIS technology, people at all levels of government, in industry, and in academia have been calling for better access to publically-available geospatial information and more general use of standard terms of reference and of standard formats for the exchange of geospatial data and information. Answering this need is the goal of the National Spatial Data Infrastructure (NSDI), a government-wide coordination effort initiated at the Federal level through Executive Order 12906, which was signed by President Clinton in April of 1994. A key component of NSDI is the development of a National Geospatial Data Clearinghouse, a general source of information about geospatial data that are available to the public. With the Clearinghouse a user can determine whether geospatial data on a region of interest exist and are appropriate for solving the problem at hand. The Clearinghouse is a distributed network of internet sites providing metadata (information about geospatial data) to users in approximately the same way. Its success depends on the overall consistency of the metadata that are made available, because users are expected to evaluate metadata from numerous sources in order to determine which data meet their needs. To promote consistency in metadata, the Federal Geographic Data Committee (FGDC), an interagency council charged with coordinating the Federal implementation of NSDI, has produced the Content Standards for Digital Geospatial Metadata (CSDGM). That document provides standard terms describing elements common to most geospatial data, and encourages people who document geospatial data sets to use these terms. The Content Standards for Digital Geospatial Metadata (hereafter referred to simply as "the standard") describes not only the terms of reference but also specifies the relationships among those terms. The relationships, many of which are hierarchical, are complex and a formal syntax is provided to specify them. Because the syntax of the standard is complex and the number of descriptive elements is fairly large (341), creating metadata that conform to the standard is not an easy task. In addition to the problem of assembling the information needed to properly describe the subject data sets, data producers must arrange that information using the terms given in the standard and arrange the terms using the syntactical rules given in the standard. The resulting metadata are formally structured and use standard terms of reference, hence the term "formal metadata" in the title of this report. It is important to be able to say with confidence that metadata conform to the structure of the standard. Human review is still required--no software can determine whether metadata are accurate--but human review of the content is easier if the syntactical structure is determined to be correct. Tools whose purpose is to facilitate the creation of metadata cannot generally be said to conform to the standard, since they typically allow, but do not encourage, the user to create incomplete metadata or to enter improper values. Conformance testing should be carried out on the output of metadata generation tools rather than on the tools themselves. MP is designed to carryout conformance testing on formal metadata of this type.
Online Links:
Online Links:
Online Links:
ALBERSCEA AZIMUTHAL EQUIDISTC EQUIRECT GENERALVNP GNOMONIC LAMBERTAZ LAMBERTCC MERCATOR MILLER MODSALASKA OBMERCATOR ORTHO POLYCONIC PSTEREO ROBINSON SINUSOIDAL SPOBLMERC STEREO TM VANDERGExcised sgml tags from sgml.c; transferred the eight- character tags to a new file called ps8.c. Choice of tags to use in generating SGML output is governed by a local variable called do_astm in sgml.c; currently this is always set to 1, causing the astm tags to be used.
A: B: C: D:Here the parser assumes that D is a member of A, not of B. But the user might have intended D to be a member of B. The parser cannot tell, so it issues a warning.
void deallocate_item (struct item *p); struct item *insert_item_after (struct item *r); struct item *insert_item_before (struct item *q); struct item *add_child (struct item *p);and added comments explaining these functions. Added code to main in mp.c to insert a parent Metadata node if one is not already present. This causes the syntax checker to report missing major sections that are required.
tempkeyt -> tempkt accscons -> accconst accsinst -> accinstr columns -> colcount vertcnt -> vrtcountRebuilt makedtd and rebuilt ps8.dtd.
output html element name prefix <html code> suffix <html code> value prefix <html code> suffix <html code>This allows specific html code to precede and follow both the element name and the element value. Created a new file called deluxe.cfg in doc that shows how this new syntax can be used to link every element name back to the correct section of my hypertext rendition of the standard.
output errors %s.err html file %s.htmland process the input file "stuff.txt", the errors will be put into a file called "stuff.err" and the html output will be put into a file called "stuff.html". The file option can be specified for html, sgml, xml, text, and dif output, and has the same effect in each case. The extensions that will be stripped from the input file name are currently only the following, upper or lower case:
.txt .sgml .sgm .xml .text .met .bin
output text wrap 72in the config file causes all text in the text output file to be wrapped in paragraphs so that it fits in the first 72 characters of the page. This all assumes 2-space indentation in the text output, which is the default. I also had to modify mp.c to call write_text() last among the output formats so as not to muck up any of the other formats. (2.4.34)
output html # this is a comment; note that it is indented less than the # element immediately above it. file %s.html faq %.faq.htmlThen the "file" and "faq" elements will now be properly recognized as children of the "html" element. I think it used to consider them children of the comment, and thus were silently ignored. I bumped all minor version numbers by one for this fix. (2.4.40)
read_config <config_file> parse_text <input_file> find_first <element_name> find_in <address> <element_name> find_next <address> <element_name> value_of <address> forgetfind_first returns the address of an element in hex. This should not be modified, but should only be used as input to find_in, find_next, and value_of. forget causes the entire metadata record to be removed from memory, so you can read another record. (mq 1.0.0)
read_config config_fileThis command reads a standard config file, which will apply to all metadata read in this Tcl session. You can read only one config file, and you have to do it before you read any metadata.
metadata m -parse input_fileHere m is a Tcl variable name. On output it is given a unique value that allows mq to keep track of it. This command returns 1 if the parsing was successful, 0 otherwise.
$m find_first element_nameHere m is a Tcl variable previously passed to the metadata command above, and element_name is a standard or extended element name. This command returns the address of a matching element in hex, or zero. Use the address in subsequent commands.
$m find_in address element_nameHere address is the value returned from the find_first subcommand above or a similar subcommand below. If the given address is an element whose name matches the target element_name, the same address is returned. Otherwise it returns the address of the first child, grandchild, or more distant descendant node whose name matches the target element_name.
$m value_of ?-nonewline? addressIf the address given matches a data element, this returns its value as a string. If you specify -nonewline, then it comes as one line, with each line separated by a single blank space. Otherwise each line is separated by the newline character (ASCII 10).
$m contains addressThis returns 1 if the address corresponds to one of the elements in the tree, 0 otherwise.
$m name addressThis returns the name of the element at the given address.
$m next address $m prev address $m parent address $m child addressThese subcommands return the address of the next, previous, parent, or child node in the tree, relative to the given address. Zero is returned if there is no corresponding element. These provide a way to walk through the tree manually.
$m forgetThis frees all of the memory used for a metadata record. I cannot recommend using the Tcl command unset; it seems to take a long time to complete. Note that this interface allows you to read and manage more than one metadata record at a time. If you're going to read a lot of records, you will probably want to use the unset command when you're done with each one. (mq 2.1.0)
config read config_filereads the named config file, returns 1 if successful, 0 if not
config find_first optionreturns the address of the named option in the config tree. This is something you use in other config commands.
config find_next address ?option?returns the address of the next option after the one whose address is given as the address argument. If no option name is specified, it looks for an option with the same name as the one whose address is given.
config find_in address optionreturns the address of the first option of the given name that is within the subtree headed by the node at the address given.
config value_of addressreturns the value of the option at the address given. (mq 2.2.0)
value_set <address> <text>This assigns the given text to the element at the address given if that element can contain a value. An error is reported if the address is that of a compound element.
insert ?-before | -after | -child? <address> ?<element>?An element of the specified type is added to the tree before, after, or as a child of the element whose address is specified. If no placement is specified (that is, neither -before, nor -after, nor -child is given), the element is added as a child of the node whose address is specified. This function does NOT check to see whether the element so inserted is permitted to be there by the FGDC metadata standard.
delete <address>The element at the specified address is removed from the tree and cannot be recovered.
copy <address>A copy of the element at the specified address is made and its address is returned as the result of this operation. The copy has no links upward, forward, or back, and can thus be attached to any other metadata record using the paste function.
paste ?-before | after | -child? <address> <subtree>The subtree given as the final argument is attached to the current metadata record before, after, or as the last child of the element at the address given. This works only if the address argument is a compound element in the tree.
write ?-format text | sgml | xml? <filename>The metadata record is written out to the disk file whose name is specified as the final argument. If no format is specified using "-format <format>", then the format is text unless the output file ends with ".sgml" or ".sgm" or ".xml" in which cases the file will be written as SGML or XML. (mq 2.3.0)
is_compound <address>This function returns 1 if the element at the address given is a compound element, and 0 if the element is not compound. (mq 2.3.1)
input language esReplace es with id for Indonesian; en would be for English, but if the value is unrecognized or missing the software will use English element names. Spanish-language element names were kindly provided by Dr. Ing. Carlos López of the Clearinghouse Nacional de Datos Geográficos, Uruguay. <http://www.clearinghouse.gub.uy/> Indonesian-language element names were kindly provided by the Indonesian National Coordination Agency for Surveys and Mapping BAKOSURTANAL French-language element names were kindly provided by the Canadian Center for Remote Sensing, Natural Resources Canada Coincidentally added an extra element to the standard, at end of Metadata_Reference_Information I have added Metadata_Language. This element is not required, of course, but is permitted by mp. (mp 2.6) (mq 2.4)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">Thanks to Florence Wong (USGS) for pointing out the need to make some fixes in the code to achieve better conformance. (mp 2.8.5)
Luis Cavalcanti Bahiana Pesquisador em Informações Geográficas IBGE- Coordenação de Geografia Av. República do Chile 500-12 andar Brazil(mp 2.9.7) (cns 2.8.4) (xtme 2.7.18) (tkme 2.9.23) (mq 2.6.22) (err2html 2.1.9)
Online Links:
Online Links:
Biological Data Profile FGDC-STD-001.1-1999 Shoreline Data Profile FGDC-STD-001.2-2001 Remote-sensing Extensions FGDC-STD-012-2002In addition the following extension is included by default:
Extension_Information: Extended_Element_Name: Metadata_Language Short_Name: metalang Parent: Metadata_Reference_InformationLocal extensions to the standard are permitted and a mechanism is provided that allows these extensions to be described to the compiler.
Are there legal restrictions on access or use of the data?Access_Constraints: none
Use_Constraints: none
Although this program has been used by the USGS, no warranty, expressed or implied, is made by the USGS or the United States Government as to the accuracy and functioning of the program and related program material nor shall the fact of distribution constitute any such warranty, and no responsibility is assumed by the USGS in connection therewith.
Data format: | Executable and source code Size: 5 |
---|---|
Network links: |
https://geology.usgs.gov/tools/metadata/mp-2.9.*.zip |
Data format: | Source and executable code with documentation in HTML in format C (version ANSI (1987)) Size: 1.8 |
---|---|
Network links: |
https://geology.usgs.gov/tools/metadata/src.tar.gz |