State Metadata Implementation Case Studies

State of Florida
State of Idaho
State of Illinois
State of Minnesota
State of New Jersey
State of Utah
State of Vermont
State of Wisconsin
State of Wyoming

State of Florida

Case Study Summary from Original Proposal:

The Florida effort will be carried out on a cooperative effort by the Florida Growth Management Data Network Coordinating Council and the Department of Environmental Protection, Division of State Lands. The Metadata Standard will be applied to one of four components of a Land Records Modernization Project. This particular component provides for the data collection of the land parcels that affect the inventory of ownership. The parcels are identified by parcel number and document number and attribute data relates these parcels to additional land records information for the State's cadastral layer state-wide for the division of State Lands. The parcels will be entered using coordinate geometry methodology.

Project Participants:

Related Home Page:

Florida Geographic Information Board - Florida Data Dictionary

Florida Department of Environmental Protection Case Study:

Documentation of the State Lands Cadastral Information System
Division of State Lands
Land Records Modernization

Introduction

The Florida Department of Environmental Protection (DEP) and the Florida Geographic Information Board documented DEP's State Lands Information System for the purpose of assessing the utility of the Federal Geographic Data Committee's Content Standard for Digital Geospatial Metadata (CSDGM). No tools were used to facilitate the creation of the metadata, requiring that the participants read and understand the Federal Geographic Data Committee's publication of the CSDGM and then convert it into metadata that followed the format provided in the publication. Although formatting of the report was discussed, it was agreed that the product would follow the structure of the standard.

The following notes and documentation describes the reaction to the process of creating the metadata. One of the participants was familiar with the metadata standard and the other was reviewing the document for the first time. The novice, for the sake of assessing the standard, took the lead in the documentation. The individual more experienced with the standard provided guidance only when pressed.

Both documenters were comfortable with the content, although there was some concern with the limited scope (geospatial data). With the promotion of Clearinghouses to support the National Spatial Data Infrastructure, there needs to be more "documented and cataloged" than just spatial data. Any further publications should take this into consideration and discuss the relation between the FGDC CSDGM, the Government Information Locator System (GILS) and the Library of Congress MARC format. The authors are aware that there are other "cataloging/documentation formats" and they feel that the appropriateness of use of one over the other would be extremely useful.

The analysis below focuses on the FGDC CSDGM with an emphasis on barriers to implementation.

Documentation Format

The documentation in its current format is not user friendly. When reading the organization of the standard, the sections marked: Numbered Sections, Compound Elements, Production Rules, Data Elements have no real world examples and a documenter without an information systems or mathematics background will find it extremely difficult to interpret.

Implementation Issues

The reviewers did not know if the "documentation" of the FGDC CSDGM is consistent with other federal standards. It appears that the "rules" are written for engineers who would "implement the standard for the population at large" (i.e. create tools to facilitate documentation). It does not appear to be understood by the publishers of the CSDGM that data documentation is normally a secondary job. Individuals who work with information systems professionals may be comfortable with this format, but much of this information must be completed by "program" staff who do not have an information systems background. It is unlikely that the program staff would have any idea of the meaning of the terminology used for the "data dictionary" and similar components. On the other hand the information systems staff are usually uninformed about the substantive information and mapping rules.

The publication does not provide adequate "how to" examples until the "Calendar Dates (Years, Months and Days)" section. In general, it is difficult for the user to understand what is being communicated until you the apply the rules. It took over thirty minutes to simply understand the structure of the "rules". A discussion of why these rules are important and how they would be applied would be very useful.

Definitions

The definitions were confusing and there is no single place to find terms. Definitions were assumed or defined internal to the standards and there were references to other standards. For example "domain", "data element", "compound element", etc. lacked definitions and examples that would aid the program professionals. With the documentation that is available, it appeared that it will require a joint effort between the data collector and the information systems staff. Should the "Biologist" not have access to a information systems staff, then this will probably severely limit how much can be completed.

A "user friendly" structured documentation tool is essential to the wide spread use of the standard and successful completion of a report.

Structure

It was difficult to distinguish between the different groupings. A simple font change or bolding of different sections would be extremely helpful. A technical writer could significantly enhance the utility of the documentation. It is difficult for the reader to know when they have moved from one section to another. With a standard as complicated as this one, there is great need for a logical or visual progression.

Formatting

It was not apparent to the documenter that the standard is only a "content standard" and not a format standard. In reviewing the publication, this fact was never mentione, nor were the implications discussed, which seem profound in the views of the authors. After considerable thought and discussion, it was agreed that there should be a recommendation for formatting, but not in the form of the content standard as it is provided. It seems unrealistic as it now stands, that this standard could ever be implemented within the documenter's agency. It would frustrate managers and staff alike and require too much of an organization's resources.

The participants' principle concern about the standard was the lack formatting and the subsequent inconsistencies in the way that the information is reported. Florida will be using the documentation not only as a mechanism for the sharing and archiving of data, but also for developing of standards. This requires a mapping of similar data, and without a consistency in the formatting, this will be onerous to impossible. As a result, Florida is moving towards the development of a consistent documentation and formatting standard. A beta version of a structured documentation tool is currently being tested.

Other Information

In addition to geographic information, there are many other types of information that need to be collected that are relevant to the geographic information community, but not addressed by the standard. For example, information specific to scheduling aerial photography flights and access to these products, data collection projects, an expert's database, etc. are not directly dealt with. Although it appears that the standard contains some, if not most, of the content needed to document these sorts of activities, this topic is never broached.

Geospatial Location

The geographic component provides for an adequate textual description of the location, but the coordinates don't appear to be useful and will be prone to error without a mapping tool. It would be more useful and less error prone to provide a process to map of the location.

Summary

In general the documenters found the CSDGM was complete, and Florida has initiated a project to develop a structured documentation tool to make the process as easy as possible for the catalogers. The CSDGM publication is not a document that can easily be provided to the state's professional geospatial data developers without this sort of tool. In addition, the state will need an education program. Furthermore, there are many things that are of interest to the state and its geographic information community that are not addressed by the standard. This includes such things as planned data collection projects, programs, expert's databases, etc. It is also recognized that there are other "cataloging/documentation" formats, such as GILS and MARC, that will need to be reconciled.

Attachment A - Metadata for the State Land Cadastral System (paper)

[back to top] [back to metadata project home page]

State of Idaho

Case Study Summary from Original Proposal:

The metadata standard will be applied to an existing state-wide 1:100,000 scale Hydrography coverage.

Related Home Pages:

Project Participant:

Idaho Department of Water Resources Case Study:

Hydrography Data

The Idaho Geographic Information Center within the Idaho Department of Water Resources has been working cooperatively with other state and federal agencies on the creation of an indexed and flow direction attributed hydrography coverage. This effort has been ongoing for almost five years and includes the entire Columbia Basin. Since this is a regional effort, states and federal agencies had to work cooperatively to make it happen. Most of the work was funded by the Bonneville Power Authority because of the utility to them of a standardized stream and river index system for the entire operating area.

