Validation rules define the fields to be used to match an address in the postal table, how each field should be matched (exactly or approximately) and the prerequisites for each field.
The Trillium Geolocation Server uses a default set of validation rules. You can override the default rules using the options in the Validation section of the gaserver.ini file.
Validation rules are used sequentially. The server attempts a match using each rule in turn until it finds a rule with which the input data can be matched to the postal table. Once a suitable rule is found, no further rules are used for that input record. The first rules in the sequence attempt to match more address components to the postal table with more precision. Subsequent rules use fewer address components and introduce fuzzy matching for some fields instead of exact matching. The final rules will match on just one address component, either city or postcode. If none of the rules are suitable, the input record is unprocessed.
If you elect to modify validation rules, you must provide a complete set of new rules. You cannot override individual rules.
The table given below describes the keys available in the Validation section of the configuration file.
Key |
Description |
---|---|
RuleCount |
The number of validation rules in the rule set. |
Rule<1 to n>
|
Specifies each validation rule, using the following syntax: Rule<n>=<Component>, <Search Type>, <Prerequisite> [,<Prerequisite>+] Criteria are surrounded by either [] or () to specify compulsory or optional criteria respectively. Component is one of the following:
Search Type is one of the following:
|
Rule<1 to n> (continued) |
Prerequisites consist of one of the component types and an optional value. If no value is specified, then the specified field must only be populated for the prerequisite to be met. For example: [Sub Building E,Building] contains a prerequisite that specified that Building must be populated for the rule for Sub Building to be processed. If a value is specified, then the field must match the value exactly for the prerequisite to be met. For example: [Postcode E,City=“LONDON”] specifies that City must contain the value “LONDON” for the rule for Postcode to be processed. Prerequisite values are case-insensitive.
If prerequisites exist, one or more of them must be satisfied for this rule item to be processed. This is an example of a complete validation rule for address validation:
For this rule to process, there must be an exact match on the Postcode field between the input data and the available reference data. If there is no input data in this field, no available reference data for this field in this data set, or no exact match, the rule will immediately fail and processing will move to the next rule. If input data exists in the Region, City, or Street fields, an approximate search will be performed to see if matching data exists in the reference data. An approximate search on the Premise field will be performed only if the search for a matching Street has been successful. |
RulesetName |
Optional. The name of the rule set, used for logging purposes only. |
RuleName<1 to n> |
Optional. Specifies a name for the validation rule. If specified, the name of the rule used to process a record will be returned to the caller. If not specified, the names will be generated as Rule1, Rule2, etc. |