Support Open Location Codes for PollingLocation object

[afsmythe]

The Voting Information Project has long term plans to support open location codes for the geocoding of polling locations. If we were to include such an attribute of the PollingLocation object in the VIP spec, what types of information would we need to collect from data providers to ensure dependability and accuracy of the code provided?

[afsmythe]

Punting this to 6.0 for now.

[Jared-Prime]

+1 this would be an excellent feature.

on the side, I wonder if an OLC support could also support Apple Maps in addition to Google Maps?

[jswiesner]

Would an open location code be provided in addition or in lieu of an address? If provided in addition to an address, would this be used in a similar manner to the existing LatLng field?

[jswiesner]

Would an open location code be provided in addition or in lieu of an address? If provided in addition to an address, would this be used in a similar manner to the existing LatLng field?

@afsmythe

[afsmythe]

The most obvious use case for an OLC would be to assist with geocoding problem sites, e.g. if we have trouble getting an accurate geocode for a standard address (either because it is very rural, on native lands or even within a dense urban area) then we could add an OLC to the existing PollingLocation record to hopefully improve the geocode.

[JDziurlaj]

Would this be in place of an address. Or in addition to it?

[afsmythe]

I imagine OLC would be supplied in much the same way that LatLng are provided now, which is in addition to the address field. The core value add of both OLC and LatLng is that a data provider could use either on their own to identify a location. But that isn't how the specification works in practice now, e.g. an address record is required and LatLng is provided to supplement that address data.

Would be nice to hear the data consumer POV. Is it conceivable that a location could be geocoded using only an OLC?

[jswiesner]

Is it conceivable that a location could be geocoded using only an OLC?

Yes, but we have always aimed to provide both a human readable address plus a precise location (i.e. lat/lng). With reverse geocoding, OLC can get us to a reliable, close-enough point on a map, but it doesn't provide us with a traditional address.

Looking at https://maps.google.com/pluscodes/, OLC is essentially nothing more than a short encoding of a lat/lng point. IOW, OLC and lat/lng can be converted back and forth. The primary utility that OLC provides is that you can effectively represent a lat/lng in form that you could use to easily remember, write down, receive mail at, etc. For example, it's much easier to write VXX7+39 Washington, DC as opposed to 38.8977,-77.0366 Washington, DC. Therefore as long as address is still required, and OLC could just as easily be converted to a lat/lng point, I don't see any value to add OLC to the polling location element and keep address as required.

That said, the way I could foresee OLC being useful is for cases when a traditional address does not exist for a given location. Instead, a polling location address could be express as a short form of an OLC, plus locality and state. If an OLC is provided in this way in lieu of a traditional address, the end user would only ever see address = VXX7+39 Washington, DC, and not 1600 Pennsylvania Ave NW, Washington, DC 20500. If we decided we wanted to allow this alternative address format all the way through to the end user, I actually think we could make it work within the current address elements. For example:

<SimpleAddressType>
  <Line1>VXX7+39</Line1>
  <City>Washington</City>
  <State>DC</State>
</SimpleAddressType>

or even:

<AddressLine>VXX7+39 Washington, DC</AddressLine>

[JDziurlaj]