The details of how the data were actually produced and the problems which occured during its creation are many. But after a long and arduous process, it seems the data are essentially complete, at least in Idaho and for most of the rest of the basin. The coverage that has been developed includes a U.S. Environmental Protection Agency river reach index number and flow direction attributes on all the hydrologic features shown on the 1:100,000 scale maps.

Metadata Activities

In 1993, the Idaho Geographic Information Advisory Committee formed a subcommittee to work on a metadata documentation standard for Idaho. The subcommittee was made up of both state and federal agency representatives. After approximately one year, the committee had developed an Idaho metadata standard which was based on the "draft" FGDC metadata standard. The Idaho standard was in essence a subset of the FGDC standard with some enhancement to the Raster data elements. The Idaho standard was adopted by the Advisory Committee in 1994 as version 3.0. Not long after that in 1994 the FGDC released the final metadata standard.

In 1995, the Metadata Subcommittee, in cooperation with the Idaho Geographic Information Center, submitted a proposal to the U.S. Geological Survey's CCAP program. Included in this grant request were a number of activities related to building and implementing a metadata server in Idaho. Also included was the review and update of the Idaho Metadata Standard to comply with the final standard adopted by FGDC. That task is now complete and Idaho has officially adopted the Idaho Metadata Profile version 4.0 as its standard metadata documentation format.

Population of the Idaho Metadata Server

Now that a metadata profile has been established and a WAIS server developed, there is a tremendous amount of work needed to actually document data and populate the server. In reality, this appears to be the greatest cahllenge in the whole process. Given the work loads and resource limitations of most geospatial programs, very few actually have the time and resources necessary to document their data. This will continue to be an operational struggle within the geospatial community until it becomes an artifact of GIS processing itself and is a particular difficulty for local government and private industry.

As part of the NSGIC CCAP grant, the Idaho Geographic Information Center was asked to document the hydrologic data vbdabe created within the Department of Water Resources using the Idaho metadata profile version 4.0. This task was completed and the resulting documentation is attached (Attachment A).

Attachment A - IGIAC Metadata Profile Form v4.0

[back to top] [back to metadata project home page]

State of Illinois

Case Study Summary from Original Proposal:

The Illinois Geographic Information System is a cooperative effort of the Illinois Department of Energy and Natural Resources, the Illinois State Geological Survey, the Illinois Natural History Hazardous Waste and Information System, Illinois State Museum, and Office of Research and Planning. This consortium developed a CD-ROM, entitled Digital Datasets of Illinois (April 1994). This CD-ROM includes metadata based on one of the final drafts of the Metadata Standard. In addition to contributing to the development of the case study, the contents of this CD-ROM will be posted and made available on the Internet at the University of Illinois.

Project Participants:

Related Home Page:

Illinois Case Study Project Description:

Summary of Activities

The Illinois Department of Natural Resources (DNR)* has been actively involved in the use and application of GIS technology for almost fifteen years. Eight divisions and a multitude of users within DNR have implemented GIS and the numbers are growing yearly. The diversity of these divisions are illustrated in the Illinois GIS Consortium (IGIS), a departmentwide GIS committee which includes: the Illinois State Geological Survey, the Illinois Natural History Survey, the Illinois State Water Survey, the Illinois State Museum, the Waste Management and Research Center, the Office of Realty and Environmental Planning, the Office of Resource Conservation, and the Office of Mines and Minerals.

As a result of years of spatial database design and development, DNR compiled and produced one of the first multidisciplinary digital geospatial databases, at the state level, anywhere in the country In order to render this information accessible to others, many of DNR's statewide datasets were published on CD-ROM in April of 1994.

In May of 1996 DNR completed the second in a series of CD-ROM's providing the public with additional digital spatial data for the state of Illinois.

Implementation of the Metadata Standard

Prior to the initiation of this project, the CD-ROM entitled Digital Datasets of Illinois (April, 1994) included metadata based on the FGDC Draft Content Standard for Spatial Metadata (Jan. 25, 1994). As part of this project the contents of the CD, including metadata in ASCII text format, were made available on the Internet at http://www.inhs.uiuc.edu/gis/statewide.html. When these metadata were generated (in early 1994), there was neither a final draft of the FGDC Metadata Standard nor a formal commitment to metadata on the part of the IGIS. The compilers of the CD were wary of over-commitment to a Standard still in flux, and without significant interagency cost and effort, could not provide uniform and explicit language for several metadata elements, such as liability statement, access constraints, use constraints, keyword thesauri, or distribution information. As a result, metadata included with the 1996 DNR CD-ROM consisted of a subset of elements selected to provide a specific emphasis on identification, spatial data organization, and entity and attribute information in ASCII text format In effect, this product provides an example of the use of the Metadata Standard, manipulated (with minimal overhead) for use with legacy data, in the formative stages of a multiagency metadata initiative (see Appendix B for example).

Databases Involved

Please refer to Appendix A for a summary of the IGIS databases contained on the CD-ROM and for which FGDC-compliant metadata data is available.

Analysis - Evaluation of FGDC Metadata Standard

The FGDC Metadata Standard provides a very detailed and relatively comprehensive framework through which essential documentary information for geospatial data can be generated. Like any tool, however, practice is required in order to gain familiarity. To acquire technical understanding and experience with the FGDC Metadata Standard prior to any large-scale implementation, several members of the IGIS have used either of two versions (those of Jan. 25 and June 8, 1994) in different ways for various small-scale projects. Opinions vary among IGIS members concerning ease-of-use, suitability, comprehensiveness, and basic need for the Standard, spawning significant issues for discussion, some philosophical, some mundane:

  1. The Needs of the Metadata User: There are many potential metadata users, ranging from the technical analyst to the casual user to the executive decision maker. Generally, the technical user understands the need for fully compliant metadata and is willing to expend the time and effort necessary to protect her investment in geospatial data capture. Conversely, the executive decision maker needs only a few essential bits of metadata information and may not be easily convinced that the benefit of metadata justifies the cost. Each individual in this continuum of users will cite different metadata needs and values. We suggest the FGDC consider this sliding-scale philosophy as a possible approach in demonstrating to managers the need for metadata and its role in the various levels of the infrastructural hierarchy. It may make the financial decision to embrace metadata a more palatable one, without compromising the integrity of full metadata at the technical level.
  2. The Standard as a Metadata Toolbox: Continuing the theme of Issue #1, it must be recognized, as evidenced by this and other reports, that organizations will and do customize the Standard to their own needs. While possibly violating the concept of uniformly searchable metadata databases, this occurrence is fact. Perhaps the FGDC Metadata Standard should be reconfigured as a toolbox consisting of a minimum set of essential searchable fields, along with all the additional parts necessary to build a comprehensive customized metadata template. Promoted in this way, the Standard becomes a handy start-up kit rather than a cumbersome fill-in-the-blank form. We realize that this would be to move away from the pure ideal of a "standard". We feel, however, that regardless of how the Standard is promoted, conscientious metadata producers will by their nature continue to be thorough. The added value would be to appeal to those who are "on the fence" concerning a metadata standard by providing a less intimidating medium for metadata capture.
  3. Global Elements vs. Local Elements: Some sections and elements of the Standard apply to most every dataset in a collection, for example distribution information, while others are unique to a specific dataset, e.g. title. It is expected that as members of the IGIS develop a more comprehensive metadata program, those elements common to all the datasets (global elements) will be reported only once in some sort of "umbrella" metadata document, rather than redundantly in every individual metadata document. Those elements unique to a specific dataset (local elements) will comprise the individual metadata documents.
  4. The Issue of Scale: As the Standard currently stands, there is no field for an explicit statement of map scale. We are aware of the arguments for and against, and that some documenters have been using elements such as 1.2.1, 1.2.2, 1.2.3 (and others) to report scale. We disagree with the argument that point, arc and polygon data can be inherently without scale simply because they are digital. If data are captured from maps having scale, then the scale is intrinsic to the data, not just implied by the sources. For example, data digitized from a map at 1:500,000 and replotted at 1:24,000 is an obvious abuse of scale; this simple example demonstrates that scale is intrinsic to the data. We suggest the addition of an element in Section 1 of the Standard for reporting the range of scales of the source data.

