Search options

Format:

{Dataset Code}EngineTimeout={Integer}

Default:

None

Purpose:

The length of time (in milliseconds) that Pro Web will spend on a search before it returns a timeout flag. A setting of 0 sets the timeout to infinity.

Examples:

To set a global timeout period of 30 seconds (30,000 milliseconds), set EngineTimeout=30000

To set a timeout period of 30 seconds for the USA dataset (30,000 milliseconds), set USAEngineTimeout=30000

Format:

IntuitiveEngineTimeout={Integer}

Default:

1000

Purpose:

The length of time (in milliseconds) that Pro Web will spend on searching before it stops and returns a list of suggestions. If set to 0, it will default to the value set for EngineTimeout.

To set a timeout for all other search engines, use the EngineTimeout setting.

Example:

To set a timeout period of 0.5 seconds (500 milliseconds) for the Intuitive engine only, set IntuitiveEngineTimeout=500

Format:

SearchTermDelimiter={Character}

Default:

| or , (either will be accepted if not set)

Purpose:

You can customise the API to use a different search term delimiter. For example, you can set the premises entry line to be divided from the street entry line with a pipe (|) character. You should use a character that is unlikely to be returned within an address.

Example:

SearchTermDelimiter=|

Format:

{Dataset Code}EngineIntensity={Integer}

Default:

1

Purpose:

The keyword controls the degree of 'fuzzy' matching which is used when searching for addresses as specified by the input search terms. Possible values are as follows:

The fuzzy matching engine will start at the default setting, and look for a match to the input search terms.

This can be CPU intensive if it is above 0 (Exact). If no matches are found, it will proceed through the levels up to and including level 2 (or until EngineTimeout occurs) before giving up.

Examples:

EngineIntensity=1

USAEngineIntensity=1

Format:

[identifier]CacheMemory={Integer}

Default:

0

Purpose:

This keyword is used to specify the amount of system memory (in MB) that Pro Web can use for data caching. This is in addition to the normal system memory required by the Pro Webserver. Caching is disabled by default, but you can use this keyword to increase the performance of Pro Web by allowing it to use system memory. If your system has less than 500MB of memory available you should not use this setting.

Caching is specified for each data mapping. [identifier] must correspond to a data mapping identifier in the DataMappings keyword. You must ensure you have enough available system memory for all the data mappings for which you add a CacheMemory keyword.

Example:

The following setting would allow Pro Web to use up to 512MB of memory for caching data for the USA data mapping.

USACacheMemory=512

This setting applies to APR, APX, USA and FRX data only.

Format:

Constraint=,

Default:

None

Purpose:

Allows you to limit your search results. The exact behaviour and supported search engines vary depending on the datamap used:

Example

USAConstraint

Allows you to limit Intuitive search results to one or more states (using state code). If no values are specified, addresses in all the states will be returned. This setting can be applied to a specific layout or used as a global setting in the [QADefault] section in qawserver.ini.

[QADefault]

USAConstraint=L11,FL
USEConstraint=L11,NY,MA

APRConstraint

APXConstraint

Allows you to filter out all entries that are not postally valid from Singleline, Typedown or Verification search results. This setting can be applied to a specific layout or used as a global setting in the [QADefault] section in qawserver.ini.

APRConstraint=L25,*
APXConstraint=L25,*

Format:

InputLineCount={Integer}

Default:

0

Purpose:

This keyword is used to define the number of lines your input addresses contain. The format of each individual address line is specified with the InputLineN keyword. Note that any lines not covered by your specified input address format will not be constrained to match to specific reference address element types.

Example:

InputLineCount=4

This tells Pro Web that each input address should contain four lines.

This keyword affects the Verification engine and the Default prompt set only.

Format:

InputLine1=

InputLine2=

InputLineN=

Default:

Blank

Purpose:

This keyword specifies which address element is to appear on which line in the input address. If you want a line on your address entry page always to contain the same type of address element (for example, line 4 always contains a town name), you can mark that line with an element code. This improves the speed and quality of matching.

< element list> represents a comma separated list of element codes, either dataset-specific or generic. By specifying an element code, you tell the engine what element to expect on that line (if the element exists in the matched address).

It is important not to supply non-address information to the engine (where possible), as this may compromise the address matching process. In particular, supplying additional non-address numeric values can cause confusion when matching against premises information.

If you are using a defined input layout, you should set the search term delimiter to the pipe (|) character using the SearchTermDelimiter setting. This will avoid Pro Web treating any commas within input address lines as line-breaking characters.

Example:

InputLine1=O00

This instructs the engine to expect organization names on line 1 of the input address.

The generic element codes are listed in the following table, in the order in which they will appear in a formatted address (unless you fix them in a different order on the address line).

See the Data guide supplied with your data for a list of dataset-specific element codes.

Format:

[identifier]SinglelineInternalRefine={Boolean}

Default:

True/Yes

Purpose:

This setting can be used to disable the Singleline engine internal refinement optimization introduced in Pro v7.79. The internal refinement mechanism can reduce the search time in Singleline searches, when very common words or very short wildcard terms in the search line would generate a huge amount of match candidates that need to be evaluated.

The list of common words used by this mechanism is defined in the address data and currently is only available for GBR. The minimal length limit for a wildcard search term affects all data sets equally.

The [identifier] part is an optional data mapping prefix, which will make the setting specific to this data only, if omitted – the setting will apply to all data sets.

When the optimization is not active, Singleline searches containing elements that are very common, like "Flat *", often take too long to evaluate all possible matches, which may lead to a timeout.

Example:

The following setting will disable the internal refinement optimization for all data sets:

SinglelineInternalRefine=No

The following setting will disable the internal refinement only for GBR data mapping:

GBRSinglelineInternalRefine=No