David -
Most of the voter registration products seem to use street
segment files to define their areas. Each range of numbers (e.g.,
100-199) on a given street, and even or odd can be separated as well, is a
segment. These segments are then placed into a set that defines a given
precinct. That is the simple case and applies to a large percentage but
not 100% of the time. You can find places where specific floors of a
building are grouped, etc.
These products don't use geospatial information, so the
likelihood that the jurisdictions will be able to provide that is not
good.
- Peter
From: David RR Webber (XML)
[mailto:]
Sent: Wednesday, July 30, 2008 9:21
AM
To: John Borras
Cc: EML TC
Subject: RE:
[election-services] Fw: VIP/EML CONVERGENCE?
John,
I think the one approach solves both. Frankly - the old approach was
needed because they did NOT have the means to solve it easily - so it became a
crazy morass of rules and amendments and notes and changes.
It's the same problem in essence - where is my qualifying address relative
to the polling station and the geographic boundaries that define it?
I'm not trying to compete with Google - instead - I'm looking to use EML to
empower their solutions (and all the other makers of mapping solutions).
They all need the raw geographic information in a simple and consistent way
that is easy for the voting authorities to provide that's compatible with the
existing mapping engines and standards.
So whether you provide street address boundaries and intersections - and /
or geographic coordinates - the idea is the same - to spell out what the
physical area looks like.
By using geospatial and consistent street addressing together (that's
what its designed for!) - we can capture what that is in a coherent way - and
the mapping software can read that XML in and visually show you it - so you
know if you have it correct.
The last piece is then easy for the voter - provide their own street
address - software shows them where that is - what precinct its inside (draws
those lines as overlay on the map using existing mapping API) - and directions
to the polling location address!
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] Fw: VIP/EML
CONVERGENCE?
From: John Borras <>
Date:
Wed, July 30, 2008 5:01 am
To: "David RR Webber (XML)"
<>
Cc: EML TC
<>
David
As I see it there are two distinct voter questions that VIP is
trying to handle. First, which is my polling station, and second how do
I get there.
The second one is clearly a Google maps type of scenario and we shouldn't
try and compete with that, just provide hooks to jump out to those type of
applications.
The first question is very different and is not in my opinion a
Google maps type of solution. The "which is" bit depends on a number of
factors and will/can be different for different elections. This is
where the business rules come into play. So determining the voter's
polling station depends on which precinct/ward they are in for a given
election and this is/can be affected by population headcounts, local
authority boundaries, electoral jurisdictions etc. I don't see
mapping software handling all that complexity. All we need to be able to
do is handle a simple relationship table that links addresses to precincts to
poling stations for a given election. Let the States admin folks use the
business rules to work out the boundaries etc and enter them into their EMS
system, from which VIP can then take an extract.
The EDXL solution seems to be fine to answer the question of
where is the nearest polling station to me but that may not be the one I
should use.
So as I said yesterday let's not get sucked too deeply into geospatials
etc.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: John Borras <>
Cc: EML
TC <>
Sent: Tuesday, 29 July,
2008 8:23:10 PM
Subject: RE: [election-services] Fw: VIP/EML
CONVERGENCE?
John,
Yes - I agree a new EML 115 can capture the geographic details
of the area associated with the 110 polling place.
I'm seeing there is potentially an "easy" solution - use almost the
exact same method as OASIS EDXL is already. We can "borrow" their schema
imports of the CIQ and Geospatial XSDs. They already have this. It
would be a nice primer for us to move to CIQ v3 next in EML V6.
Think we need to collect together the conceptual model first on how this
all would work (Paul - novel concept - do the information model first!) -
using street / GPS / map references to markout the physical boundaries - store
that in XML - but I'm seeing the means to do this is probably already in the
EDXL stuff.
Then ensure we have the right pieces from the VIP side too - and the
linkage to the 110.
Googles mapping engine should be able to place people's physical
address inside the boundary then - drawing it on the map and pinpointing
their house.
This is going to be a very cool application. Think the states will
have huge incentive to provide those EML 115 and EML 110's to drive this with
- and it will make their lives much easier - instead of having to figure
out all kinds of ugly addressing based rules - let the mapping software do the
work...
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] Fw: VIP/EML
CONVERGENCE?
From: John Borras <>
Date:
Tue, July 29, 2008 4:17 am
To: "David RR Webber (XML)"
<>
Cc: EML TC
<>
David
I'm not convinced we should handle geography specifically within
v6. I think it's out of scope for us. We can leave hooks for
users to insert their own preferred mapping tools, eg Google maps, but
let's not get sucked too deeply into this aspect.
I agree we have within 110 most of what is needed for VIP but the
one bit we don't have is the link between a voter's home address to
their precinct and thus polling station. The business rules that
determine this are usually within the election authorities' systems and
all we've done is handle the output from that which tells the voter on their
polling notification where to go to cast their vote. What VIP want to
do is handle the business rules as well so the third parties can
provide the searching facility direct to the voter. So that's
where I think we need the new message, perhaps a 115.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: John Borras <>
Cc:
EML TC <>
Sent: Monday, 28
July, 2008 2:31:30 PM
Subject: RE: [election-services] Fw: VIP/EML
CONVERGENCE?
John,
Good thoughts. I'm seeing for EML v6 we need to handle
geography! Mashups and Web 2.0 are upon us...
KML is Googles markup for maps, GPS and more. Most GPS devices
support KML.
You can do very cool things with it - such as this -
http://www.drrw.net/inside/travel/cycling-mashup.html
which obviously could be used to provide recommended route to and from
a polling station from nearby highway - etc.
Back to polling stations. Actually if we look at the EML-110
election event - we have a chunk of this already.
Should give us a good model to follow to add in the additional
parts. I actually think this is closer than we realize. Not sure
how much new stuff we need - may only be one new transaction that provides
voter polling place linkages.
I worked on alot of things this weekend (including the EML 110!) - but
still have some more testing and crosschecking to do before everything is
ready to share the full analysis with the group.
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] Fw: VIP/EML
CONVERGENCE?
From: John Borras <>
Date:
Mon, July 28, 2008 5:43 am
To: EML TC
<>
Thanks for all the very useful contributions. Looks like we
will need to have a very flexible new suite of messages to
accommodate the address - precinct- polling station, including opening
days/hours, set of relationships, and their linkages to
contests. Not sure I've seen this complexity in the VIP stuff
so far but maybe as they roll it out they will come across the need for
it.
David - two questions on your note below.
First what's KML? And secondly the VIP requirement is primarily
about which polling station do I have to use not how do I get
there. So EDXL HAVE might not be appropriate if it's focus is just
on giving directions?
So where does all this leave us and how do we take it
forward? Well in my opinion we need to review David's address
handling facility first to see if that meets the VIP needs. Secondly
we then need to build the new messages to handle the geography elements
for polling station allocations. And finally develop any further EML
schema localisations needed for the remainder of the VIP
requirement. Having got that set together we can then ask them to
validate it before working out a cross-over strategy with them.
Agreement or alternative views would be appreciated plus views on
whether we need to have a TC telecon to discuss this further.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: Richard J Cardone <>
Cc: EML
TC <>
Sent: Friday, 25
July, 2008 9:20:28 PM
Subject: RE: [election-services] Fw: VIP/EML
CONVERGENCE?
Richard,
OK - thanks for reminding me one of the core values here for VIP -
pointing people at the right polling place!
So -thinking about this - its not a pollbook type of function - its a
public information one.
What EML is setup to carry is the ballots, candidates
and polling place information.
So this is an additional function associated with polling place -
which relates to address boundaries.
And then now we're seeing another - which is early balloting and
those mechanisms. I'd add to that absentee ballots.
So there's potentially two new types of EML supplemental
transactions. For the address boundaries I'd add geospatial and
support for KML. Fortunately this has already been done for us using
CIQ!!!
The new OASIS EDXL HAVE schema is doing exactly this for hospitals
and emergency management. In that case its "how do I get to the
right hospital?". Substitute polling station for hospital and we can
borrow all that part of their XML!
Then for the "means to vote" - I don;t think we have anything
specific right now. However in both instances - we can re-use the
eml-common lexicon of xml parts - to assemble these pieces from is my
sense - and hence tie them neatly into the "EML family".
Thanks,
DW
-------------------------------------------------------------------------------------------------------
Rich -
I would agree that there are locales where that
happens -- the polling locations have set hours/days but an individual
would still be in a precinct (the precinct determines what contests are
contained on the individual's ballot).
In Texas there are places where early voting is done
at regional locations and anyone can go to any location. They are
still assigned to a precinct, it is just that all precincts can go to all
early voting locations. On election day the polling locations become
localized and individuals are routed to their local polling place that
handles one precinct (or a small number of precincts).
Polling locations actually change frequently (a
church or social hall is under repair and they move to a different
facility for the current election). Precincts usually change only
when redistricting or such takes place.
- Peter
-------- Original Message --------
Subject: RE:
[election-services] Fw: VIP/EML CONVERGENCE?
From: Richard J Cardone
<>
Date:
Fri, July 25, 2008 2:30 pm
To: "EML TC"
<>
Peter and John,
There is the case where polling places can change
over time in an election. For example, voters may be directed to
centralized polling places during early voting. At some point, early
voting ends and election day--the final day of voting--arrives. On
election day, voters may be directed to their neighborhood polling places,
which are different than the centralized polling places.
Rich
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Not happy with your email address?
Get the one you really want -
millions of new email addresses available now at Yahoo!
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Not happy with your email address?
Get the one you really want -
millions of new email addresses available now at Yahoo!
Not happy with your email address?
Get the one you really want -
millions of new email addresses available now at Yahoo!
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
