Scenarios for product library implementation
The most basic implementation of the product library is using it for file management workflows. In addition, more sophisticated implementations can also be accommodated. The factors that determine the detail level of the implementation may include the location of the production or geographic data being used, the type and format of the data being used, or the types and variations of the products and data being created and maintained.
Below are four different examples of ways the product library can be implemented in an organization. Within these examples are details and workflows that can be modified to accomplish numerous variations of provided architectural examples.
Example 1: File management
Project work or map, chart, and data production life cycles require the use of many different files, such as documents, images, and geodatabases. To access file management tools, you only need to have a product library geodatabase that contains at least one solution. Other levels and their associated files can be added to the product library to help with organization. The documents added to the product library can be used as source information for a project. Once the source is evaluated and project compilation begins, there are numerous files used, such as MXDs and spreadsheets, for example, that may need to be stored and managed in a multiuser environment. When the project or the production cycle is near completion, outputs from ArcGIS or other systems can also be stored in the product library so they can be retrieved and reviewed at a later time.
Example 2: Data management and validation
You can associate batch jobs with product classes to store your business rules for data validation. You can also create a field configuration table that determines the way you interact with attribute fields in the Create Attributes, Update Attributes, or Metadata Attributes window when using the Production Dissolve tool.
Example 3: Cartographic production using an ArcSDE geodatabase
In this example, the file and data management and data validation capabilities from the previous examples are available. Here, however, cartographic maps and charts are the primary focus. The map documents (products in the product library) display geographic data that is maintained in an enterprise geodatabase. This geodatabase is the production database. The specific sets of features from the production database displayed in the products can be controlled by ArcGIS workflows, data frame extents, and layer definition queries. Cartographic specifications are also stored in the product library. Visual specifications are one example of this type of information. The cartographic specifications are applied to a production database on a product-by-product basis.
A variation of this architecture is used by the Aeronautical Solution. The specific features that are displayed from a production database in the product are set using extraction queries and layer definition queries. Extraction queries create cartographic copies of features to allow a cartographer to make the required hard-copy products. In this implementation, each product can have more than one instance, and each instance can include different features from the same data source based on the extraction queries.
Example 4: Cartographic and tiled data production
This example, like the ones above, includes file management, data editing and validation, and production. In addition to these functions, this scenario requires the creation and maintenance of tiled data. The tiled data can be stored in separate geodatabases (personal, file, or ArcSDE licensed for ArcGIS Desktop), and these geodatabases can be associated with product library instances. The geographic data stored in these instance geodatabases may be maintained individually within a single organization or in a distributed working environment. Both cartographic specifications and data validation information are stored in the product library and applied to production databases.
A variation of this architecture is used by the Nautical Solution. Each product has one or more instance geodatabases. Because users can work on different instance geodatabases, each user's production database changes depending on the chart or cell (product) being worked with. Each instance geodatabase contains only the data that is relevant for that product. Instance geodatabases are linked to a central database repository of geographic data using extraction queries and ArcGIS replication. The central data repository stores all the data models available for the different types of products that can be generated.