JSON examples posted

[John Dziurlaj]

Good Morning,

 

I want to report that we have updated the BallotDefinition GitHub with example files using the latest version of the CDF schemas. Additionally, we now have examples in both XML and JSON.

 

Several substantive changes to the model have occurred:

• The class Geometry is now called Shape. This new name reflects the narrower usage of the class (i.e. for associating a shape appearing on parts of the ballot with its meaning)
• The classes ending in *Selection have been renamed *Option. This is a to better distinguish an option for selection and a voted selection.
• Documentation has been updated for completeness and clarity.

 

An updated version of the Ballot Definition specification will be posted in the coming weeks.

 

Regards,

 

John Dziurłaj /d͡ʑurwaj/

Sr. Solutions Architect, The Turnout

[Ray Lutz]

John:

The indexing of ballot styles is a little more difficult than your example implies, because the coordinate system must be based on finding some indexing markers on the image rather than depending on the existing coordinate system from the original PDF. Thus, make sure that in the ballot style std, you provide the locations of alignment marks of some kind, so that it will be possible to align and crop a scanned image, so that the coordinates will be about the same. For Hart, for example, the common way to do that is to use the code-128 barcodes that surround the body of the ballot for alignment purposes. Once the ballot is mostly standardized, then for Hart, the rectangles can be used to fine-tune the location rather than the timing marks that are used in the case of ES&S and Dominion, for example. Also, please allow for pixels as the unit. I provided some examples in my comments to your document, including providing the corners of the ballot, for example for dominion, when they have those alignment blocks that can help to define the corners, but at least the corners should be provided in the ballot style so that it can be indexed to the coordinate system that results from scanned ballots.

--Ray Lutz

--
To unsubscribe from this group, send email to cdf-ballot-sty...@list.nist.gov
 
View this group at https://list.nist.gov/cdf-ballot-styles
---
To unsubscribe from this group and stop receiving emails from it, send an email to cdf-ballot-sty...@list.nist.gov.

-- 
-------
Ray Lutz
Citizens' Oversight Projects (COPs)
http://www.citizensoversight.org
619-820-5321

[Carl Hage]

On 9/13/22 5:43 AM, 'John Dziurlaj' via cdf-ballot-styles wrote:
> I want to report that we have updated the BallotDefinition GitHub with
> example

> <https://github.com/usnistgov/BallotDefinition/tree/examples/examples>

> files using the latest version of the CDF schemas. Additionally, we now
> have examples in both XML and JSON.

Thanks for adding these! It will help in the discussions. I realize they
are excerpts, so not indended to be the complete match to the PDF, but
adding the PDF is helpful.

Some comments on what I noticed in physical_ballot_def_1.json

The BallotFormat[0].ExternalIdentifier[].Type is "stable", not a valid
enumeration. Do you mean "local-level"? Fine to use "stable" if it's in
the enumeration with a definition.

The OptionPosition used to have Indicator (in the 8/31 review) but now
that is removed. OptionPosition is now correctly identified as a
BoundedObject, but the association with a shape is now lost. The Class
Geometry says it is for associating with OptionPosition. But the shape
IDs are not reference Do you mean to add GeometryId: "g-1" to
OptionPosition?

Seems like Shape should be required with 1 instance to define the shape
of the bounded object.

The Contest[0].Name seems a little weird, probably should be "President
and Vice President of the United States". (Also nice to make an example
that does not derive from an IBM 026 keypunch.) If this name is supposed
to be a shorter heading, then "US President/Vice-President". Since it's
a 2 ticket office (thanks for that example), implying that in the
heading is good.

The Election.ElectionScopeID seems wrong. The physical_ballot_def_1.pdf
shows "Williams County", so I would say an appropriate example is
"gpu-williams-county".

How about capitalizing names properly in examples, instead of using 026
keypunch text, e.g. "STATE OF OHIO"? Don't suggest an EMS should be
implemented with SHOUTING improper capitalization.

