Include lat/long for polling locations

[jungshadow]

The second comment from the states:

I would suggest the ability to submit “XY” latitude/longitude coordinates for polling locations for those who collect that information (NB: we use decimal degrees to seven significant figures). We find that using polling location coordinates is more reliable and more accurate than traditional address interpolation.

This did exist in the never-launched 4.0 specification. It may be worth adding this to ContactInformation as well rather than just polling location in case it could be useful for other elements (e.g. ElectionAdministration). To that point, does it make sense to extract the address "guts" of ContactInformation and reuse in PollingLocation (NB: I have a feeling we've probably had a lengthy conversation about this...but I don't remember)?

[pstenbjorn]

@jungshadow this is something we had discussed a while back but was excluded from the 5.0 spec for reasons I do not recall. Given some of our addressing challenges it would be helpful to have a geolocation option for polling location addresses.

[jdmgoogle]

#include "std_disclaimer.h"

@pstenbjorn The reason we ended up not going with them in 5.0, I believe, is that the lat/lngs we got from the states and from third parties were usually wrong, and often by a large amount. For example, when we cross-checked the lat/lng coordinates provided by another large service for 1,000 addresses:

• Only 10% of addresses were within 10 meters of the provided lat/lng;
• 50% of addresses were >100m off;
• ~15% were >1km off;
• ~4% were >10km off; and
• One address was 113km off

I mean, we can figure out how to add it, but I don't think I'd actually trust any data in those fields. :)

[jungshadow]

@jdmgoogle Side note on this, I don't think we included the lat/long values in the previous feeds–mostly because we didn't have a place for them. Did they actually come from the states?

[jktomer]

@jdmgoogle I think you might be remembering a different data source. I don't recall ever seeing polling place geocodes in a VIP feed.

Regardless, Google is unlikely to use lat/longs supplied by anyone other than ourselves (we geocode all polling location addresses for our product anyway), but I don't oppose adding them to the spec if other people feel they might be useful.

[jdmgoogle]

@jktomer It was definitely something involving street segments. It may have been from a non-official source, though.

I'll echo the "I'm okay having them in the spec for non-Google people to use (but we're only using values from our own geocoder)" sentiment.

[jungshadow]

Thanks for the feedback on this.

@jdmgoogle @jktomer @pstenbjorn @cjerdonek One remaining question here: Should ContactInformation be further abstracted for general use on any element with an address? It seems weird to add a lat/long to ContactInformation to cover election admin offices and additionally add it to PollingLocation.

[cjerdonek]

You mean a "SimpleAddress" type with two elements "AddressLine" and "LatLong"? I'm okay with that. At least for me, the reason I didn't suggest doing that earlier is that at the time such a type would have only had "AddressLine".

[jdmgoogle]

Here are the various options I see:

1. Create a LatLng object and add it as an optional field in PollingLocation;
2. Same as (1), but also add it as an optional field in ContactInformation;
3. Create a SimpleAddress type with [1,unbounded] AddressLine elements and use it PollingLocation; or
4. Same as (3) but also use it in ContactInformation.

Changing ContactInformation means we either have to diverge from the 1622.2 definition of ContactInformation or request that 1622.2 update their version of ContactInformation. The current reason for not using ContactInformation in the PollingLocation element is because the latter requires at least one address line, whereas the former does not.

My vote is to ping 1622.2 to see if they're open to adding a LatLng object to ContactInformation, and if so we would make the same change and add LatLng to PollingLocation as well (choice (2) above). If not, I recommend we go with (1).

Thoughts?

[jdmgoogle]

After some further investigation of 1622.2, it looks like there's not a feasible way to add lat/lng to ContactInformation; the existing SpatialDimension element in 1622.2 fits their use case well, and is overkill for adding to ContactInformation.

Given that, I'm officially going to recommend we add a LatLng element to PollingLocation.

Yea/nay?

[jungshadow]

Yea.

[pstenbjorn]

Yea

[jungshadow]

Assigning to @jdmgoogle, but feel free to reassign to me if you don't want it.

[jdmgoogle]

Whoops. Spelling error in the spec.