I think we need to work from examples in the wild. My understanding is that OLC are mainly for informal locations, such as John's House, Informal Settlement, Somewhere, USA. My address (Line1) is John's House (that's what people in my community call it), but the location would be represented by the OLC.

[jswiesner]

I think we need to work from examples in the wild. My understanding is that OLC are mainly for informal locations, such as John's House, Informal Settlement, Somewhere, USA. My address (Line1) is John's House (that's what people in my community call it), but the location would be represented by the OLC.

+1 to pulling together some practical examples. @afsmythe, are you able to provide some examples?

For the example you gave, I don't see any benefit of using OLC. That might as well just be modeled as an address + lat/lng since the address portion is what the end user would see, and an OLC or lat/lng would be doing the same thing in placing a pin on a map for the location.

[afsmythe]

OLC is essentially nothing more than a short encoding of a lat/lng point.

I wasn't aware of this. This is a good point.

Therefore as long as address is still required, and OLC could just as easily be converted to a lat/lng point, I don't see any value to add OLC to the polling location element and keep address as required.

Also a good point.

The instigation of this was hearing how some particularly rural locations (and those on indigenous lands) were being identified "in the wild". We have heard from state/county partners and other civic non-profits in the space that OLC are being used to identify locations which do not have a "traditional" address (or are not served by USPS). In these cases, I could see VIP guiding partner states to first convert a OLC to LatLng and provide those in the feed. I also think there would be some merit in repurposing the existing SimpleAddressType to support OLC as mentioned in #390 (comment)

If OLC could be used within the SimpleAddressType elements then I think we can close this issue.

[jdmgoogle]

Strong +1 to finding ways to better support ambiguous addresses and locations without traditional address structures. Also +1 to the request to have specific address/location examples which are not easy or possible to represent via the current address types and would benefit from OLCs/plus codes.

[afsmythe]

Moving this to "Up for debate". We'll guide data providers to use LatLng if they wish, and plus codes can be provided in PollingLocation.AddressStructured.Line1 so long as City and State are also provided.

[jswiesner]

Moving this to "Up for debate". We'll guide data providers to use LatLng if they wish, and plus codes can be provided in PollingLocation.AddressStructured.Line1 so long as City and State are also provided.

This sounds good to me. I suggest we circle back to this once we have a data provider interested in using Open Location Codes. Putting the Open Location Code in the first address line (along with city + state) is a reasonable solution that we can try out once we have data.

[afsmythe]

I believe Plus codes were used for some instances in 2020 and 2021. @robertmdw can you add some feedback here about those successes and/or areas for improvement?

[robertandremitchell]

Yes, some of our state and county partners in CA and CO opted to use Plus Codes in order for drop-off location pins to more accurately be placed. We were able to use Plus Codes to get non-mapping addresses to map, which was helpful.

However, one issue we ran into in feedback from CO was that the new address for that site was confusing in its display to voters, as they were not familiar with plus codes in that Line1 position. One workaround could be putting the Plus Code in the latitude/longitude so that states and counties could provide descriptive Line1 ("between 1st Avenue and Main Street")? Alternatively, altering the display in instances of Plus Codes may be needed, but would require all API users to implement.

In addition, if they tried to put that Plus Code address into Apple Maps or another mapping service, it was not able to be mapped. We would still need to do some digging into this particular issue to confirm, but that would definitely be a limitation for mobile users in particular, who may try to plug the address into a mapping service of their choice.

There was one odd cases in Napa County as well (https://partnerissuetracker.corp.google.com/issues/197141619) where a zip code had to be omitted for the Plus Code to geocode. So we would also want to develop more fully formed guidance to states about what info may be needed or not needed as part of the Plus Code usage.

[jswiesner]

However, one issue we ran into in feedback from CO was that the new address for that site was confusing in its display to voters, as they were not familiar with plus codes in that Line1 position. One workaround could be putting the Plus Code in the latitude/longitude so that states and counties could provide descriptive Line1 ("between 1st Avenue and Main Street")? Alternatively, altering the display in instances of Plus Codes may be needed, but would require all API users to implement.

The detail of "between 1st Avenue and Main Street" seems better suited for a field like PollingLocation.Directions than it does PollingLocation.AddressStructured.Line1. If the line1 contains a plus code, one possibility is to display PollingLocation.Name or PollingLocation.Directions more prominently to the user above line1.

In addition, if they tried to put that Plus Code address into Apple Maps or another mapping service, it was not able to be mapped. We would still need to do some digging into this particular issue to confirm, but that would definitely be a limitation for mobile users in particular, who may try to plug the address into a mapping service of their choice.

It's always possible to convert back and forth between lat/lng and Plus Code. This again is an issue that I think can be mitigated on the client side. If a Plus Code is detected, you can link the user to an external map application that uses plus code converted to a lat/lng.

There was one odd cases in Napa County as well (https://partnerissuetracker.corp.google.com/issues/197141619) where a zip code had to be omitted for the Plus Code to geocode. So we would also want to develop more fully formed guidance to states about what info may be needed or not needed as part of the Plus Code usage.

I believe this was a very exceptional edge case, but we'll need to try this approach out more in practice to see how often these types of issues occur. If this type of issue was found to be a systemic problem, I think there are ways to address it in infrastructure that don't necessarily need any change to the spec or from the data provider.