Attachment A - Datasets (CD-ROMS, Volumes I & II)

VOLUME I VOLUME II

Attachment B- Example of Metadata for Illinois Natural Areas (paper)

* DNR merged with the Department of Conservation, the Department of Energy and Natural Resources, the Department of Mines and Minerals, and the Division of Water Resources, IDOT in July of 1995. This GIS initiative began at the former Department of Energy and Natural Resources (ENR).

Sheryl G. Oliver, GIS Coordinator
Illinois Department of Natural Resources
Office of Realty & Env. Planning
524 S. Second
Springfield, Illinois 62701
soliver@dnrmail.st.il.us
(217) 785-8586 (voice)
(217) 785-8575 (fax)

Dan Nelson
Illinois State Geological Survey
615 East Peabody Drive
Champaign, Illinois 61820
nelson@muck.isgs.uiuc.edu
(217) 244-2513 (voice)
(217) 333-2830 (fax)

[back to top] [back to metadata project home page]

State of Minnesota

Case Study Summary from Original Proposal:

Through the Minnesota Governor's Council on Geographic Information Standards Committee and the Land Management Information Center, Minnesota will apply the Metadata Standard on a newly developing state-wide data layer representing the Public Land Survey System to the quarter-quarter section (40 acre) level. If time and resources permit, the Metadata Standard may be implemented on other existing data layers, namely the National Wetlands Inventory and Land Use data.

Project Participant:

Related Home Page:

Minnesota Governor's Council on Geographic Information Case Study:

The Minnesota Geographic Metadata Guidelines: A Functional Implementation of FGDC Content Standards
Minnesota Governor's Council on Geographic Information
GIS Standards Committee

I. Case Study Project Description

Background

The Governor's Council. The Minnesota Governor's Council on Geographic Information was created in 1991 by Governor Arne H. Carlson to help coordinate the use and development of geographic information among all levels of government in Minnesota and to provide policy-level support to Minnesota's GIS users. Eighteen council members are appointed annually. They are drawn from state agencies, federal and local government, higher education, and the private sector. Administrative and technical support is provided by the Land Management Information Center at Minnesota Planning.

The council's GIS Standards Committee has been working for over three years to help define practical and useful standards and make them accessible to the state's broader GIS community. Aware of a void in adequate documentation of the large number of spatial databases in the state, and sensing a number of independent and uncoordinated efforts to develop metadata templates, the committee set as an objective for fiscal year 1996 (July 1, 1995 - June 30, 1996), to establish a state geographic metadata guideline.

Early Metadata Development Efforts in Minnesota. By mid-1995 a number of efforts to implement the FGDC Content Standards for Spatial Metadata were underway in Minnesota. The Washington County Surveyor's Office, for example, had established an ambitious plan to document a large amount of data in a manner fully compliant with the FGDC standard. The difficulties of adhering to such a rigorous model with limited staff resources soon slowed the process.

At the same time the state's Department of Natural Resources established a series of documentation templates designed to provide varying levels of detail about data sets, from brief general descriptions to detailed fully FGDC-compliant treatments. Catalog level metadata records were compiled for a few dozen data sets and made available on the department's web site in March, 1995. Simultaneous but separate efforts at developing a downsized version of the content standard were going on within the Metropolitan Council of the Twin Cities, the principle planning organization of the seven county Minneapolis/St. Paul metropolitan region.

Around the same time, the Governor's Council's recently completed data resources survey results were posted on their web site, identifying almost 500 spatial databases using yet another metadata template, incompatible with the FGDC standard.

Purpose of this Effort. It quickly became apparent that metadata chaos was about to dominate. The GIS Standards Committee became a focal point in providing a solution. The committee began working toward a solution using the following logic:

The FGDC metadata standards form an ideal set of documentation information.

However, due to their complexity and the lack of software tools to help implement them, the standards are unlikely to be quickly adopted by most data developers in the state.

To hasten the benefits of the standards, state efforts should focus on developing a simplified subset of metadata records -- state metadata guidelines -- compatible with the most important elements of the FGDC standards and capable of taking advantage of developing Internet access features of the NSDI Clearinghouse initiative.

Software should accompany any metadata guideline that would help users to enter, manipulate and become familiar with the information.

A series of instructional sessions should be developed that would help educate the user community about the guidelines.

A metadata subcommittee was formed in October 1995. Composed of the most advanced cooperators, the subcommittee quickly developed a strategy to develop and promote a statewide metadata template.

Cooperators

The development of the Minnesota Geographic Metadata Guidelines is being facilitated by the state's Governor's Council on Geographic Information. The Council's metadata subcommittee is responsible for this effort and consists of:

Robert Maki; GIS Database Coordinator; MIS Bureau; MN Department of Natural Resources
Mark Kotz; GIS Specialist; The Metropolitan Council of the Twin Cities
Robert Bixby; Professor of Geography; St. Cloud State University
Nancy Rader; Research Analyst; Land Management Information Center at MN Planning
Christopher Cialek; Geographic Information Supervisor; Land Management Information Center at MN Planning; Member: Governor's Council on Geographic Information

Databases Involved

A list of over 475 databases that will have metadata descriptions compliant with the MN guidelines can be found on the World Wide Web site of the MN Governor's Council on Geographic Information at http://www.lmic.state.mn.us/gc/gisdir.htm.

II. Case Study Methodology

