1. Home
  2. Maintaining and Updating Resources

Maintaining and Updating your Resources

Once your data or app resource has been published to the Commons, part of your responsibility of being a Commons contributor is ensuring that your resources do not become "stale". Below are some examples of how to handle maintenance and updates to your resources.

Updating Data and Metadata

If internal working copy of your data resource is updated routinely, you'll want the revised data to be distributed regularly via the Commons. If the updates are infrequent, you may choose to manually copy the revised data to the appropriate subdirectory of your data resource (e.g., copy new file geodatabase to replace existing file geodatabase). This may be all you need to do. Other times, you may want to edit your metadata record to change the "time period of content" date and publishing date. If you have an improved layer file or preview file, you may publish that also. Or, you might have additional documentation for the metadata folder. Updates of this sort can be done right in your GDRS node (or in the zip file on the Inbound FTP site), and do not require updates to the dataResource.xml. These updates should not be done using the MGC Data Resource Editor.

Organizations which are distributing resources that are continually updated may develop routines to extract from their production data system, convert to distribution formats, and copy to their GDRS node on a frequent basis - as frequently as nightly or weekly. This is an excellent method for ensuring that the distribution version of the data is synchronized with the working copy at any point in time. Updating of ancillary information such as metadata or data footprints can also be automated.

The Geobroker, during its hourly validation routine, recognizes when there are newer dates associated with files in the data resource, and re-validates as needed. If the updated data resource passes validation, then the Geobroker publishing process (overnight) pushes the updates to the GDRS Central Repository, the participating agency GDRS sites, and the Commons FTP site (for data distribution).  

Adding a new Data Subresource Type to a Data Resource

Let's look at an example of an update that would require modifying your dataResource.xml. Assume your basic data distribution format is file geodatabase (which the Commons publishing routine also converts to shapefile format for distribution). You decide to distribute the data as KML (zipped as KMZ) as well. In order to have the Commons reflect this, you need to update your dataResource.xml.

Manual method:

In your data resource directory you would create a new subdirectory called “kmz” and copy the kmz data there. You would edit your dataResource.xml file to add a new subresource. The segment to add an additional dataSubResource type to your dataResource.xml file would look like this:

<dataSubResource>
<subResourceType>kmz</subResourceType>
<subResourceIdentifiers><subResourceGUID></subResourceGUID></subResourceIdentifiers>
<subResourceAccess></subResourceAccess>
</dataSubResource>

At this point, it is easiest to leave the subResourceGUID section blank, and wait for the Geobroker to assign one on its next validation. Note that GUIDs must be inside {curly brackets}. The Data Resource Validator Tool can be used to verify that the other manually-added information is formatted correctly.

Using the MGC Data Resource Editor:

Open the Data Resource Editor and use the Update Record option (find the base name you used before to create the resource). This opens an mxd that was saved when you created your current resource. Add the kmz data to this mxd. Remember that the Data Resource Editor points to the Staging Area where you prepared this data resource for publication. The data resource editor will pick up the fact that you now have an additional data file (specify a resource type of "kmz").  Update the data resource from the “Update” button. The data resource editor should create the “kmz” folder for this new data set, and copy the “kmz” data there.  The editor also updates the dataResource.xml file with a set of “dataSubResource” tags as shown above, and will also assign the subResourceGUID automatically. From your staging area, recopy the updated data resource folder to your GDRS.  

Based on the new dates within the data resource folder, the Geobroker will revalidate and republish the resource if it passes validation. For the new data subresource type, a new data distribution zip file will be created and posted for download from the Commons.

This process is described for the data sub resource type “kmz”, but would work for any valid type listed in Resource Formats and Types.

Removing a Resource from the Commons

Removing a resource from the Commons is as simple as switching the distribution setting in the geobroker to "Agency". The resource will be removed from the Commons by the next morning.  If you wish to delete a resource entirely from the GDRS system, we recommend that you do this as infrequently as possible, since organizations can build applications around a particular resource as posted to the shared GDRS and published in the Commons.

Recent Records: If a resource was just published and published incorrectly (wrong name, wrong data types, duplicate GUID, etc.), it is acceptable to delete it and republish in its desired configuration. For a resource that was just published, it is unlikely that anyone has yet built it into an application or work process. Please note that the current resource deletion process requires administrative rights to delete the record from the Geobroker and to delete the record from the "Authoritative Node GDRS". More details may be provided here in the future for publishers. Until then, if you have a need to delete a recent resource, contact MnGeo.

Longstanding Records: If a resource has been published to the system for a long time and needs to be deleted (for instance, because it is being replaced by a major revision that gets a new data resource name) then more care needs to be taken to delete it. The Commons Team has established communication guidelines for these situations. Users need to be notified ahead of time to find out if anyone has built that particular data resource configuration into their business process. If that is the case, then more time may be allowed before the old resource is deleted. Once the decision is made to go ahead, the same process is used as above.

Responding to Users – Following Resources

Note that users of the system will sometimes contact you or other metadata contacts with questions or comments about a dataset. User questions about the data or metadata may make it obvious where the metadata needs to be improved, or where an additional data format (subresource type) would be desirable. Monitoring and responding to these comments, both directly to the user and by improving the data or metadata, will help improve Commons distribution products.  

Helpful Hints

  • Always create a backup before manually editing a dataResource.xml or appResource.xml, in case you need to revert your changes. You can always delete it later.
  • If you know of a resource from another publisher that is similar to what you are trying to accomplish (both in function and appearance), you can find their dataResource.xml or appResource.xml in your local GDRS or on the Commons FTP site. For the latter, you can browse to the folder with this formula: ftp://ftp.gisdata.mn.gov/pub/gdrs/data/pub/<publisher>/<resource>. For an example, see the FTP folder for bdry_dnr_lrs_prk
  • The "Descriptive Name" shown in the Broker is there to help you identify your resources along with the GUID and base name; it is only seen by you and administrators. While you can change this inside your dataResource.xml and appResource.xml files, that change will not be reflected within the Broker without administrative intervention. If you need a change implemented in the Broker, contact MnGeo.
uploaded file: 
PDF icon Geospatial Commons Resource Changes - Communications Guidance.pdf