Initializing the Model Collection Management Project

Getting Started:

The best way to get started with the model management workflow is to download the demonstration repository on gitHub. . Work through all of the procedures documented here just to see that they all work with the demonstration data provided. Once you are comfortable with the workflow, you can make a copy of the template, remove the geodatabases in the Prior_Archive folder and the Stage/Stage.gdb. Then youcan initialize a fresh workspace and make whatever modifications you need.

Inspect and Modify ModelMgt_Config Data

Model Management Config Data

Before any work is carried out toward the next edition of the model collection, you have an opportunity to modify the schema for model feature classes. The master template for all multipatch feature classes and the tables that establish the coded domain fields for model status and QA Flags are kept in the Stage/ModelMgt_Config.gdb. If you are going to make changes to any of these, it is critical to make them when you are initializing the workspace.

Any changes you want to make to the multipatch feature class schema should be made to the Model_Mgt_Config/Model_Template_MP feature class. As we work through the tools in the first tool group, you will see how changes the domain tables are propagated to all new feature classes. The tool 1a. Create Model Template can be helpful for creating and modifying a new model template based on an existing model feature class.

Prepare Prior Archive Feature Classes

The geodatabases in the Prior Archive folder provide reference for initial state of models before any updates and additions are carried out during the lifecycle of the Model Management workspace. To assure that all of the changes made to the model collection are traceable and reversible, it is important that the prior archived collection be latest edition created by the previously retired Model Management Workspace. Feature classes in this folder are strictly read-only.

If you are making changes to the table schema for multipatches, you should make these changes to each of your prior archived feature classes to make them conform to the ModelMgt_Config\ModelTemplate_MP feature class. The model management workflows require that the schema for each of model feature class is exactly the same as the template. You might find it useful to make a copy of the tool, 1c. Migrate Prior FCs to make a consistent migration for each of the prior feature classes. Do not alter the original tool which is used for initializing the stage feature classes based on the working model template.

If you are beginning a model collection from scratch, it is not necessary to have anything in the Prior_Archive folder.

Initialize the Stage Feature Classes

The Stage Geodatabase

All of the changes made to the model collection are carried out on the feature classes in the Stage Geodatabase. This collection is initialized by copying each feature class from the prior archived collection. An additional multipatch feature class is created for New Models. The Stage.gdb also contains point feature classes representing the Development Tracking Log and Issue Points which are useful for noting issues such as missing models.

The Initialize Workspace Tasks

Initialize Workspace Tasks

These tasks are organized to help guide the set-up for a new model management workspace. As discussed above.

  1. Update Domains: If you have changes to make to the Status or the QA_Flag domains, edit the corresponding tables in the Stage\Congig.gdb. Then run this tool. This should be run on the Stage.gdb Config.GDB and any active ModelBatch geodatabases. This task makes use of the Update Domains tool described above.
  2. Initialize Stage feature classes. Each time you initialize a model management workspace, each of the prior model feature classes is copied to the stage geodatabase. This uses the 1c. Migrate Prior Archived FCs tool, but changes the name of the output worlkpace and prepends the string Stage to the name of each to avoid confusion.
  3. Initialize Stage NewModels FC: The newModels feature class in the Stage geodatabase holds any new model that might be imported or created by editing a pre-existing model. This task uses the 1b. Create Models MP tools to create a new empty feature class for the purpose using the current model template feature class.

At this point in the workflow, the stage feature classes should reflect all of the models and attributes as they appear in the prior archived collection. You are now ready to stage changes!

Tool Group 1: Initialize the Stage Feature Classes

Initialize Workspace Tools

The tools in the 1. Initialize tool group 1 and the tasks in the Initialize Model Management Workspace help out with getting your Stage geodatabase up and running. These tools are called on by the Initialize Model Management Workspace tasks. And some of them are incorporated in other tools and tasks.

  • 1a. Create New Model Template is handy for creating a new model template based onthe schema of an existing model feature class. .
  • 1b. Create Models MP FC This tool is incorporated in several other tools and tasks throughout the Model Management process. It takes the model template and creates a new empty feature class for storing new models. At the same time, it makes sure that the target geodatabase has the proper domains for Model Status and QA Flag.
  • 1c. Migrate Prior FCs uses the Create Models MP FC tool to create a new models feature class and then takes an input model and appends it to the new feature class. It uses an iterator to do this once for each of the five feature classes.
  • 1d. Update Domains. In case you just want to update the domains in a geodatabase that contains a 3D model multipatch feature class, this tool is for you. Note that before you run it, you should update the domain tables in the Stage/ModelMgt_Config.gdb.
  • 1e. Create Issue Points. The Issue Points feature class is used to flag places where new models need to be made. This tool will create a new one. If the prior archived model collection comes with unresolved issue points, it may be best to copy these over so that you can address the issues during your model management sessions.
  • 1e. Initialize Development Log. The development log is a table that includes a row for each development project and contains the latest status for that project and a URL for the agency's web home page for the project. It is important that the Project ID be a unique key in this table. I've included the tool here that I created for the Boston Planning and Development Agency. Each agency will have its own variation on this.