[Date Prev][Date Next] [Chronological] [Thread] [Top]

# RE: Gems - Merging of totals from old I-Mark software

- To: "Rcr List (E-mail)" <rcr@dieboldes.com>
- Subject: RE: Gems - Merging of totals from old I-Mark software
- From: "Ken Clark" <ken@dieboldes.com>
- Date: Mon, 13 Sep 1999 12:35:19 +0100
- Importance: Normal
- In-Reply-To: <01BEEFB6.9BA83110@sdn-ar-002neomahP044.dialsprint.net>

> The capability of Gems to be able to merge the results from the
> old I-Mark software. The state of Tennessee is only certified
> with the old I-Mark software, as well as, the old Touch Systems
> AVTS units. Hence, we will need to run both the old I-Mark
> software for the AVTS units, and the Gems software for the Postal
> Ballots, and then merge the two different systems totals.
>
>
> Jeff Hintz
> Global Election Systems

This is now complete. It will be in GEMS 1.11.6 when it is released. Jeff, I will send you a pre-release for testing today. Since this feature is only useful for Shelby, we'll hold off on a general release for now.

To set up a database for importing IMARK results, you need to:

- Create a GEMS database with matching precincts, races, and candidates as the IMARK 1.1.3 database. Set up the Export IDs to match the keys in the IMARK database.
- Set up a counter group and vote center category for the IMARK results. The totals will be counted into the default vote center for the vote center category. This vote center will have all precincts of the IMARK database. The count method for the vote center you can leave as AccuVote -- it doesn't really matter as long as it is there.

There is now a new menu item under "File" called "Import IMARK results". It pops up a dialog where you select the vote center to count the totals into (the default VC above), and the IMARK mdb to import from. Select the IMPORT button and it will do the rest.

Caveats:

- This feature needs serious testing. Really.
- You must have a separate counter group for the IMARK import, it must have exactly one vote center, and that vote center must have exactly one counter group and "memory card".
- There is no way for GEMS to know if the Export IDs really match the IMARK database. If the IDs don't match, then GEMS will import the results into the wrong counters without warning. Review your export IDs very carefully, and do a serious L&A whenever using this feature. In particular, be very careful that the candidate export ids match the IMARK ids, since getting them in the wrong order will swap results.
- GEMS checks that all counters are imported. If a precinct/race/candidate is missing in the GEMS database, then the import results will be wrong, and you will be warned. Don't ignore these error messages. I decided not to issue a error if the GEMS has *more* precincts/races/candidates than the IMARK database. If the totals are not there, they are not there.
- The 1.1.3 IMARK database does not track ballots cast by precinct, so there is no way to import those statistics. I have faked the voter turnout results based on the race counters to compensate. This should work fine as long as there is a precinct-wide race in every precinct, or by extension a jurisdiction wide race. This will give correct numbers in the SOVC and Summary reports, but the Card Cast report will be completely bogus.
- You must not have any other counter related process running when you do the import; specifically upload or central count. The import just shoves the totals into the counts without any respect to the GEMS poster, so the poster is likely to be unhappy if it is running while the import process does its thing.

Ken

- Prev by Date: TS Headers for El Paso CO (was RE: headers)
- Next by Date: scale fonts on TS
- Index(es):
  - Chronological
  - Thread