Promoting and Demoting Model Status

Updating Status Attributes of Existing Models

Importing new models is one aspect of updating the model collection. Next, we will visit each new model to see how existing models may be affected by these new additions. For example, new models may land on top of old models that may need their Status demoted to some phase of demolition. Sometimes existing models need to be modified to clear the site for a new model.

The update process also involves looking for models in Stage_Proposed_MP and Stage_Internal_MP that may have been promoted through the approval,permitting or construction process since the last update. This search may be facilitated by joining these feature classes with the Development Log.

As we look at each of these models, we can refer to current aerial photography to see what we can see. When changes to status are warranted, we should be ready to update any of the Model Status Attributes as follows:

  • Status,
  • Appear Date,
  • Disappear Date,
  • Appear Source and
  • Disappear Source

It is crucial at this stage that you have made yourself familiar with the Model Attribute Dictionary. Keep it handy so that you understand how to fill in these fields which are crucial to the integrity of the 3D models collection!

Model Collection Stewardship is Research

There are several aspects of managing the model collection that can be thought of as historical research. This is a useful mind-set for understanding the right sorts of values for the Model Status and Model Provenance attributes. In the setting of a typical municipal GIS or urban planning department the focus isnormally on information related to present and future situations. Care has been taken in the design of the model collection schema and management workflows to streamline the update tasks so that preservation of historical information is a side-product that leaves a priceless historical record as a side-effect of collection updates. While this benefit does not require much additional work,it does require an understanding of the proper assignment of model status attribute values.

The model collection schema is built to support research. The process of updating the model to reflect current conditions requires the consultation of reference materials such as aerial photos or the development log, permitting and assessing records, etc. The automated attribute assignment procedure, described above streamlined access to reference resources such as the latest Google Maps or NearMap and Assessing department viewers. The Appear Date, Disappear Date Appear Source and Disappear Source attributes provide a place to record the source documents that confirm these observations. Proper attribution of this kind is a big time-saver practically speaking. Reference material must be checked. It is easy to fill in these attributes when the references are at hand. Recording the facts in the catalog means that the references wil not have to be checked again.

The same model collection schema is useful for pure historical research and development of models of past street-scapes that do not exist anymore. Over most of the city, we may not have the knowledge and date-integrity to be able to zoom back in time with a time-slider. One difficulty is that we do not know the true Appear Date for most of the models. Nor do we have models of past structures dating to earlier than 2003. Nevertheless, the model collection schema would allow an interested person to add historical models and to data to annotate the appear and disappear dates for structures using historical maps.

Keep in mind that Appear and Disappear dates do not necessarily reflect "year built" or "year demolished". Rather, these attributes reflect the sources that record the date that the structure is first confirmed to exist or to have gone missing. Recording this reference information when you have it eliminates the need to check sources again until a better source of information becomes available.

Update Attributes with the Attributes Pane

Most of the tasks involved with updating the model collection involve selecting one or more features from the 3D view and changing their attributes. The Attributes Pane is the right tool for this job. This method is easier and safer than trying to edit attributes from the table or with the Calculate Values tool.

Understanding the Stage Edit Views and the Status Routing Process

As described in more detail in the The Building Model Collection, the geodatabase view of the model collection is segmented into feature classes according to Model Status This segmentation by status streamlines applications that are focused on the current or near-future views of the model collection.

The segmentation of the collection according to Model Status is useful but requires a little trickery in the development of new editions, since updating the status of a model can cause the model to jump from one feature class to another. Experience has shown that trying to accomplish changes of this kind by copy/pasting multipatch models from one feature class to another is a recipe for disaster -- some of which may not come to light until weeks or months later, whereupon, one has a sickening feeling of wondering how many other models may have failed to copy or paste properly.

The way we avoid this problem is by setting up the Stage feature classes so that any attribute edits including status changes may be made in the Stage feature classes, where they may be reviewed and made logically consistent. Deletions of models from the collection are flagged by setting the Model Status to Retired or to Expunge. When the next edition is published, the models in the Stage feature classes are routed to their new feature classes using the StatusRouter tool, which is discussed in more detail below.

The Stage Edit Views

The Stage Edit Views Permit the Quick Toggling of Features according to their new Status values.