This case study describes the efforts in Minnesota to implement a practical version of the FGDC Metadata Standards and to maximize their use within the geographic information user community of the state. The following strategy was developed to promote those goals:

  1. Develop a conceptual model - Build upon the independent work of Maki and Kotz, who developed prototype metadata templates in the spring of 1995, by reviewing and merging those templates by November 1995.
  2. Examine the template - In November, conduct a detailed review of the proposed template and revise as agreed, including evaluating those elements that should be mandatory and those that are optional. Be prepared to have the template ready for preliminary testing.
  3. Test the metadata template - At least four implementations should be attempted using the template. Test data sets will include: Twin Cities Metro Land Use, Statewide 40-acre Public Land Survey, Otter Tail River Watershed Hydrologic Database, Digital Orthophotography sample.
  4. Evaluate results and modify template where necessary - Using the results of the implementation exercise, adjust the template to best describe these data sets keeping the information value of each element and ease of use in mind.
  5. Expose stabilized prototype template to user community - Prepare for a workshop in May 1996, to offer a detailed template description and elicit feedback from data developers who will be asked to use it.
  6. Modify template based on public review - Using the feedback from the workshop, make any necessary modifications to the template.
  7. Document the guideline - Produce a detailed description of each element of the template and explain its value as a data processing guideline.
  8. Explore possible collaborations to develop a software tool to assist metadata development - Minnesota is not alone in grappling with the issue of adequate spatial data documentation. Efforts have been made to collaborate with the state of Michigan's GIS council, IMAGIN, to develop tools that assist in entering this type of information. A Windows-based metadata entry tool called DATALOGR, has been developed by the Michigan Legislative Service Bureau for IMAGIN. It is currently undergoing revision. Its principal developer has agreed to review the MN guidelines to determine if a revised DATALOGR could accommodate the guidelines of Minnesota while satisfying the needs of data documenters in Michigan. By pursuing software development partnerships, costs for such efforts will be mitigated and interstate standardization promoted.
  9. Educate users - Provide a second workshop at the 1996 MN GIS/LIS Consortium Conference (the state's annual GIS conference held September 25 - 27, 1996) that will detail the value and use of version 1.0 of the guidelines.

III. Results

Products and Services

A Single, Jointly-Developed Set of Guidelines. The Minnesota Geographic Metadata Guidelines have their roots in the FGDC Content Standards. The guidelines, however, developed as a synthesis of the best thinking of state, regional and local government and the academic community within Minnesota. Because of the cooperative development path of this single set of guidelines, they enjoy two important advantages. First, our approach limited the number of developers and controlled review cycles so that a manageable schedule could be developed and maintained. Second, due to the inclusive nature of their development, the guidelines are more likely to gain support and widespread use among the wider user community than guidelines developed and promoted by a single entity. Before they were fully formulated, the guidelines were introduced to the state's Information Policy Council, a policy advisory group made up of information managers from all state agencies. IPC acceptance is a critical part of the state's standards sanctioning process. Preliminary response from the IPC to the guidelines has been very favorable.

Broad User Community Involvement. The wider geographic information user community in Minnesota has been involved in the generation of these guidelines. The metadata development team is made up of representatives from four major data generating organizations.

On May 7, 1996, the team conducted a workshop to expose interested organizations to a prototype. A large part of the cost of conducting the half day workshop was underwritten by the Minnesota GIS/LIS Consortium, a not-for-profit organization that provides a forum for communication and cooperation within the state. The principal developer of Washington County's metadata development effort participated in the planning and presentation.

The goals of the workshop included, 1) informing potential users of the content of the guidelines and detailing a schedule for their release, and 2) asking that participants attempt to use the prototype and offer criticism to help modify it to maximize its usefulness.

The workshop attracted 52 participants representing state government (47%), local government (29%), federal government (8%), academia (8%), regional interests (6%), and the private sector (2%).

Evaluations of this inaugural workshop were very positive. All 37 respondents rated the event "very useful" or "useful." We are encouraged that they will likely use the guidelines once released in final form. Attendees also remarked that, although the guidelines are complex and involved, once described in detail they do not seem so daunting. "There's a lot here; but now that it has been explained, I can do this."

Participant critiques were reviewed over the summer, an updated version of the guidelines was prepared, and in September, a second workshop was presented to unveil version 1.0 of the Minnesota Geographic Metadata Guidelines.

NSDI Partnering Remains Intact. The MGMG do not include every element of the full federal metadata content standards. This alteration concerned the development team. On one hand, because of their size and complexity, the federal content standards present a very large hurdle for potential users. On the other hand, incompatibility with the federal standards jeopardizes access to a wealth of customized software tools being developed by the FGDC Clearinghouse initiative to facilitate metadata browsing and searching.

To deal with this dichotomy, the development team worked to ensure that essential elements -- FGDC mandatory elements -- have been included in the guidelines. Meeting with the FGDC Clearinghouse director in August, we were assured that inclusion of mandatory metadata elements will guarantee full functionality in the national clearinghouse, a goal of the Minnesota effort.

New Interstate Working Partnerships Fostered. A new interstate partnering opportunity has been created in the development of these state guidelines. Critical to the success of the guidelines is an easy to use software tool that will readily allow entry of metadata information. Many such tools exist, but none that adhere to the specific elements that compose the Minnesota guidelines. The development team felt it was advantageous to adopt an existing tool rather than invent a new one.

One such tool has been developed in Michigan for the state's GIS Council, the IMAGIN Forum. The software, called DATALOGR, is a windows-based utility with a straightforward presentation. DATALOGR was originally developed to help enter a unique fixed set of metadata elements for data developers in Michigan.

Partially through the suggestion of the MGMG development team, IMAGIN contracted a redesign of the software to make it more flexible. The development team has worked closely with the DATALOGR revision team to ensure that all elements in the Minnesota guidelines can be collected. That work is nearing completion.

The Minnesota GIS Standards Committee has opened negotiations with IMAGIN for an unrestricted license for the use of DATALOGR within Minnesota's public sector. Although negotiations have not yet been finalized, the sense of partnership developing between the two states is real and has had positive impacts on the clearinghouse efforts of both states.

Outreach Planned. The Minnesota approach emphasizes the user. A comfort level develops in new metadata developers as they are exposed to a manageable documentation standard. As familiarity with that standard grows, new descriptive elements may be introduced that more completely document databases. Ultimately, the goal of the GIS Standards Committee is to evolve the MGMG into full compliance with the FGDC standards.

Through the workshops already presented, and those planned for the future, an opportunity exists for potential users to come to understand the guidelines and experiment with them. Easy access to a metadata entry software tool is core to the strategy to get a wide cross section of users to implement the guidelines.

The metadata team intends to spin off training activities to technical colleges and private training concerns around the state to accelerate acceptance of the guidelines. The responsibility of managing the distribution of the software tool when a licensing agreement has been achieved will most likely fall on the Land Management Information Center (LMIC), a division of the state's planning office dedicated to coordinating GIS activities in Minnesota.

Template

