When you are working with visual specifications, there are several different tasks associated with creation, management, design, and application.
Specification creation involves deciding the type and location of the database that is going to store the specifications and their rules.
The management part of the process involves creating representation rules and establishing which feature layers are going to be linked to representation rules and calculated fields.
Design involves creating the actual specification rules that associate symbols (representation rules and calculated fields with a specific set of conditions for features in a feature layer). This includes the layer for which you want to define the conditions and the Structured Query Language (SQL) statement and Visual Basic Scripting Edition (VBScript) expressions that make them up.
Once the specification rules have been created, they are ready to be applied to the data.
Creating specifications
Specifications can be stored and managed in any geodatabase. The tables required to store the specifications are created when a new specification is created, if they do not already exist. Careful consideration should be given to choosing the type and location of the geodatabase that will store your specifications. This is especially true if you are working in an enterprise, multiuser production environment. In this case, the specifications should be stored and used in conjunction with the product library.
Managing the specification database and creating rules
Specification design involves deciding how best to implement a specification in your work and, as appropriate, across your organization. Users or groups of users within your organization can be given the following tasks within the visual specifications workflow:
- Read and apply a specification—Users of a specification that has already been defined for them or their organization. They should not be given permission to alter a specification and so are equivalent to the standard geodatabase viewer role.
- Read/Write to existing specifications and create new specifications—Users who have access and permission to read and write to the visual specifications tables. These users are equivalent to the standard geodatabase data edit role.
- Read/Write and assign what databases will store specifications—Users who have permissions to read/write, create new specifications, and create the visual specifications tables if they do not already exist. This role is equivalent to the geodatabase data creator.
When using an многопользовательская база геоданных, user permissions can be granted to the visual specifications database tables based on an individual's roles and responsibilities, just as they would for geodatabase tasks. In a nonenterprise environment, these roles are less strictly enforced; however, they can still exist in a theoretical sense of there being a specification designer/manager and a specification user.
In addition, there is an option to use a product library, which can also help enforce specification standards within an organization.
Creating representation rules and establishing which feature layers are going to be linked to representation rules and calculated fields are tasks that tend to be iterative as specifications are developed and updated. The symbols, or representation rules, need to be created for the features that will be displayed using your specification. They can be created from scratch using the Marker Editor, or symbols can be converted to representation rules using existing ArcMap symbols. Both these methods are valid, and their results must be migrated to a style to allow referencing during the specification design process. Once the symbols are created, it must be decided if and what layers and feature classes are going to be associated with feature class representations or calculated fields using a specification.
Creating representation rules
While deciding where to store and manage specifications, a parallel effort can be started that creates and stores representation rules in styles. If you are using calculated representations, the representation rules must be stored in a style for the specification to know where and how to access them when someone applies that specification. Representation rules can be created in one of two ways:
- Converting existing symbology to representations, then loading those converted representation rules into the desired style
For more information, see Managing feature class representations
- Creating or modifying converted symbols using the Marker Editor
Tips for storing representation rules
- The representation rules stored in the styles are only referenced by a specification. Thus, all machines must have access to a local copy of the styles, or the styles referenced in the specification must be centrally located.
- There are two locations in a style where representation information can be stored: representation markers and representation rules. Visual specifications only use representation rules, not markers.
Establishing feature layers
Specifications associate feature attributes to symbols with feature layers. A specification maintains a list of the layers and the associated feature classes that compose it, according to the names of both layers and feature classes. This allows multiple layers within a specification to reference a single feature class and, by default, have each layer point to its own unique feature class representations. This default setting of one representation per layer is not always desirable, as it may add more columns to feature classes than wanted. This is especially true when there are a significant number of layers pointing to the same feature class. To minimize this effect, the reuse of existing representations is recommended, as opposed to always creating a new one. When designing a specification, thought should be given to the feature layers that will be used to display your maps with your specification. It is recommended that the layer name, source feature classes, and order be established within ArcMap before individual rule bases for these layers are added to the specification.
During the design of the specification, the layer name is used to divide a specification into rule bases. If the layer name changes, the specifications rule will not be seen on the Calculated Representations tab of the Layer Properties dialog box. This can be changed and updated in the advanced view where the dataset and layer names are listed and can be edited.
Designing specifications
A rule base is a collection of individual specification rules for a given layer. There are two ways to build a rule base. The first method allows you to use individual layers to design the specification rules, and the second is using the advanced view available with the Visual Specifications tool. With individual feature layers, you can focus on one feature layer and build both calculated representation and calculated field rules for it. With the advanced view, you can create calculated representation and text string rules for all available feature layers in your map. Generally, it is best to use the tabs on the Layer Properties dialog box to design a rule base for each layer when starting a specification. Once the majority of the specification has been built and a more holistic editing experience is required, the advanced view may prove to be a better option.
Using individual feature classes and layers
The most common method is to start with existing feature layers. At least one specification must exist in the database chosen to store your specifications. Once this database is referenced though the Visual Specifications dialog box, the Layer Properties dialog box for the existing layers will display two additional tabs, Calculated Representations and Calculated Fields. The specification design process is intended to provide a comprehensive set of logical expressions based on the complete data dictionary. Generally, most data chosen will not have an example of every type and combination of attributes that are valid in your data dictionary. Therefore, the main objective of this process is not to use the Calculated Representations and Calculated Fields tabs to apply a specification to current features layers but to use it as a testing database for your specification.
Thus, you should not design a specification with data that is critical in day-to-day operations, as you could affect it in unintended ways during this process.
This is especially true when working in an enterprise environment. It is recommended that initial specification design be done on a nonenterprise database or a personal geodatabase. Typically, the beginning stages of the design process involve significant changes to the underlying production test data such as adding and removing representations and columns as you work though the design. Adding, deleting, and modifying representation rules also requires a schema lock, which is not always practical in an enterprise environment. Once the specification has become more refined and close to finalization, it is good practice to run the specification on an многопользовательская база геоданных using the Calculate Visual Specifications geoprocessing tool.
After the design process is complete, the production enterprise workflow is to run the Calculate Visual Specifications geoprocessing tool on the default version of the database, where there are no schema locks. This results in an enterprise production database that has all the required columns and symbols needed to produce the required products for all users of that database.
Using the Visual Specifications tool
The second way to design specifications is to use the advanced view in the Visual Specifications tool. This view allows you to see all the specifications stored in the current database location as well as all the rule bases for each layer and feature class participating in a specification.
Since this view does not require you to have a layer loaded in ArcMap, specifications can be built from scratch using this option; however, you still need to provide a workspace. Generally, the advanced view is a better tool to use once a specification has been started and the detailed work has already been performed using the Calculated Representations and Calculated Fields tabs on the Layer Properties dialog box.
A specification contains two main parts—calculated representations and calculated fields. As part of the design process, you can determine if your specification uses both or only one of these. Generally, most industry- or agency-specific visual specifications make no distinction between text and symbols (points, lines, and polygons). Both are graphic elements used as visual variables to help assign meaning to data. Thus, once a specification is completed and rolled into production, technicians can simply assign the specification they are familiar with, without knowing the underlying details of what is, or is not, part of the specification.
When designing specification rules for either calculated representations or fields, it is important to know how each rule will be processed when a specification is applied. Generally, rules are processed in the order in which they were added to the specification. However, the order can be altered so they are processed in a way that is appropriate for your map or chart. Rules are processed in order from low to high; thus, a rule with a processing order value of 1 will be calculated before a specification rule with an order value of 2. Each specification rule is then processed from right to left, where the SQL statement is processed first, which results in a subselection of features. This subselection of features is then passed to the Expression Parser for further refinement.
Tips for rule design
- The expression is required for calculated fields and optional for calculated representations.
- As SQL is not mutually exclusive, correct assignment of the processing order to each rule is important since the result of one specification rule may override the results of a rule that was processed earlier.
Updating and distributing specifications
Once a specification is near finalization or is finalized, it can be transferred to other users via the Export Specifications command. This command allows a selected specification to be exported from the database into an XML file (with a custom .vvs extension) and imported into another database location. This process is useful when changes to a specification or representation rule, stored in a style, have taken place and are needed by other users not using the same specification database. Optionally, the exported specification can include the representation rules or just the calculated representations and calculated fields.
Applying specifications
Once the specification design process has been completed and tested to ensure that the desired symbology is calculated, you are ready to distribute and apply your specification. If required, update database permissions if your specification is stored in an многопользовательская база геоданных. See the 'Designing specifications' section above for more details. There are two modes of applying a specification. The first is a manual mode, which is applied using the Calculate Visual Specifications geoprocessing tool. This tool adds the required fields (RuleID, Override, and Text String) to the feature classes chosen, and if they do not exist, it then updates the values accordingly. In an enterprise environment, where some users are restricted from making schema changes, it is recommended that an administrator run this tool with the appropriate specifications first. This step will ensure that data viewers will be able to see the symbols of the specification, and data editors will be able to update the RuleIDs and calculated field values, if the columns did not exist. The second mode is to check the Update Feature Class(es) check box on the Calculated Representations or Calculated Fields tabs on the Layer Properties dialog box.
For more information on user permissions, see one of the following: Privileges for geodatabases in Oracle or Privileges for geodatabases in SQL Server.
For more information, see An overview of the Symbology toolset
It is important to note that the tools that are part of visual specifications are conceptually geodatabase tools, not map document tools. However, there is some basic functionality to display the representation and calculated fields as labels using the Calculate Visual Specifications geoprocessing tool. For more advanced management of the map document, layers and symbols are required. It is recommended that as the specification is being designed, an associated map document be created to display the values of the symbol columns. This map template could be a standard map document (.mxd) or map template (.mxt) or layer files. It could also be a document management tool like Views.