How does MPMileage handle multiple address matches from Maptitude?
Maptitude can report multiple matches when locating points with partial addresses. MPMileage's behavior is controlled with the Multiple address matches will be considered ambiguous, and skipped checkbox on the Input Locations dialog box. If you set this checkbox, MPMileage will consider all such results and "ambiguous", i.e. not found. If you clear this checkbox, MPMileage will use the first location returned by Maptitude.
When searching for a partial address, Maptitude tries to find an exact match. If it cannot do this, it tries a 'contains' match. This will often return multiple results. If population data is available (e.g. for a city or post code), these points are then sorted according to population size. It is assumed the larger location is the most likely.
How can I improve the processing speed?
MPMileage has been written to take advantage of modern processors, and hence can perform route calculations much more quickly than MileCharter. However, some of this speed depends on a correct configuration. Here are some suggestions for speed:
•Make sure your database has an index on the start and end location fields. These two fields are used as references for both reading and writing the data. Note that indexes cannot be applied to Excel workbooks. Large datasets should be implemented using a proper relational database using Microsoft Access or via an ODBC connection.
•Remove duplicate rows from the input data. MPMileage is clever enough to avoid duplicate route calculations, but duplicates will always slow data reading and writing.
MPMileage does not want to write numeric values to Excel
All output values, regardless of the database, are written in the format of the data field. Unlike a true relational database, Excel is weakly typed. Therefore it is possible for a cell or column to appear to be blank or un-typed, but Excel reports it as being text.
The solution is to clear the entire column, and then format it as a number with two decimal places. You may have to re-enter the column header (if there is one).
MPMileage does not recognize the Excel columns that store my location names
This usually occurs if your location names are numbers. Location names are often numbers if you are using your own numeric identifiers, or if you are using zipcodes. Excel is weakly-typed and will usually treat these as numbers. However, the locations must be text for MPMileage to recognize them, and for MapPoint comparisons to work properly.
It is strongly recommended that you use use a proper strongly-typed database (eg. Access or an ODBC connection) for applications like this. However, if you must use Excel, format the entire column as text and precede each and every value with a quote (') character. The quote character tells Excel that the field is text and not a number. An alternative is to use text location names.
I cannot open my Excel workbook when MPMileage is loaded
This is a side-effect of the Excel database driver. You have to exit MPMileage in order to view the workbook. This is another reason to switch to a proper database such as Access.
MPMileage opens a table but cannot see any/all of the columns
MPMileage must have read/write access to both the table and the columns. This is also true for the location columns. The only exception is the primary key column, which can be read-only.
How do I set the country / region?
MPMileage will use Maptitude's current country/region for geocoding and street routing. This is set by selecting Edit -> Preferences to display the User Preferences dialog box:
Set the geocoding and street databases in the Default Data Region box at the top.