In addition to printed descriptions of the MGMG, each workshop participant received a digital version of the documentation and a word processing table that provides some structure to help them experiment with documenting their own data. Those products were provided in both Microsoft Word and Corral Draw WordPerfect formats. A full template will be soon available in DATALOGR.

A full description of the MGMG template can be found in Appendix A of this report and will be available by January, 1997 on the Governor's Council GIS Standards Committee home page located at: http://www.lmic.state.mn.us/gc/stds/index.htm. An example of a filled out metadata document using the MGMG can be found in Appendix B.

IV. Analysis

Relevance of the Standard to Study Participants:

The development team agrees that the FGDC Metadata Content Standards form the essential catalyst to broad, orderly and complete documentation of spatial data. A number of critical aspects beyond the standards, however, are required to successfully implement a broadly used metadata strategy. These allied activities include education, user input, an achievable implementation strategy and assistance from coordinating bodies in carrying out that implementation. It is with these crucial associated activities that the Governor's Council feels it plays a critical role.

Evaluation of the FGDC Metadata Standard:

Overall, the FGDC standards are well designed and thorough descriptions of content. The following list, organized by section, highlights where the MGMG deviates from the FGDC Standards in some significant way.

Section 1

Unique Identifier (no FGDC equivalent) - Inserted as an identifying code to distinguish the data set. A coding scheme for this field has not yet been developed.

Spatial Extent of Data (no FGDC equivalent) - Text description of the geographic region described by the data set.

Theme Keyword Thesaurus (1.6.1.1) - Field added to MGMG to conform with Clearinghouse core elements list. A thesaurus of this type has not been compiled.

Contact Information (section 10) - Ten of the most important elements in this repeated section are embedded in Section 1.

Browse Graphic (1.10.1 through 1.10.3) - A free text field that combines three FGDC elements.

Cross Reference (section 8) - A free text field that provides an opportunity to include information about other related data sets without the structure of FGDC section 8. The MGMG name for this field is, Associated Data Sets.

Section 2

Lineage (2.5) - A compound field that includes all pertinent information described in FGDC elements 2.5.1 through 2.5.2.6. The working group felt that a single free text field would be more readily used than breaking out pieces of lineage in as many as 12 separate fields. As this element is explained to potential users, care will be taken to ensure that the components of this field are described, including source data name and date, description of the processing steps performed, data capture specifications, hardware & software used, processing tolerances, etc.

Source Scale Denominator (2.5.1.2) - This element of the lineage compound set has been pulled out as an explicit MGMG element to conform with Clearinghouse core element requirements.

Section 3

Point and Vector Object Information (3.3) - Replaced with Vendor Specific Object Type describing spatial objects in terms used by the native software (e.g. arc, area, cell, point, polygon, region, route-section, TIN, etc).

Tiling Scheme (no FGDC Equivalent) - Because many logical data sets in Minnesota are physically structured upon a set of well-defined partitioning schemes, this descriptor has been added.

Section 4

Horizontal Coordinate Scheme (no FGDC equivalent) - Identification of the coordinate arrangement used to define horizontal units. Seven domain choices.

Coordinate Offset or Adjustment (no FGDC equivalent) - Coordinate information for many data sets in Minnesota have been adjusted to minimize their size. This was particularly true in the past when offsets were applied to data to allow values to be stored as single precision values. This element has been added to describe the magnitude and direction of such offsets where they exist.

Azimuth or Bearing Usage (no FGDC equivalent) - Where spatial reference information includes survey coordinates, the FGDC standards do not clearly deal with the difference between azimuth and bearing measurements. This element has been added to identify which is being applied in the documented data set.

Azimuth Direction of Reckoning (no FGDC equivalent) - Identifies either clockwise or counterclockwise direction for which azimuth measurements have been taken.

Map Projection Parameters (4.1.2.1.2) - This FGDC compound element has been combined into a single free text MGMG element.

Section 5

Two FGDC elements have been retained in this section in a fully compatible form.

Section 6

Contact Information (section 10) - Ten of the most important elements in this repeated section are embedded in Section 6.

Section 7

Contact Information (section 10) - Ten of the most important elements in this repeated section are embedded in Section 7.

Attachment A - Minnesota Geographic Metadata Guidelines

Attachment B - An Example of a Completed Metadata Document Using the MGMG

Christopher Cialek
Land Management Information Center at MN Planning
330 Centennial Building; 658 Cedar Street
St. Paul, MN 55155
(612) 297-2488 (voice)
(612) 296-1212 (fax)
email: chris.cialek@mnplan.state.mn.us
October 1996

[back to top] [back to metadata project home page]

State of New Jersey

Case Study Summary from Original Proposal:

Two separate New Jersey agencies will participate in this project. The Department of Environmental Protection will compare the utility of an existing on-line data documentation against the Metadata Standard. In addition, the New Jersey State Mapping Advisory Committee will select a limited set of county, municipality and academic information for which the Metadata Standard will be implemented. A focus of the New Jersey effort will be to examine how metadata is used and the challenges faced when implementing the Standard at various levels of government.

Project Participants:

Related Home Pages:

New Jersey Department of Environmental Protection Case Study:

The New Jersey Department of Environmental Protection (NJ DEP) GIS Program conducted a case study to compare an existing state developed data dictionary with the federal Metadata Content Standard. The NJ DEP GIS Program has been documenting spatial data layers using an on-line data dictionary since 1988. This standard, developed for use with Arc/Info coverages, has provided an easy to use vehicle for various DEP and County government GIS users to document data quality, and understand the utility and limitations of spatial data layers. A comparison of the existing NJ DEP approach with the Metadata Content Standard is timely and was facilitated through the CCAP grant coordinated through NSGIC.

The Metadata Content Standard was found to be robust and comprehensive. There is significant resonance between the data dictionary in place at DEP and the federal standard. The Metadata Content Standard was found to be more comprehensive than the existing data dictionary, and therefore the NJ DEP GIS is modifying its effort to insure consistency with the federal standard.

The case study focused on an Integrated Terrain Unit (ITU) coverage for Mercer County, NJ. The ITU combined and encompasses four reference data layers; soils, land use/land cover, flood prone areas, and surficial geology. The case study has resulted in enhancements to the NJDEP data dictionary. These changes incorporate all of the mandatory elements of the federal standard, and modify the numbering and naming conventions to insure consistency. The results of this comparison can be seen by evaluating the attached templates. The NJ DEP data dictionary and associated readme files historically in place on the GIS network are included as Attachment A. The newly adopted data dictionary, now consistent with the Metadata Content Standard. is included as Attachment B.

John Fleming, NJDEP GIS
Lenora Ross, NJDEP GIS

New Jersey Geological Survey Case Study:

