AFD Products: Refiner Manual

ADVANCED CLEANING SETTINGS

The Settings Tab (Shortcut Key [Alt]+4) includes an "Advanced Settings" button which allows you to configure some of the more advanced options related to Refiner cleaning.

In most cases the default settings are the best for cleaning data and will not need to be altered.

Note that you can reset Refiner cleaning settings to the defaults by selecting the "Reset To Default Settings" option on the File Menu.

Database Settings

These settings affect how data is written back to your database.

Retain any alias locality in the source address
Where an address is fully matched to PAF, Refiner will write back the full correct postal address to your database. Sometimes, your address data might contain a locality which is not postally required, such as "Wimbledon", this will be removed should your address be matched as it does not form a necessary part of the address. Should you wish to retain such localities, as long as they are recorded by Royal Mail as a permisable locality alias, you can enable this option and Refiner will assume they are correct if given in the source data.

Never move source data to the Organisation field
Normally Refiner will put additional address data for street level matches in the property or building field unless they look like an Organisation or there is already a property. Specifying this option ensures Refiner never returns such data in the Organisation field - useful if you are not writing that field back to your databases data (the data will instead always be added into the property field).

Write back an empty string rather than null for blank fields
When using a Microsoft Access database or connecting to an ODBC source, it is assumed that where a field to be written out is blank a NULL should be assigned to that field as that is the normal convention with such database systems. However should you prefer, or your database system require, a blank string instead then selecting this option will force Refiner to output an empty string in such cases.

Write back a default DPS for street addresses
The DPS is a delivery point suffix, used by Royal Mail to uniquely identify an individual property on a postcode and included in the customer barcode which can be printed on an envelope. This is most useful to customers who are cleaning data for the purposes of using Royal Mails customer barcode mailsort products. Where an address can only be matched to street level, no DPS is avaliable and so none will be written out. By selecting this option a default DPS (9Z) will be written out for such addresses allowing them to be included in such sortations. However, please note that Royal Mail will be enforcing a minimum requirement that means that the vast majority of addresses in your data will need to have a full accurate DPS, not a default one, to be eligible.

Cleaning Settings

These settings affect the way in which Refiner matches your data.

Do not attempt to format fields for unmatched addresses
Where Refiner cannot match an address it will attempt to logically format your source address into the output fields automatically. For example something ending Street will be placed in the Street field, something that looks like the postcode would go into the postcode field etc. If you are writing data out to the same number of fields as are present in the source address and the format of the original data is already good you may prefer to retain your existing address format in such cases. Selecting this option will cause Refiner to simply write out your source address data fields in order in your destination fields should it be unable to find a match (or leave it alone if you are writing back to the same fields).

Assume source data does not contain field separators
Refiner normally expects to find each address element in a seperate field, for example the street in one field, the town in another, etc. Where this is not the case it would expect to find a separator, such as a comma, delimiting each address element in a field. Should these delimiters often be missing, e.g. you have the street and town all in one field with only a single space between each one and nothing to determine where one field starts and another one ends then using this option will allow Refiner to be able to match the address. Note that this option should only be used were your database requires it as the number of extra searches this requires means that speed of processing will be severely increased.

Match to PO Box only after trying a physical address match
Sometimes an address may contain elements of both a PO Box and a geographical address. In many cases only one of these may be correct and matchable, however sometimes they both could be and Refiner will attempt to match the PO Box address first in such cases. If you prefer physical addresses selecting this option will force Refiner to try and match a physical address first. Note that you will still get a PO Box match if no geographical address can be matched.

Assume original postcode is correct
Refiner uses advanced matching algorithms to find the correct match for your address while also ensuring that incorrect matches should not be given. In some cases your address data may have many fields missing, for example were only the property details and postcode have been captured, that means that very few addresses can be properly matched. In such cases if you are fairly certain of the accuracy of the postcodes held in your database you can select the option to direct Refiner to make an assumption that the original postcode is correct where a match cannot otherwise be made. This option is risky as you will obtain the wrong address should the postcode be incorrect so should only be used for non-sensitive uses of address data were it still has value even if some data is incorrectly matched. When used with attach mode you simply need to map in the property and postcode and the other fields will be attached based on those. When used with the default cleaning mode Refiner will still try to obtain a fully accurate match first, but if that cannot be made it will assume the postcode is given is correct and attempt a match on that basis.

Ambiguous Settings

When Refiner cannot make a unique match, an ambiguous one can sometimes be made instead, for user review. These settings allow you to switch off or adjust when such results are given.

Do not return ambiguous results (return no match instead)
Where Refiner cannot make an exact match, but can determine several possible correct matches, an ambiguous match will be given which allows the user to manually select the correct result if that can be determined through manual review of the record. In an automatic cleaning process the result code will indicate that the record is ambigious but the original record will be retained, so this option makes little difference other than the exact result code returned. However if you do not wish to be advised of ambiguous matches you can enable this option.

Do not suggest un-verifiable matches (return no match instead)
In cases where in-sufficient address data has been supplied for Refiner to make an exact address, it is sometimes possible for Refiner to suggest a match due to their being a unique match to the data supplied. In such cases Refiner cannot confirm the match automatically as it may not necessarily be the correct one, but in the course of a manual process a user might be able too. Like ambiguous matches these will never be written back to the database in an automatic process, they have to be reviewed by the user. If you do not wish Suggested Matches to be returned you can select this option.

Ambiguous match is preferable to a street level only match
In some cases a match is ambiguous if matched to property level, but Refiner can return a street level match retaining the existing property information instead. This is normally preferred as with large databases the more that can be reliably cleaned automatically the more the savings in terms of user time. However, if you are manually checking records you might prefer to see the ambiguous matches in such cases to see if you can locate the correct result with human insight and so turning this option on will enable you to do so.

Grid References

This allows you to change the options for how Grid References and Latitude and Longitude values are returned.

Display Grid References
By default British grid references are used for British postcodes and Irish Grids for Irish postcodes. However in some cases you might wish to standardise on one or the other, for example when comparing distances between them. So, using Grid Reference Options you can select to always use either GB (British) or NI (Irish) grid references.

Where a grid reference is not available for a Postcode, there is an option to use an approximate grid reference for the locality or town. This is of course a lot less precise, but may be more useful than a blank grid reference for uses such as finding distances, locating an address on the Map etc.

Grid Reference Resolution
Unless you have purchased 1m grids, grid references are supplied to a 100m resolution. However you can choose if these are displayed as a 5 digit or 6 digit grid reference depending on the form that you need for the data. A 6 digit grid (usually 6 digits for both the northing and easting values) is capable of displaying 1m grids if required.
Latitude and Longitude Display
For latitude and longitude you can choose to use either the decimal value or a value made up of the degrees, minutes and seconds. Generally a decimal value is more useful for storing in your database to manipulate in other programs, but the degrees value is more easily readable when presented to an end user.

For more information about Grid References see the Grid References Appendix.

Address, Postcode and Bank solutions