Since you have a PDF, it would be useful to add the
BallotStyle[0].ImageUri[0].Content:"physical_ballot_def_1.pdf". A URI as
a file name is assumed to be in the same directory as the json. A github
URL would be another option. I am assuming the coordinates match within
the PDF, and sheets are in pages front to back.

There are no fiducials to align a scan defined. In the PDF, there are
rectangles around the three columns with a border that could be used as
a fiducial. A shape for the Extent on a PhysicalContest could include a
stroke width to match the rectangle around the contest. There is a
separator that is thicker between contests, but could be represented by
an overlapping fiducial that is a filled rectangle.

There is no defined way in the spec to identify the ballot style on a
scan. One way to do this is create an extent on the sheet that is a
consistent location to identify the extent of the reporting unit. The
area in the upper right of the ballot with "Precinct 001-BRA" is
presumably the same, though the phrase is right aligned so "Precinct
111-III" might have "Precinct" in a shifted location. The scanner can
use pixel extracts from the PDF to match the reporting unit, and in-turn
the ballot style associated with that unit.

It is helpful to be able to put an extent on the PhysicalContestOption,
similar to PhysicalContest.Extent[] so the whole option area including
the candidate name is identified.

Some comments on physical_ballot_def_2.json:

It's not clear (without measurements) where the FiducialMark applies.
It's too much work to put all of them in the example, but maybe the 4
corners? I think in the physical_ballot_def_2.pdf the narrow vs wide
fiducials code the precinct and in-turn ballot style. The reporting unit
identification extent could group the fiducials for a match. (I wonder
what the numbers are next to the fat fiducials.)

Same comment as above, we need a GeometryId (or better ShapeID) in the
OptionPosition to identify the oval shape and stroke width. On my
ballots, the oval is in red ink, presumably so scanners can use red
light (detect green/blue ink).

Comments in physical_ballot_def_3.json:

The Candidate.BallotName is full of inappropriate formatting characters,
\n and \t. It should be "Edward FitzGerald and Sharen Swartz Neuhardt"
not "Edward FitzGerald and Sharen\n\t\t\t\t\t\t\t\t\tSwartz Neuhardt".
This is an illustration of an error/bug, and could indicate the JSON be
flagged as invalid. This reminds me of times past when MS-Word users
used spaces to wrap and align words instead of using paragraphs.

> Several substantive changes to the model have occurred:
>

> * The class Geometry is now called Shape. This new name reflects the

> narrower usage of the class (i.e. for associating a shape appearing
> on parts of the ballot with its meaning)

Seems that you only partly change the name of the class, as "Geometry"
is still a top-level object, presumably so it can be referenced by ID.

> * The classes ending in *Selection have been renamed *Option. This is
> a to better distinguish an /option for selection/ and a /voted
> selection/.

Sounds good to me.

> * Documentation has been updated for completeness and clarity.
>

[John Dziurlaj]

Hi Ray,

 

My understanding is that so long as a fiducial mark can be found on the ballot, by using its offset, you can find the origin of the coordinate system. If the origin is the top left side of the printed page for example, and a fiducial is at a known position of say (2,3), then you can work backwards to find the origin.

 

In regard to pixels, such units are specific to the resolution in which a ballot is scanned, which would make them hard to use unless everyone agreed on a particular resolution.

 

Regards,

 

John Dziurlaj

[Ray Lutz]

Hi John:

On 9/14/2022 11:56 AM, John Dziurlaj wrote:

Hi Ray,

 

My understanding is that so long as a fiducial mark can be found on the ballot, by using its offset, you can find the origin of the coordinate system. If the origin is the top left side of the printed page for example, and a fiducial is at a known position of say (2,3), then you can work backwards to find the origin.

Best to have the fiducial marks at the corners so the total extent can be determined, and thus, sure, the units of measure are not too important.
Just saying that it is pretty common still to use some resolution and pixel locations, esp. if they are to be printed on say a laser printer, because they have
limited addressability, which is a little different from resolution because you may be able to address a location but the spot you can print there may be
a lot bigger. That can result in integer values for positions. Agreement is not required if the resolution is passed with the other data.