The New Jersey Geological Survey (NJGS) uses geographic information systems (GIS) to create geologic, hydrogeologic, and geographic themes in an electronic data format. These GIS themes are part of the NJGS electronic data base and GIS strategic plan which includes different ways of distributing these data to the public. A recent initiative undertaken by the NJGS involves transferring these digital data over the internet via the World Wide Web (the Web) (see attachment 1). Because the Web reaches a global market, the NJGS recognized the need to fully document the nature of these data so that their functionality is clear and so the users are aware of any restrictions or limitations in their application. The NJGS evaluated the FGDC-NSDI metadata standard in November, 1995 and decided to adopt the format for its use in creating metadata files for each digital file intended for electronic distribution.

The FGDC metadata standard is applied to all electronic files intended for distribution of over the Web and all GIS themes developed at the NJGS. The NJGS themes are being designed for use by ESRI's ArcView 2 software. ArcView 2 software uses Arc/Info GIS themes and dBASE relational data files for graphic display and composition. The NJGS metadata documents therefore focus on Arc/Info themes and dBASE relational database files. However, other products for which metadata files are produced include ASCII text files and compiled PC-based computer software programs.

The methodology used to evaluate and apply the FGDC metadata standard involved downloading a copy of the standard from the Web, having two NJGS staff simultaneously compare the FGDC standard to existing New Jersey Department of Environmental Protection (NJDEP) data dictionary file format, and establishing an ASCII-based text format for the FGDC standard (attachment 2) which was then applied on two GIS themes, one of which was linked to a dBASE file. The resulting set of metadata documents were then circulated for review and comment to the NJGS staff and staff within the Bureau of Geographic Information Analysis of the NJDEP Office of Information Resources Management (see attachment 3).

Results

The results of this metadata document initiative are included as attachment 2. An ASCII text file format was chosen as a template due to the universal nature of ASCII text and the necessity to develop metadata files on both PC (DOS-Windows) and the UNIX-based workstation platforms (attachment 2).

Analysis

The FGDC standard was found to be fully adequate in fulfilling the metadata document needs of the NJGS. Very few comments were submitted in response to the two memos that were circulated that outlined the concept to the NJGS staff.

Attachment A - NJDEP Data Dictionary and Associated Readme Files (paper)

Attachment B - NJDEP GIS Data Dictionary Now Consistent with the Metadata Content Standard (paper)

Attachment 1 - NJGS Digital Geodata Series Initiative (paper)

Attachment 2 - Results of Metadata Document Intitative (paper)

Attachment 3 - Metadata Documents Used in Case Study (paper)

[back to top] [back to metadata project home page]

State of Utah

Case Study Summary from Original Proposal:

The State of Utah's Automated Geographic Reference Center will be responsible for the creation of a public Land Survey System (PLSS) sample. The task will involve the development of documentation compliant to the Metadata Standard for a variety of PLSS related data. In particular, the sample will include metadata from the Bureau of Land Management's Geographic Coordinate Database (GCDB) for surveys on federal land, state lands and forestry surveys on state lands, county surveyor data for private lands, and any PLSS data digitized from 1:24,000 scale quads or other sources.

Project Participant:

Related Home Page:

Utah Case Study:

Introduction

The focus of this project is to determine how best to integrate cadastral data from different sources. In this instance, cadastral refers to the data representing the US Public Land Survey System and ownership from general areas (agency jurisdictions) to parcels. The process was started with three participants and AGRC facilitating. We hope to expand this to include the US Forest Service because the USFS, BLM, and the State control abot 90 percent of the public lands in Utah. Initially, we hope to include one other county representing a more rural area of the state.. Other participants will be added to eventually include all cadastral data producers in the state.

Framework Files for Integration

Utah County
MON (Land Monuments and all corners)
Section Lines
Ownership (to parcel level)

State of Utah
RSPLS (contains points and lines)
AOLSA (major ownership polygons)

Bureau of Land Management
GCDB (graphic representation of PLSS)
ALMRS (ownership and status)

Procedural Steps

Metadata File
Create metadata for files (listed above)

Standard Attributes
Determine minimum attributes needed in core files
Create/develop pointers to additional attributes

Spatial Index
Investigate for which areas data exist
Create graphic diagram

Integration
Develop steps to integrate multiple levels of data
Determine which are "Framework" compliant
Create mechanisms for clearinghouse access

[back to top] [back to metadata project home page]

State of Vermont

Case Study Summary from Original Proposal:

The Vermont Center for Geographic Information, Inc. will participate in the project by developing standardized metadata for one of its most important existing data layers, parcel boundaries. These parcel boundaries are based on 1:5,000 scale orthophotos.

Project Participant:

Related Home Page:

Vermont Center for Geographic Information Case Study:

I. Parcel Layer Metadata Case Study

Introduction and Project Description

The mission of Vermont Center for Geographic Information, Inc is to implement the state's strategy for development and use of a geographic information system. This includes assuring that spatial data gathered is compatible with the system and is shared by all in need of this data.

A Vermont metadata standard has been used since 1990 to assure standard documentation of each data layer. This standard does not meet FGDC metadata requirements, so up-dating the documentation is necessary to bring it up to compliancy.

As a test case for this process, VCGI developed FGDC compliant metadata for one of its most important existing data layers, parcel boundaries. These town parcel boundaries are based on 1:5,000 scale orthophotos.

Methodology

The purpose of the Parcel layer case study was to investigate the problems of transforming the current metadata to FGDC compliancy. The methodology comprised the following steps:
  1. Research current metadata generation software with emphasis on FGDC compliancy, user interface, and compatibility with our existing system.
  2. Establish a methodology for converting our metadata using the software selected.
  3. Evaluate the process keeping notes of problems encountered, issues not addressed.
  4. Make recommendations for conversion of the remaining data sets.

II. The Product

The software, DATADICT -- developed by the Montana State Library, Natural Resource Information System (NRIS) -- was used to create FGDC compliant metadata for the data layer Parcels. This software is compatible with our UNIX-based Arc/Info system. It was inspired by DOCUMENT.AML, as created and modified by the U.S. Geological Survey, Environmental Protection Agency, and ESRI. The user interface was satisfactory, probably as good as it can be due to limitations in Arc/Info forms menu software.

It produces FGDC compliant metadata files as long as all required information is input. We found that our system which used many memo fields was largely in-compatible with the DATADICT software. After an initial study, it was decided that the fastest way to accomplish the conversion task was to run DATADICT macro and enter the info by hand using our existing metadata tables as reference. DATADICT searches the data layer for information it can place in the metadata document automatically, such as projection information and attribute names. It also gathers generic information such as contact person and data distribution info from tables used for all data sets. This left very little documentation to be entered by hand. The majority of the work was to rewrite a series of memo fields in the existing documentation to fit the FGDC fields of ABSTRACT and PURPOSE. Data attribute definitions were also entered by hand because we felt it would be faster than writing and debugging code to do it automatically.

III. Analysis

Methodology

