Methodological Problems and Limitations

At first, OD attempted modeling many-to-many relationships to link parcels in the cadastral layer to every other feature layer or attribute table to the cadastral layer. However, many-to-many relationships must be modeled using an intermediary relationship class that holds data values necessary to link the data tables together. Populating the relationship class data tables required either manual data entry or the use of a visual basic script. Both of these options were too time intensive considering the deadline date, so other methods of data modeling had to be considered (e.g. use of one-to-many relationships where appropriate, and the dropping of feature classes from data model if required).

Soils, capability, and OCP_Urban did not contain any fields with which they could link to any other feature layer or attribute table in the data set. The original plan was to link soils and capability to the cadastral feature layer by populating a relationship class with values determined by using the intersect command in ArcInfo. These classes could not be joined to the model due to the complexity of populating the relationship class data attribute table, as described above. OCP_Rural was not added because there was no way to link OCP_Rural to the zoning code. Also OCP_Rural is out of date; it doesn't contain all parcels in the rural area. Furthermore, there are many OCP land use definitions that do not match the zoning code.

The Water utility (line layer) was not added because the original GIS file generated from AutoCad does not contain any attributes. The District's engineering department has attributes for this data in their water model, but we understand the only way to add these attributes into the GIS file is manually. It can only be added manually because the geocode information in these attributes only applies to the water valves point data, not the Water Utilities feature class.

Zoning codes for each parcel was added to the cadastre layer by Pitt Meadows GIS staff during this project. The zoning attribute table is actually a table that contains the actual zoning code definition. The original zoning feature class layer is out of date (plus only for urban area) with arbitrary (miscellaneous) lines running through parcels. Therefore, the zoning feature class layer was not added to the data model.

The roads layer was not added because the Cadastral layer (used to link to Road layer) was missing many addresses or house numbers. Furthermore, some of the street names are different between Roads and Cadastral layers (e.g. there are over 600 records to re-name in the Cadastral layer alone). The Storm and Sanitary sewer layers (in AutoCad drawing format only) lacked attribute data which caused a problem for linking to the data model. Essentially, for the Storm and Sanitary feature classes there was no data to add to the geodata model.

In general, there was a lack of common attributes in the feature classes and attribute tables to make easy linkages, between primary and secondary keys. Also, there was a poor match between ICI attributes and Pitt Meadows attributes. In other words, the Pitt Meadows attributes do not show up in the ICI data model, and vice versa. In addition, there was a general lack of metadata.