Stage 2: Conceptual Data Modeling

The Integrated Cadastral Fabric data model was deemed as a good reference for creating the Visio UML data model for Pitt Meadows. The general goal for data model construction followed by OD was to link all data to the cadastre layer, which was a similar format to the ICF data model. The following were the steps involved in creating the data model:

a) Identifying feature and attribute layers
Due to time constraints, not all data available could be incorporated into this initial phase, and priorities were made according to the District's business requirements.

With that guideline in mind, the following layers were listed as highest priorities:
- Cadastre (including parcel annotations and related attribute tables)
- Utilities (water, sanitary, storm, water services, Pitt Meadows septic system)
- Land use and zoning
- Transportation (Roads)
- Agriculture (soils, crops, capability and related attribute tables)

b) Identifying the attributes
All attributes in the selected data layers were looked over before incorporation to the final geodatabase. A few fields were deemed meaningless, including the attributes that were generated automatically when converting source data to coverages or shapefiles, and included Arc/INFO IDs, Area and Hectares. More specifically, Area and Hectares (associated with shapefiles) were rejected because they are immediately outdated when the data is manipulated.

Once all valid attributes were identified, a list of the attribute columns and associated length were created for keying into Microsoft Visio. A 'primary key attribute', the common attribute column between linked layers, was selected in each layer. Since all feature layers are linked to the cadastre in the data model, the primary key attribute is confined to the attributes available in the cadastral feature layer, such as Jurisdiction roll numbers (JUROL or PCLLINKSID), zoning code and addresses. The address field was used to link roads to the cadastre zoning code both ocp_rural and ocp_urban were linked through zoning codes and landuse information. The other layers were linked through their roll numbers.

Once all valid attributes were identified, a list of the attribute columns and associated length were created for keying into Microsoft Visio. A 'primary key attribute', the common attribute column between linked layers, was selected in each layer. Since all feature layers are linked to the cadastre in the data model, the primary key attribute is confined to the attributes available in the cadastral feature layer, such as Jurisdiction roll numbers (JUROL or PCLLINKSID), zoning code and addresses. The address field was used to link roads to the cadastre zoning code both ocp_rural and ocp_urban were linked through zoning codes and landuse information. The other layers were linked through their roll numbers.

In some data layers, there was simply no attributes common to the cadastre, and to solve this, a unique id was created for each parcel in cadastre (See c., Unique ID). This unique ID was then populated into an intermediate table and used for linkage (See e. Intermediate Table). However, for the Storm and Sanitary feature layers, this type of linkage was not possible. To populate the road centerlines and other line features of these layers with the parcel unique id, they needed be segregated by parcel segments, which will have to be done in the future. To illustrate, following is a screenshot of the Storm layer.

c) Creation of Unique ID
The Unique ID was created by combining the JUROL and PID values in each Cadastre layer record, using the calculator function of ArcGIS. Unique ID works well for linking the cadastre to polygon feature layers without common attribute fields when defined polygon boundaries don't match those of the cadastre. This was the case for the soil and capability layers, and required an intermediate table for linkages (See e. Intermediate Table).
Note: Unfortunately, due to time constraints, no Unique ID was used in the final data model. This should be a relatively quick assignment for future enhancements.

d) Determining relationships
The Geodatabase compiled for this project uses one-to-many relationships. Some of the data (e.g. soils and capability) provided by the District relate to the cadastral feature class through many-many relationships. However, no many-to-many relationships were inputted into the Geodatabase for this project, due to time constraints. Most data layers were linked to cadastre through roll numbers JUROL or PCLLINKSID. These were roll numbers that were not unique, since one person can own many parcels. Some resulting linkage had records with the same roll number but differing attribute values. For example, many species with identical roll number linked to numerous parcels having the same roll number in the cadastre layer.

Road layers, on the other hand, could be linked through address as one-to-one relationships, under the rule that parcels have unique address house numbers. Ocp_rural and Ocp_urban used the ocp landuse definition field, linking to the cadastre's zoning codes. As shown in the table below, this relationship is one to many. However, due to time constraints, Roads, Ocp_rural and Ocp_urban were not incorporated into the final data model.

e) Intermediate Tables
Layers linked by Unique ID and zoning code required intermediate tables. The values of these could then be populated into the relationship class table of the geodatabase. For layers linked by Unique ID (i.e. soil or capability), the intermediate values was created through an overlaying technique using the workstation ARC/INFO INTERSECT command, 'between' the updated cadastre with unique ID and the corresponding data layer. The ARC/INFO INTERSECT command creates a new data layer populated with an attribute field contained in both the cadastre and the linked data layer.
Note: Due to time constraints no intermediate tables were utilized in the final data model.