The process of updating the status of models can be confusing, since it is often the case that new models completely cover previous models. It is helpful to be able to turn classes of models on and off according to their new status values. This can be troublesome, because the Active_MP layer with its 140,000 models takes a long time to draw. Many hours of trying to work around these awkward problems has led to the development of a set of Definition Query Views that sort the features in the Stage feature classes into previews of the final sorted feature classes. The neat thing about this is that picking a new status for a model causes the model to immediately disappear from one definition query view and appear in another with the appropriate symbology. This allows a very convenient way of checking the logical consistency of the collection as we are updating it.

Explore the Stage Edit Views

The illustration to the right shows how the stage edit views use group layers and definition query views to sort the Stage feature classes into group layers that simulate the final status layers.

The Stage_Active_MP feature class is further broken down into the Stable features (those that continue to have a status of Current) and Demolition Candidates those that have a status that is some variation of Demolished It is handy to be able to toggle the demo candidates with the models in the Proposed Preview group layer while checking to make sure that your updates are logically consistent.

Working with these layers while making updates takes some practice. You may decide to modify these definition queries once you have fooled around with these.

Regenerating or Modifying the Stage Edit Layers

It is inevitable that you will lose or want to modify or recover one or more Stage Edit Views. The masters of the current working version of the entire group layer is stored in the ArcDocs/Layers folder in the current Model Management workspace. If you make changes to yours, be sure to save the group layer there!

It took a while for me to figure out that it is very important to uncheck the the option Remove layers that have been overwritten by geoprocessing tools in the ArcGIS Pro Project > Geoprocessing Options. Otherwise these layers keep disappearing!

Odd behavior of Sticky Definition Querys

At ArcGIS Pro 2.9 we have a problem of queries that seem to be edited but then revert back totheir old values once you save them. I have found that it is sometimes helpful to:

  1. Change the query
  2. Then click the green checkmark above the query window.
  3. Look at the values againtomake sure that they reflect your changes.
  4. If not, remove the query and build a new one from scratch.

Never Delete Models from the Stage Feature Classes

The principle of reversibility for all edits made in this model collection management workflow requires that models not be deleted from any of the Stage feature classes. To prevent a model from making it to the next edition, you can set its status to Retired which is the normal procedure. Or for models that are exact duplicates or corrupted, you can set the status to Expunge, which will cause the model to be ignored by the Status Router tool when the next edition is produced.

The exception to this rule is that you are allowed to delete models from the NewModels_MP feature class.

OK! Lets GetStarted!

Enough chitchat. Lets continue updating the collection!

Visit Each New Model

Assuming that you have imported some new models, and appended them to the Stage_NewModels_MP feature class, a usefulway of structuring the task of integrating these is to zoom to each one. A handy way of doing this is to open the attribute table of unfiltered NewModels feature class, sort it according to its Object_ID, then zoom to each model. While you are looking at it in the 3D Scene, you can check sources like aerial photography (links provided in the model attributes.) This will confirm the model status and the demolition status of the other buildings in its context. Some of these extant models may require edits to make them logically consistent with the new models.

Check Proposed Models for Construction / Demolition Activity

Notice that Proposed models that have changed their status to Under Construction We can now begin the process of checking and updating the values of model status attributes for these models. To begin with, it is important to have a clear understanding of the purpose for each of the attributes. So please review the Model Collection Data Dictionary.

Overview

  1. Visit each of the new models. If you have had more than one batch, it can be helpful to sort the NewModels feature class according to the Record Initialization Date (RecInitDt).
  2. Use your most current reference image, which could be Google Maps, Google Earth or NearMap to see what has been happening in the context of the new model.
  3. Update the Model Status attributes to reflect the status of the new model and other models that may be affected by the new project. While you have the reference material in front of you, update the values Appear Date, Appear Source and Disappear Date and Disappear Source. For example,
    • For new models that have a status of Approved or Permitted, the Appear Date can reflect the date of the project approval or permission as reflected in the development log. The Appear source should be the development log with its issue date.
    • For existing models that would be affected by approved or permitted projects, change their status to Approved Demo or Permitted Demo.

      While you have the most current photography at hand, it is useful to use the Disappear Source attribute to record your observation of whether there is any site work going on, or of the existing structures remain unchanged.

    • It is often the case that models affected by new development may have to be modified since the new project may call for the removal of parts of existing models while leaving other parts intact. These models should have their QA Flag set to 3D Edit Candidate. These will be dealt with later.
    • If a new model is a new project proposal that supersedes an existing proposal on the same site, the older model may have its status changed to Superseded Proposal and the Disappear Date should be the same as the appear date for the new proposal.
  4. Notice that when models in the Active feature class have their Model Status values changed to Demolished, Modified, these models disappear from the Stage Active Preview group layer to one of the definition query views in the History Preview group layer. This allows you to quickly toggle these alternate views to expose any small models that may otherwise be hidden under other models.

