Any interest in supporting What 3 Words?

Latitude and longitude is currently supported, however many people are using What3Words for precise location mapping as it can be somewhat more user friendly to use.
Does anybody have any thoughts on maybe adding support for maintaining/supporting What3Words locators for location/venue data?

Views would be interesting. What three words is not entirely open or free - see here.

Maybe a product such as yours could offer it in input pages and then do a conversion to lat/long for sharing.

Given that location is somewhat open ended and includes lat/long, I think you could easily use it for what3words as it. The address could go in description.

I think there is a case to be made for adding a type field to location though, with enumerations (for example) of “physical_address”, “mailing_address”, “virtual”, and “what3words”. I can’t think of others off the top of my head.

@MikeThacker does a link to a particular service require it to be open/free?

@skyleryoung I’d see a what3words field as a data point that is an alternate way to define where the location is on Earth, not a location “type”.

Hello Paul

does a link to a particular service require it to be open/free?

The data describing each service in Open Referral must be open and freely accessed. There may or may not be a charge to use the service.

If you’re referring to the openness of the location identfiier (e.g. what3words or UPRN) then that is open to discussion. UPRN is mandated for UK public sector location data and you can freely get a lat/long from a UPRN (although there are other restrictions). I understand that what3words is not completely open but that you can lookup a location from the words.

Do say here if you think there would be limitations in people using what3words.

The proposal for HSDS version 3 is given in rows 67 and 68 of the “Latest” tab of Por20349 - HSDS - US and UK. So the fields:

  • external_identifier - gives the value e.g. “”
  • external_identifier_type - gives the identifier e.g. “what3words” (for the location of Big Ben)

Of course in the UK we’d prefer something like:

  • external_identifier = “1”
  • external_identifier_type = “UPRN” (for Bristol Town Hall)

@MikeThacker OK I think the use of external_identifier should suffice to cover what3words in an extensible way, although I guess it limits it to one type per entry?

1 Like

Hi Mike,
From a technical perspective what is being proposed will work fine and I’ve got no issues with wht’s being proposed.
However, just a couple of thoughts:

  1. UPRN is of debatable use for end-users. I don’t hear people asking “what’s the UPRN?” when trying to locate a premise, whereas they do, sometimes say, “have you got a W3W location?”. The UPRN is an essential aid in identifying & assigning uniqueness to addresses, but has no profile in the “real” world. So whilst we should always have a UPRN, I think facilities such as W3W offer a more user friendly way of obtaining a precise location and directions. I would acknowledge the situation regarding the “openness” of W3W, but from an end-user perspective its a useful tool & free for most use cases. I think I’m just trying to say that they are slightly different tools & I’m merely suggesting that W3W can offer an enhanced user experience if it can be provided.
  2. I agree with Paul Mackay’s point that one identifier per entry is a little restrictive and it would be disappointing if it was a case of UPRN or W3W rather than UPRN as default & W3W as an option.


Of course UPRN can freely be converted to lat/long so I’d expect an application consuming UPRNs to show them as points on a map.

The need to support more than one external identifier is valid. This, like many other cases, would mean adding an extra table to the tabular data structure for a one-to-many relationship between location and external identifiers. It might be less of an issue if the definitive source of the data structure (HSDS) were JSON schema instead of tabular data structure, but that would be a big step and not necessarily easy to bring adopters along with.

Looks like we may adopt JSON Schema after all. How does that impact this topic?

See this feedback from 360Giving pasted from this thread:

The ability to include third party identifiers for locations significantly increases the user-friendliness of sharing geographic data, as latitude and longitude are not always commonly used to describe service delivery locations.

However, we would recommend against highlighting what3words as an example of an external identifier scheme, as it is fraught with issues, and this may increase its perceived legitimacy.

It is not clear whether there are any limitations on the types of third party schemes that can be used for sharing location data. 360Giving has had some experience with this, and found that as a result of our geocode types list not being validated, it has suffered from poor data quality and a proliferation of codes which is now unwieldy, while the official codelist has become out of date. We would recommend defining a closed list of schemes and maintaining that list to reflect changing needs, rather than being permissive of any scheme being used, which makes the data harder to map and compare.

We would strongly recommend supporting the use of externally referenced geocodes for all entities that relate to location, for example service area. This would make the data more comparable to other datasets, including being able to compare the provision of services to the area of impact of grants, or to government administration and reference data. Consider introducing a concept of location scope or similar for indicating a reach of a wider area than a single place.