The conversion methodology agreed upon for this project came as a result of practicality issues rather than interest in developing new technology or complete automation. The existing software could extract most of the needed information from the data layer and generic information tables maintained in the system. Very little work was needed to be done by hand, and most of that involved digesting several memo fields in the existing metadata system and rewriting descriptive paragraphs for the appropriate FGDC fields. This rewriting work would be necessary for any software package used for metadata conversion. Although a procedure could be developed whereby the rewritten metadata memo fields could be entered into a database and later joined into the final metadata product, direct input by hand while running the conversion macro simplifies the procedure and takes less time.

It took a half hour to convert the first VCGI metadata document to FGDC compatible metadata using DATADICT package. The time will be shortened with increased familiarity with the software and menus. Also, a little preliminary work with the existing memo fields may result in much time savings by copy/paste activity.

Issues

Practicality/Technology. Although the Montana dictionary software supports adding unlimited text to most of the free text fields, which suggests the possibility of automatically transferring data from VCGI's metadata memo fields, it was determined that one-to-one correspondence did not exist and that a certain amount of rewriting would be necessary. With this in mind, the decision was made to input the data necessary by hand. In this case practicality won over technological wizardry.

With a data set such as Parcels, with 250 layers (one for each town in Vermont), one would prefer to have a metadata document describing the data layers as a group instead of a separate document for each layer. With DATADICT, the metadata is attached to a data layer with internal Arc/Info ties. Thus one needs to create a pseudo layer or summary layer to attach the summary metadata. This is less than ideal, for much of the metadata is collected automatically from the data layer and values for arc and polygon counts will not reflect the variety among the data layers in the set.

The FGDC metadata standard can seem overbearing at first sight. A software package like DATADICT which collects most of the information automatically leaves very little for the user to input by hand. This in itself will go a long way to encouraging data developers to try out the metadata tools. Issues of filling in the holes in data set information are still unsolved. One still has to know the characteristics of the data set before documenting it.

2. Summary metadata docs for a series of covers is not dealt with in this program.

3. The current metadata generation tool does not include all the metadata fields found in VCGI's system. The following information was felt important to VCGI but is not supported in DATADICT:

Tile structure of data sets. Some data layers are large and are divided into a tile structure for storage. One common tile structure used at VCGI is Vermont Town based. The data is stored in data layers clipped to the town boundary. The town is the basic unit of government in Vermont and since data generation and maintenance for layers such as land parcels and roads is carried out town by town, it is logical to maintain the statewide data in tiles by town. A different metadata document is not needed for each town data layer. Rather, metadata for the set is appropriate with a field indicating the tile structure in which the data layers are stored.

Data set size. Many of VCGI's clients use Personal Computers and need to know the data set size before ordering. This is valuable information for inclusion in the metadata file.

Associated files & tables. VCGI metadata records information of associated files and tables to a data layer. Often data layers have external tables that can easily be linked for increased information. Documentation of these files and tables should be included if they are available at the same site and are commonly used in association with the data layer.

Network & dynamic segmentation info. This information is important for Vermont transportation data sets.

Text field for geographic area. Many people relate to text descriptions better than bounding coordinates. Although the latter may be easier to work with mathematically or graphically in software packages, people often relate to names such as Vermont or Burlington town line.

Vermont Center for Geographic Information, Inc.
206 Morrill Hall
Burlington, VT 05405-0106
(802) 656-4277 (voice)
(802) 656-0776 (fax)

[back to top] [back to metadata project home page]

State of Wisconsin

Case Study Summary from Original Proposal:

The State of Wisconsin Land Information Board, in cooperation with the Wisconsin State Cartographer, three counties, three state agencies and one federal agency have developed the Wisconsin NSDI Clearinghouse Initiative partially funded by the FGDC. His clearinghouse activity includes implementation of the Metadata Standard on a variety of federal, state, and local data sets, including geodetic, natural resource, transportation, digital orthophotography, administrative, and public land survey. The results of this Metadata Standard implementation will be included in this report. In addition, the Wisconsin Department of Natural Resources (DNR) is in the process of updating its DNR GIS Database User's Guide first published in 1993. This book documented approximately 50 layers in the DNR's GIS Map Library. The new edition will reflect additions and restructuring on the DNR GIS Map Library, and incorporate the additional and revised elements of the final Metadata Standard.

Project Participants:

Related Home Pages:

Wisconsin Department of Natural Resources Case Study:

I. Project Description

Summary of Activities and Introduction

The Wisconsin Department of Natural Resources (WiDNR) GIS Program Mission is to provide tools for spatial data management and analysis for use in departmental policy analysis and decision-making, program management, and operations. The Geographic Services Section (GEO) of WiDNR's Bureau of Information Management (BIM) is responsible for overseeing GIS database development, applications, and technology implementation in the Department. In this role, GEO maintains over 50 statewide GIS data layers, and is currently developing other geographic datasets.

WiDNR shares data from the Department's GIS Database with all interested parties under the terms and conditions described in the Wisconsin DNR GIS Datasharing Policy. Comprehensive information about the statewide GIS data layers available from WiDNR is presented in the Wisconsin DNR GIS Database User's Guide, currently available as a printed document distributed in a 3-ring binder. The User's Guide is the primary means by which information about the content and characteristics of the WiDNR GIS Database is provided to Department GIS users and other interested parties.

Metadata Component of WiDNR GIS Database User's Guide

The Wisconsin DNR GIS Database User's Guide is currently undergoing a major revision that will document newly available GIS data layers as well as modifications to existing datasets since the publication of Edition 1 of the Guide in 1993. The intent is that the Guide revision include updated Metadata for all statewide datasets in a form consistent with the June 1994 version of the FGDC Content Standards for Digital Geospatial Metadata.

In contrast with the printed format of Edition 1 of the User's Guide, Edition 2 will be published primarily in HTML (hypertext mark-up language) format and made available online through the WiDNR Internet Server; a hardcopy version will subsequently be made available. Metadata for the WiDNR GIS Database is an integral part of the User's Guide.

Cooperators

From time to time, and particularly early in the design stage of this effort, WiDNR has cooperated and exchanged information with staff at the Wisconsin State Cartographer's Office (SCO) who are also participating in the FGDC/NSDI program. Points of contact at the SCO are Hugh Phillips and Bob Gurda.

Databases involved

For a summary of the WiDNR GIS Databases for which FGDC-compliant metadata are currently or will become available, please refer to Attachment A.

Case Study Methodology

The metadata case study information provided herein describes an ongoing design and prototyping effort with several goals in mind:

  1. Communication of information about the contents of the WiDNR GIS Database to Department staff accessing this information in the WiDNR computer operating environment: i.e., WiDNR staff using NCSA Mosaic version 2.0 on a PC to access the WiDNR GIS Database User's Guide on the WiDNR Internet Server.

  2. Ease of development and maintenance of the HTML-format version of the User's Guide on a PC 486/33 using HoTMetaL Pro for Microsoft Windows, an HTML editing software product published by SoftQuad Inc., of Toronto, Canada. NCSA Mosaic Version 2.0 is the primary Web browser used to preview the HTML documents, with Netscape as a secondary browser.

  3. Dissemination of data distribution and content information to interested parties outside the WiDNR accessing the User's Guide over the World Wide Web.

  4. General compliance with the FGDC Metadata Standard.

