- GravitecDevelopment

Date

Description of Change

Feb. 10, 2014

The maximum number of neighborhoods available has been raised from 200 to 400.

Nov. 14, 2013

A user has reported errors when trying to load the demographics from the FIT program into the SITESPLUS FIT Demographics worksheet.  This error only happened when the number of sectors was greater than 500.  That "artificial" limit has been lifted to 2,000.

Nov. 8, 2013

When running a macro, two of the FIT reports did not create the projected form of the report, but instead created the current form.  These errors have been corrected.
In addition, a user has requested the ability to designate distance limits for macro reports.   The correct macro-line format for designating a distance limit is:

       DISTANCE  max

where "max" is the distance limit, in miles.

May 8, 2013

A user has reported that SITESPLUS is reporting distances incorrectly when the project is configured to use kilometers instead of miles.  This error has been corrected.

April 12, 2013

A user reports that converting leakage to one store is not working correctly if based on store powers.  The command is working correctly if based on even distribution.  The trouble was caused because SITESPLUS was not automatically calculating immediately after converting leakage based on store powers.  This problem has been corrected.

March 15, 2013

A new command has been added to assist in loading project data from outside sources.  The command is "File | Load Tabbed Text File."  This will cause SITESPLUS to open a text file of your choice and attempt to read lines of data, adding stores and/or sectors with each data line.  Note that the first line MUST be a dictionary line describing the data lines to follow, and all fields MUST be separated using the [Tab] character (not spaces or commas).  Download instructions.

March 8, 2013

If your project had store IDs that were quite large (greater than 1000) and you rebuilt one of those stores, SITESPLUS sometimes had trouble representing the new store ID correctly because of decimal-to-binary translation rounding.  This problem would most often become visible when opening the project file and receiving Sister Store Addition errors.  The problem has been corrected.

Dec. 17, 2012

When using the [Excel Save] buttons in the Store or Sector datasheet, SITESPLUS would correctly generate the Excel files, but the column headers were not "database friendly."  That is, the headers contained characters that are illegal in many database programs.

Those column headers have now been changed to be more database friendly.  Note that the headers in the datasheets have NOT changed, only the headers in saved Excel files.

Dec. 15, 2012

A user has requested an enhancement to the Data Map graphic, and we have added three new sector label choices:

    Black population (count)
    Hispanic population (count)
    Asian population (count)

Dec. 11, 2012

A user has reported a program crash during the editing of a very large project.  The crash only happens if a neighborhood definition contains an extremely long line of characters, greater than 1,024.  This error has been corrected.

Dec. 3, 2012

Two changes have been made in response to user requests:

1.  A new Change Balance Tolerances command has been added to the Calculate menu.  For user with very large models, this command may enable you to save a tremendous amount of time by allowing you to perform the "Balance Powers" command to a limited state of completion.

SITESPLUS normally balances powers until the average misbalance per store is only $.33.  During a "rough" balance in a large model, though, you may be able to tolerate a misbalance of $1,000 or more per store.  Setting the misbalance figure to $1,000 may save as much as 90% of the balance time while achieving 98% of power accuracy.

2.  The format for the Projected Chains-2 report has been changed slightly when requesting neighborhoods for the report.  The market share figures previously had an asterisk ("*") appended to each market share, referencing a footnote below the report.  When converting the report to an Excel sheet, Excel would not see those MS cells as a number because of the asterisk.  The asterisk will now appear in the headings instead.