Often, the source data model is dictated by the package used to collect the data. In many organizations, computer-aided design (CAD) packages are used to digitize information. Because CAD packages typically store only graphical properties, "real-world" attributes often are encoded in the data by carefully choosing display characteristics such as color and line style.

A direct load approach into a spatial database reads the data from its source format, performs a data-model conversion as the data pass through memory and writes directly to the destination database. This approach has several advantages, speed being foremost among them. Provided the loader has a rich enough semantic translation capability, value can be added to the data on the way through. For example, as the data are loaded, self-intersections can be removed, and improper polygonal topology can be repaired.

In addition, dramatic data model changes can be performed, resulting in a more useful view of the data being stored. Rather than simply loading the data and leaving their vocabulary the same as when they were collected, attributes and their meanings can be expressed more directly in the spatial database.

No matter which approach is used to load the data, it's important that the loading tool supports transactions. Because some spatial databases will reject input that doesn't meet geometric integrity checks, a "transactioned" approach allows a failed load to be resumed at a point just prior to where the error occurred.

After the data are successfully loaded into the database, they must be indexed to facilitate fast access. Attribute and spatial indices should be created, depending on the nature of the queries that will be posed. All the activities associated with regular database tuning apply equally to spatial database tuning (e.g., allocation of tables and indices to disk areas, choice of block sizes, etc.), but with the additional challenge of the spatial index.