Re: Proposed Electronic Ballot Image Format for the Demo

From: Dennis Paull <dpaull_at_svpal_dot_org>
Date: Sat Aug 23 2003 - 15:50:16 CDT

Hi Alan et al,

In the interests of easing voter verification, I think it advisable
to display the office being sought along with the name(s) of the
candidate(s) voted for. The STCOPREXXXXY needs to appear no more
than once per ballot. Some ballots have a large number of races. In a few
cases, the same person can run for more than one office and in a few
cases, such as County Central Committee, can hold more than one office.

Whatever can be done to make it easier for the voter to verify what
they voted for should be considered. Some voters aren't too bright.
Others will have language questions or for whatever reasons will have
trouble quickly reviewing their vote choices.

At the same time, we need the printed ballot to be machine readable.
These two requirements are not mutually exclusive but they might also be
somewhat of a question. Is the barcode intended for machine readability?
If so, how does the voter know that what is written is the same as
the bar code? If the machine uses OCR, it should be fairly easy but
the technology is a bit trickier. But not much. I recommend using OCR.

One could argue that the ballots will only be read during a manual
recount. I think that the ballots should be readable during a machine
recount using a machine different from the one used in the precinct
to generate the ballot. Of course, it needs to be readable for the
manual recount as well.

Dennis Paull

At 11:23 AM 8/23/2003 Saturday , Alan wrote:
>I propose that the raw vote data be stored as follows in a plain comma
>delimited character format -- one row per ballot.
>Like so,
>Where STCOPRECT stands for State, County, and Precinct. XXXX is the ballot
>number. Y is an extra character we may or may not use -- it could be used
>to designate alternative schemes for mapping characters to bit patterns ...
>or it could be used for something else. The ten "C"s hold the encoded
>ballot selections. Write-in names follow with the 2-digit number indicating
>the applicable contest (should the write-in names be encrypted?).
>This fixes the basic part of the ballot image to 25 characters. This will
>help us decide on a bar code scheme. We don't plan to bar code write-ins
>names at this point.
>We will need a to write a routine to "uncompress" the data. With a table of
>ballot images that look like what I've described above, we should be able to
>punch a "uncompress" button and get the data written out like so:
>Note that write-ins will be inserted in the correct position and the other
>selections are written-out.
>Please sign-off on this design if you think it's okay. Let us know right
>away if you want it different.
>Keep in mind that this is for the demo. The production system will likely
>be a little different -- maybe another character or two for other attributes
>and, of course, the ten characters for the encoded selections could be more
>or less than ten.
>-- Alan Dechert
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Aug 31 23:17:14 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:18 CDT