Time-Series Imagery in Google Earth

Google Earth is a free tool that includes a deep store of recent and historical aerial imagery. The historical imagery can be viewed by clicking the button shown at number 2 in the image below.

Google Earth is a great free research tool.

You can quickly zoom to a site in Google Earth by copy-pasting the latitude and longitude from the model's attributes into the Google Earth search box as shown at number 1 in the figure, above.

Promote Status of Proposed Models

Reviewing all of the new models and their context will have led to many changes in other feature classes. There may be other changes needed to reflect the advancement of projects through the design review process. These changes can be found by looking at models in the Stage_Proposed_MP and Stage_Internal_MP feature classes and comparing the value of Status in these feature classes with the Project Status attribute in the Development Log. To facilitate this, it may be helpfulto join these feature classes with the current Development Log using the Project ID. Select by attribute queries or new definition query views can be created to highlight models that are candidates for promotion or demotion. These change candidates should be checked one-by one. With reference to the most current aerials. Then the same update procedure as described above, can be carried out.

Remember that the values of Appear Date, Appear Source, Disapp_Dt and Disapp_Src attributes should also be updated to reflect the change in status while you have all of the source material at hand.

Don't forget to update the edit fields!

As described in the data dictionary, the Record Modification fields are updated automatically by ArcGIS. These are very useful for traching and sorting recent modifications. For better or worse, there is no way to stop these fields from being re-set when the model collection is migrated to the next edition. Yet, it is important for users and managers tobe able to understand the changes that have been made to the models and their attributes. Therefore, it is up to you to set the values for Editor, Edit Date and Edit Action.

Most of the Edit Actions that happen to the stage feature classes during the staging process can be described as "Updated Status Attributes". The Update Edit Fields task facilitates updating the Edit fields by looking for records in each of the Stage feature classes (except for Stage_NewModels_MP) that have a Record Modify date later than both the Recode Init Date and the Edit Date. These are records that have been modified during at somepoint inthe lifespan of the ModelMgt workspace, but that have not yet had their edit fields updated. These records have a new Edit Date assigned and the value of Edit User is set to be the same as the Record Modified user.

It would be cool to be able to preserve the original Record Modified date, but unfortunately ArcGis updates the modification date before doing the modification.

Model Edit Flagging and Workflows

In the course of your adventures trying to fit new models into their urban context you wil have come across various situations where models need to be edited or created. Normally these situations are flagged for attention later. There are four model editing scenarios that eachhave their own workflows soitmakes sense to accumulate this work and handle edits when you can shift intoa different mode.

Here are the edit workflows and how to flag them:

  • New Model: Flag in Issue Points feature class.
    • Create in external editor, handle with model import workflow.
    • ArcGIS Model Creation Workflow.
  • Model 3D Edit: Flag with QA Flag = 3D Edit
    • Modify in in external editor, handle with model import workflow.
    • ArcGIS model editing workflow.
  • Surface Edits:
    • Remove Materials (Textures or Colors): QA Flag = Remove Color
      • Use surface edit workflow
    • Flip Surface Normals (all faces): QA Flag = Flip Faces
      • Use surface edit workflow
    • Flip Surface Normals (subset of faces): Flag with QA Flag = 3D Edit
      • Must be edited with external editor and imported with model import workflow. .

Setting Status for Edited Models

When models are flagged for editing, there are two options for dealing with the status of the prior version of the model.

In the case of 3D model edits, if a model is being split to reflect a demolition of part of the real world structure, then the status for the prior model should be set toModified so that the original model of the prior condition will be routed to the History_MP feature class. See the note on How the Modified Model Status Saves You Time.

If a model is flagged for 3d Edits for a repair, or if themodel splitting operation is going to produce complete models of the persistent part of the structure as well as a model of the portion of the structure that will be removed, then the status of the prior model should be set to Retired

In the case of surface edits when the new model is geometrically identical with the prior version, the status of the prior model would be set to Expunge.