Structure of an App Resource Directory

Application Resources need to be prepared using a standard directory structure, starting with the application resource name, which is what you use to name the folder referenced as "Parent Directory" in the naming and structure descriptions below.

Required Elements

Parent Directory of the appResource

Name: 32 characters or less
- no spaces, underscores are ok
- no special characters
- lowercase a-z
- ends in a letter, not an underscore
Example
- quick_layers

appResource.xml file

Follow the xml structure described below. You can view appResource.xml files on the FTP site, such as this example.

appResource.xml Structure
<appResource>
<!--Root Element-->
<baseName></baseName>
<!--Basename of appResource, same as parent directory-->
<descriptiveName></descriptiveName>
<!--Descriptive name of data resource, spaces, numbers, and mixed case all accepted.-->
<publisherID></publisherID>
<abstract></abstract>
<!--ex. us_mn_state_mda See also Publisher Codes.-->
<topicCategories>
<!--Parent Element of topicCategory child(ren)-->
<topicCategory type="ISO 19115"></topicCategory>
<topicCategory type="ISO 19115"></topicCategory>
<!--Optional, unlike for dataResource.xml. See table for topic category descriptions. Use multiple tag sets if you have mutliple categories.-->
</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>
<appSubResources>
<!--Parent Element of appSubResource child(ren)-->
<appSubResource>
<!--Parent Element of individual appSubResource. 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. {fa2ce765-a2b2-46af-b3bf-edd96e04c2d4}-->
</subResourceIdentifiers>
<subResourceAccess>
<!--Optional: For use with services or links to other outside resources-->
<subResourceURL type="________" description="________" name="________"></subResourceURL>
<!--See table of URL Types. Web apps will usually use type HTML. The description and name are usually similar, and the URL itself is placed right before the </subResourceURL> end tag.-->
</subResourceAccess>
</appSubResource>
</appSubResources>
<accconst></accconst>
<keywords>
<!--Keywords for use in search on the commons. Use multiple tag sets for multiple keywords. -->
<keyword></keyword>
<keyword></keyword>
</keywords>
<ptcontac>
<!--Point of contact: Included due to the lack of Geospatial Metadata, as it is does not fully apply.-->
<cntinfo>
<cntorg></cntorg>
<cntper></cntper>
<cntaddr>
<address></address>
<city></city>
<state></state>
<postal></postal>
</cntaddr>
<cntvoice></cntvoice>
<cntemail></cntemail>
</cntinfo>
</ptcontac>
<lastUpdated>20170622</lastUpdated> <!--Date last updated: use for the Commons page, not used if blank. YYYY-MM-DD or YYYYMMDD formats work.-->
</appResource>

Optional Elements

Although subfolders are not required for an App Resource, they are permitted. In some cases, subfolders are useful in helping the user evaluate the resource or use it once downloaded.

Standard metadata and a preview.jpg are not required for App Resources; however, if either is provided, the publisher is encouraged to place them in a "metadata" subfolder in order to expose them on the Commons page (see example). This folder can also include any documents, images, or manuals that could improve the user's understanding of the application.

For applications that can be downloaded, the distributed file(s) can be placed in the main directory or in a subfolder with a name of the publisher's choosing; these files will all be zipped with the application for the distribution package. If the application is a completely on-line service, such as a web map or a geocoding service, a distribution package is not typically created. For those resources, only a main directory and an appResource.xml file are required to publish.