II. Results

Product

Integration with User's Guide. The Data Layer Descriptions included in the Wisconsin DNR GIS Database User's Guide, 2E, include hypertext links to the metadata information for each dataset. The metadata pages in turn contain links to the User's Guide, enabling the user to access metadata of interest and easily return to the main body of the Guide. Besides the HTML documents containing the metadata content for each dataset in the WiDNR GIS Database, the Guide also includes explanations of the structure and terminology used to present the metadata. This information, called the Guide's Metadata Structure section, is accessed directly from the User's Guide Table of Contents as well as each Data Layer Description.

WiDNR Implementation of Metadata Standard. The intent of WiDNR BIM/GEO is to comply with the FGDC Metadata Content Standard by generally including all "mandatory" and "mandatory if applicable" elements. In some cases, GEO altered the organization of metadata elements so as to achieve a structure more easily accessible to users through a Web browser, or to make the metadata easier to interpret. The User's Guide refers to each element by FGDC metadata content element by identification number, clarifies GEO's interpretation of the purpose of certain metadata elements, and notes each case in which the organization of metadata elements varies from the FGDC standard.

Organization of Metadata Pages. In an attempt to simplify the structure of the metadata sections of the HTML-format User's Guide, topically similar metadata elements that apply to many or all of the layers in the WiDNR GIS Database are addressed in a single set of Web pages accessed from all the applicable Data Layer Descriptions included in the Guide). Metadata that vary from one dataset to another are addressed in separate, data layer-specific pages accessed from the corresponding Data Layer Description; the diagram in Attachment B summarizes the structure of the WiDNR GIS metadata content pages. Cases of WiDNR departure from the FGDC Content Standard are summarized in Section III.B. Print-outs of the HTML Metadata Structuree pages from the User's Guide, summarizing the format and terminology used for presentation of metadata in the online version of the User's Guide, are included as Attachment C. This attachment also includes print-outs of sample HTML documents illustrating how the structure is implemented, using the WiDNR 1:100,000-scale Hydrography data layer as an example. [Note that the black bars at the top of the print-outs display as graphics when viewed using a Web browser.]

Digital versions of the HTML format metadata documents are provided on a 3.5-inch diskette accompanying this report; note that Uniform Resource Locators (URLs) embedded in the HTML documents would need to be modified to enable hypertext links among the component documents.

The following URL can be used to access the most current version of the prototype WiDNR GEO Home Page and GIS Database User's Guide, including the complete set of metadata documents for the WiDNR 1:100,000-scale Hydrography data layer:
http://www.dnr.state.wi.us/org/at/et/geo/

III. Analysis

Relevance of the Standard to Study Participants

The WiDNR considers well-structured, comprehensive metadata essential to help determine a dataset's "fitness of use" for a given application, as well as to help actually begin using a dataset. Consequently the FGDC Standard is a highly relevant and useful component of the database documentation provided in the WiDNR GIS Database User's Guide.

FGDC-compliant metadata, however, is only a part of the picture. Narrative and tabular information, presented in an easy-to-understand, well structured and attractive format, is also desirable to make data documentation useful and presentable. The metadata standard presentation tends to be dry, seemingly more attuned to the need for machine searchability rather than human comprehension and ease of use. Several examples illustrate how the WiDNR, through its GIS Database User's Guide, is addressing this shortcoming:

Evaluation of FGDC Metadata Standard

Overall, the FGDC Metadata Standard appears to be well designed, thorough, and flexible enough to adequately meet the need of WiDNR to document the quality and content of geographic data. The following Issues (organized by Metadata Content Standard section) describe the significant instances in which BIM/GEO has comments about specific parts of the standard, is varying from the standard, or where changes might be considered to improve the standard's usability.

ISSUE 1 - A Theme Keyword Thesaurus (1.6.1.1) doesn't currently exist at the WiDNR. Although in time WiDNR might develop its own Thesaurus, we would interested in finding out about existing Thesauri that could be adopted.

ISSUE 2 - A description of the data's geographic extent of coverage was considered to be at least as useful to many users as the West, East, North, and South Boundary Coordinate elements (1.5.1.1 through 1.5.1.4), and was added to Section 1 as a text version of compound element 1.5 - Spatial Domain.

ISSUE 3 - "Abscissa Resolution" (4.1.2.4.2.1) and "Ordinate Resolution" (4.1.2.4.2.2) were moved from Section 4 to Section 2. These are layer-specific metadata elements, and in the WiDNR implementation the information in Section 4 is not layer-specific; the elements were moved to Section 2 because data resolution is related to data quality.

ISSUE 4 - To simplify the metadata structure, certain Section 2 elements (i.e., parts of 2.5.1.1., 2.5.2.2., 2.5.2.3, 2.5.2.5, and 2.5.2.6) were consolidated (refer to Attachment D.)

ISSUE 5 - "Latitude Resolution" (4.1.1.1) and "Longitude Resolution" (4.1.1.2) were omitted as of less practical value to users than the "Abscissa Resolution" (4.1.2.4.2.1) and "Ordinate Resolution" (4.1.2.4.2.2) information for the corresponding Transverse Mercator version of a given dataset.

ISSUE 6 - "Resource Description" (6.2) is omitted; refer to "Title" (1.1, 8.4) for the identifier by which the distributor knows the dataset. This is a layer-specific metadata element, and in the WiDNR implementation the information in Section 6 is not layer-specific.

For more information about the WiDNR's GIS data documentation and metadata development efforts, contact:

John Laedlein, GIS Database Specialist
Wisconsin Dept. of Natural Resources
101 South Webster St., IM/8
P.O. Box 7921
Madison, WI 53707-7921
(608) 264-8916 voice
(608) 266-0870 fax
email: laedlj@dnr.state.wi.us

Attachment A - DNR GIS Database Summary

Attachment B - Organization of GIS Database Metadata in the HTML Format - Wisconsin DNR GIS Database User's Guide

Attachment C - Description of the Structure and Format of Metadata Provided for the WiDNR GIS Database

[back to top] [back to metadata project home page]

State of Wyoming

Case Study Summary from Original Proposal:

The State Engineer's Office in cooperation with the Shoshone and Arapaho Indian Tribes have contracted with the U.S. Geological Survey to develop metadata for all GIS data on tribal lands. These data holdings are extensive covering a wide range of data sets. This case study will emphasize the use of the Metadata Standard in the unique administrative circumstances of sovereign tribal governments. In addition, it represents a cooperative arrangement between the Tribes and the State under a formal data sharing agreement.

Project Participant:

Related Home Page:

Wyoming Geographic Information Advisory Council
Wyoming GIS Resource Page

[back to top] [back to metadata project home page]

last updated by David Hart on January 17, 1998