[Date Prev][Date Next]
RE: DIMS Integration or Other VR Systems
Post it as an RCR; never any harm in that. If you could attach a smallish import
file that demonstrates the problem, that would help. Also, you mention that there
are thousands of errors. Indicate a couple of them. This might be related to
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of
Sent: Wednesday, January 29, 2003 7:49 AM
Subject: DIMS Integration or Other VR Systems
Let me know if this is an RCR, or we have a design limit, or just need to
work more closely with VR vendors and they need to change.
In California, we have certain districts that have both "at large" members,
and "district specific" members. That is, two board members of a water
district may be voted on by ALL voters in the district, while 5 Board
members may be voted in from 5 specific subdistricts of the water district,
for a total of 7 district board members.
The Voter Registration Systems handle this in a parent-child district
relationship. The "At Large" or parent district can have a candidate
running, and several of the sub-district (child) races may also be running.
On the import from the Voter Registration system (both DIMS and DFM), the
GEMS import chokes and gives errors for every precinct where this is
encountered - sometimes hundreds or thousands of errors. Is there a "flag"
that can be developed for this type of a district, part of our import, that
would allow this sort of thing, or are we restricted with our design. I
understand the benefits of the way we do it from the standpoint of catching
problems. But if there were a flag in the import that the specific district
type was an "at large" district and allowed both district wide races and
sub-district races to run in an election, we would still maintain GEMS'
integrity. Conversely, we could force the VR systems to recode each
precinct and seperate these districts into two types of districts, but they
in fact are the same district.