Hi

Request to tweak the behaviour of the following components.

ValidateAddress (for US)
1) Validate Address fails if the AddressLine and the other fields are not there as part of input.
2) If only Postal Code is given in input and is correct, the component should return correct city, stateprovince and county information.

ValidateAddressGlobal (for Global)
1) ValidateAddressGlobal should return the City, StateProvince and County corresponding to input Postal Code, if correct for all countries.

GeocodeUS
1) Presently Geocode Address for US returns county information if the input contains only PostalCode.
2) However it appends the word 'County' in the output.
3) This word county  is not seen appearing in the output from ValidateAddress County field.
4) Different components within PB should give consistent output.

GeocodeAddressGlobal
1) On inputting only PostalCode; for countries which have the County information, the tool is not giving.
2) Ideally on inputting PostalCode information which is correct, the behaviour should be similar to GeocodeUS, it should output the correct city, stateprovince and county.

Thank you

This would actually make the ability to choose the correct version to code against possible.  Currently if i am coding three records on the same code distinguished by address there is no way to know which of the 3 options is the one i want.

There are 17 levels for Location Precision returned by the EGM Global and World components.

However for Geocode US there is a totally different way of returning the Location Precision by the tool.

There should be consistent way of representation irrespective of the component so that it can be used by the consuming applications as such.

So we have used the Geoconfidence output from the Geocode US and mapped to one among the Location Precision returned by Geocode Address Global, World. Attached is the excel with details of mapping.

I would like to see the time stamps recorded by AddressBroler at the start and end of the geocoding process recorded in milliseconds, rather than just in seconds. Normally, the response is generated in less than one full second, so recording at a "coarse grain" such as a second does not provide much insight into how fast the geocoding operation is being performed.  There is an increasing priority on performance as time goes on, and fractions of a second matter. Recording the start and stop times in milliseconds would enable us to have a much clearer picture of how well the Addressbroker is performing.

Add the option to auto install the dataset.

This option would be similar to the Windows update where you can select and schedule to automatically download or automatically download and install.

Currently, the Addressbroker time-out, when triggered, causes the dispatcher to discard requests that have not yet been submitted to a geocoding thread. It would be much more useful to have a time-out value available to be set that causes a geocoding thread that has been working for more than the specified time to abandon the attempt to geocode and return an error. The current approach does not address the reason that incoming requests can be left on the queue - because the server is getting hung up working on requests on which it is performing poorly. If those requests were aborted and logged, the server would stay "clear", and the supporting analysts could then examine the  logs to recover the data involved and investigate.

When using the Find Address Using Server function, the cursor starts at the Geocoding Servier field. It really needs to be positioned in the first Address field to be most useful. The fields above it would seldom be changed.

The supplied MapMarker Address Dictionary can return the SegmentID for the unique street centreline that was used for interpolation.

I would like to be able to specify a unique value column when building the User Dictionary that could be used to return the unique ID of the record that was matched to in the User Dictionary. e.g., Address PFI column in VicMap Address data http://j.mp/e9xibs.

This would mean that I could correlate the match from my User Dictionary back into the source data that was used to build it, so that I can reconcile changes in the source data into my matched dataset.  Currently, I build a User Dictionary based on VicMap Address http://j.mp/e9xibs, and would like to return the Address PFI [Persistent Feature Identifier] so that when I receive a monthly data update, I can verify if the address details that were matched against have changed, as often happens.  The VicMap Address data is constantly changing and being improved and I need to be able to understand when the source data for a matched address may have been changed, so that I can re-geocode to a more accurate location.