Structure of a Data Resource Directory

Data Resources need to be prepared using a standard directory structure, starting with the data resource name. The Parent Directory of the dataResource is a folder having the data resource name.  Directory naming and structure are described below.

Required Elements

Parent Directory of the dataResource

  • Name: 32 characters or less
    • no spaces, underscore is ok
    • no special characters
    • lowercase a-z
    • starts with abbreviation for primary ISO Topic Category, followed by an underscore
    • ends in a letter, not underscore
  • Example
    • env_agchem_incidents

SubDirectory for each sub-resource type

Subresources to be distributed need to be stored in a standard directory structure.  The valid subresource types are listed in this Table of Resource Formats and Types.  In the following example, the data resource "Electric Utility Service Areas" (data resource folder name = "util_eusa") contains two data subresource directories, one containing an Esri file geodatabase type and one containing a kml/kmz type.

Data Resource Directory Structure, with Subresources

The dataResource.xml file would contain information on these subresources, as described in the next section.

dataResource.xml

The dataResource.xml file can be created automatically by using the MGC Resource Editor Add-in, or manually by following the xml structure described below.

dataResource.xml Structure
<dataResource>
<!--Root Element-->
<baseName></baseName>
<!--Basename of dataResource, same as parent directory-->
<descriptiveName></descriptiveName>
<!--Descriptive name of data resource, spaces, numbers, and mixed case all accepted.-->
<publisherID></publisherID>
<!--ex. us_mn_state_mda See also Publisher Codes.-->
<topicCategories>
<!--Parent Element of topicCategory child(ren)-->
<topicCategory type="ISO 19115"></topicCategory>
<!--One or more required. Use the Code listed in the table for topic category codes (e.g., imageryBaseMapsEarthCover) not the Abbreviation or the Description.-->
</topicCategories>
<resourceIdentifiers>
<!--Parent Element of resourceGUID-->
<resourceGUID></resourceGUID>
<!--GUID with structure: {8-4-4-4-12} where the numbers represent the number of alphanumeric characters between dashes and the whole thing is within curly braces. Leave blank if you don't know how to generate; the GeoBroker will automatically assign.
ex. {4e398704-7325-4548-87fc-5b39b519544b}-->
</resourceIdentifiers>
<dataSubResources>
<!--Parent Element of dataSubResource child(ren)-->
<dataSubResource>
<!--Parent Element of individual dataSubResource. One or more required.-->
<subResourceType></subResourceType>
<!--See table of Resource Types.-->
<subResourceIdentifiers>
<!--Parent Element of subResourceGUID-->
<subResourceGUID></subResourceGUID>
<!--Unique to each subResource and not the same as the resourceGUID!
GUID with structure:{8-4-4-4-12} where the numbers represent the number of alphanumeric characters between dashes and the whole thing is within curly braces. Leave blank if you don't know how to generate; the GeoBroker will automatically assign.
ex. {59b97976-2b04-4d36-a57f-76bcd5a0362f}-->
</subResourceIdentifiers>
<subResourceAccess>
<!--Optional: For use with services-->
<subResourceURL type="________" description="________" name="________"></subResourceURL>
<!--See table of URL Types.-->
</subResourceAccess>
</dataSubResource>
</dataSubResources>

</dataResource>

Metadata Directory

This directory must include the following:

Optional Elements

Preview Files

  • Preview files are stored in the metadata directory
  • Examples:
    • data_resource_dir/metadata/preview.jpg
    • data_resource_dir/metadata/preview.jpeg

Ancillary Metadata

In addition to the required metadata files, you can include as many ancillary metadata files of any type in the metadata subdirectory. These may include manuals, reports, or historic documents describing the data. You can also include metadata for individual feature classes if multiples are bundled in your data resource. These can be linked from the main metadata file.

Additional Data Types on the MN Geospatial Commons FTP Site

You will notice on the Commons FTP site that additional file types that you had not originally created are present. Those are automatically generated to give users alternative file types, in particular Shapefiles and Open GeoPackages, which are most commonly used in Open Source GIS.

Automatic File types Generated

Publishing data with File Geodatabase as Native Type

  • All underlying Feature Classes will be converted to Shapefiles, including those in Feature Datasets.
  • All Geodatabase Tables will be converted to DBF files.
  • The resulting Shapefiles will be converted into an Open GeoPackage.
    • FGDBs containing tables may be excluded from this conversion, since the conversion tools currently available do not handle the conversion of tables into Open GeoPackage.
    • Long field names may be truncated in the conversion process, as Shapefiles have a maximum length of 10 characters for field names.

Publishing data with Shapefile as Native Type

  •  Shapefiles will be converted to Open GeoPackage, with the exception that shapefile directories that include additional .dbf tables will not be converted to GeoPackage, as noted above.