The user attribute file is an xbase file that contains the addresses that you wish to match against the reference shapeset. It may contain other data as well, but the fields containing the postal address data should not contain non-address data.
If a user order table is not provided to the progam on the command line with the -o switch, the program attempts to discover the fields that contain address data by probing for certain fieldnames. It tries first of all for a two field format consistent with the MICRO/MACRO bifurcation ( See MICRO/MACRO). Then it tries individual attributes. If it finds fields that it seem to be of the kind it likes, it presents a list of these fields found to the user for confirmation. The user can terminate the program if the list is errorneous.
Example:
Fields with MICRO address attributes:
ADDRESS
Fields with MACRO address attributes:
ZIP
Type y (return) to confirm list, n (return) to reject.
In this case, the user attribute table has at most two fields that observe the MICRO/MACRO. That is, it may have one field named ADDRESS, in which the MICRO attributes are all located, along with a number (possibly zero) of MACRO attribute fields. Or it might have a number (including at least HOUSE and STREET) of MICRO fields (HOUSE, PREDIR, STREET, SUFTYPE for example) along with a single MACRO field. Or it may have only the MICRO attributes and no MACRO field. Or it may have both a single MACRO and a single MICRO field.
MICRO , ADDRESS , COMPLETESTREETNAME , FEATUREADDRESS
MACRO, PLACESTATEZIP, LASTLINE
In this type of user attribute table the fields tend to correspond more closely to the postal attributes.
HOUSE , CIVIC , ADDRESSNUMBER , HOUSENUM , NUMBER , HOUSE.NUM , HOUSE_NUM , HOUSE-NUM , HOUSE.NUMBER , HOUSE_NUMBER , HOUSE-NUMBER , HOUSE_NUMB , STREETNUMBER
FEDIRP , PREDIRECTIONAL , DIRECTION, PREDIR , DIR, PREFIX , FDPRE , PRE.DIR , PRE_DIR , PRE-DIR , STREET.DIR , STREET_DIR , STREET-DIR
STREETPREFIXTYPE, PRETYP, PRETYPE, PRE.TYPE, PRE_TYPE
FENAME, STREET, STREETNAME, FNAME, STREET.NAME, STREET_NAME, STREET-NAME, STREET_NAM, ST.NAME, ST_NAME, ST-NAME, STR.NAME, STR_NAME, STR_NAME
FETYPE, STREETPOSTTYPE, SUFTYP, SUFTYPE, STREETTYPE, TYPE, FTYPE, STREET.TYPE, STREET_TYPE, STREET-TYPE, STREET_TYP, ST.TYPE, ST_TYPE, ST-TYPE, STR.TYPE, STR_TYPE, STR-TYPE
SUFFIX, POSTDIRECTIONAL, FEDIRS, FDSUF, SUFFIXDIR, SUFDIR, SUF.DIR, SUF_DIR, SUF-DIR, SUFFIX.DIR, SUFFIX_DIR, STREET.DIR, STREET_DIR, STREET-DIR
CITY, PLACENAME , LOCALITY, MUNICIPAL,
PROV, STATE, REGION
ZIP, ZIPCODE, ZIP-CODE, ZIP_CODE, ZONE, PCODE, POSTAL, POSTALCODE, POSTAL_CODE, POSTAL-CODE, PC, CODE , FSA
ZIP4 , PLUS4 , LDU
COUNTRY, NATION
The user order file is a short xbase file that tells PAGC what fields of the user attribute file contain the address data. It is used in the matching phase to correctly read and standardize the user's table of addresses. The order table is an xbase (dbf) file which consists of three fields:
The order file has a three fields structure:
| Field Number | Field Name | Type | Size |
| 1 | ATTRIB | C | 8 |
| 2 | FIELD1 | C | 30 |
| 3 | FIELD2 | C | 30 |
Each row of this table will consist of a postal attribute ( See Postal Attributes) in the ATTRIB field, and a fieldname of the user's address table in FIELD1. This table conveys to the program which field in the user's table a particular attribute will be found.
FIELD2 is normally blank, except when a POSTAL attribute is split into two different fields in the user's address table. In this case FIELD1 will give the name of the first field and FIELD2 will give the name of the second field of the postal/zip code. This is to provide for ZIP/ZIP+4 tables for US addresses and for those Canadian address tables that isolate the FSA portion of the postal code.
As an example, consider an address table that contains addresses extracted from a city phonebook. The xbase (dbf) file may contain the fields NAME, ADDRESS, ZIP, PHONE. Since the phonebook tacitly assumes the city/state, these are among the attributes are omitted from the ORDER table. The program is directed to look in the ADDRESS field for all the remainingpostal attributes except the POSTAL, which will be found in the ZIP field.
Example: phnbkord.dbf:
| ATTRIB | FIELD1 | FIELD2 |
| HOUSE | ADDRESS | |
| PREDIR | ADDRESS | |
| QUALIF | ADDRESS | |
| PRETYP | ADDRESS | |
| SUFTYP | ADDRESS | |
| SUFDIR | ADDRESS | |
| POSTAL | ZIP | |
If no table of this sort is provided, the program attempts to construct the structure from probes.
The user attribute record is read in the order determined earlier. First the MACRO portion is standardized, using only the MACRO_C rules, and only the best standardization retained. An error is produced if no MACRO portion is found or if no standardization is found. This record is then bypassed and a null record is written to the shapefile. Otherwise the MICRO portion is standardized, using all the rules except MACRO_C rules. Again, errors are logged if it is missing or cannot be standardized, the record bypassed and a null shape produced.
No standardized version of the user attribute record is retained. PAGC is completing a shapeset by complementing the user's unstandardized .dbf table with the .shp and .shx files. Each record corresponds one to one with a point shape. If the program is unable to find the coordinates necessary for a point, a null shape is added to maintain the correspondence.