Locus Plus

Open location finding

Rob Pickering

Rob Pickering

— 4 min read
Locus Plus
Locus Plus Screenshot

Open location finding

There is a proprietary location finding app that seems to be getting a lot of stick at the moment. I’m not going to rehash this as the concerns are amply articulated by much smarter people than me in articles like these:

In the UK, emergency services call centres are using this application, seemingly without any critical analysis, and in situations where lives can be lost if the wrong information is passed.

I believe information standards used for critical systems should be transparent and open so that they can be analysed and constructively criticised, preferably with multiple competing implementations for validation and commercial independence.

May Day public holiday has just been and gone in the UK, the weather was bad and we still have lots of Covid restrictions, so it seemed like a great (and well named) excuse to set myself a challenge of learning about location APIs and encodings. I ended up spending the day trying to figure out if it is possible to build a comparable system using open standards just for fun.

The Problem

The problem that the original app is trying to solve is the ability to pass location coordinates concisely and accurately in an audio conversation.

A much better solution exists to do this automatically on emergency services calls where the caller is using a smartphone which supports Advanced Mobile Location information. This allows the location to be sent accurately and digitally direct to the call centre using SMS without user involvement. In the UK, this is available 75% of calls from mobiles to the emergency services. In the majority of cases where AML is available and it is possible to transmit this information through to the handling organisation, this is preferable as there is no potential for errors to be introduced pronouncing or transcribing the location.

This still leaves a gap for the 25% of calls where AML isn’t provided or for rescue services that cannot receive the information it provides. This is the problem space that voice based location applications operate in.

The key ability is to be able to provide concise, easily pronounced location phrases that eliminate as far as possible the potential for error. These need to be made available in an emergency situation even when the phone has no data connectivity.

Possible solutions

There are a few different major standards for representing location coordinates:

None of these are very optimal for spoken transmission, they are all long strings of letters and digits which have significant probability of a single letter or digit error corrupting the conversation. This can be fixed or improved using the phonetic alphabet and judicious use of readback, but few non-geeky users will be familiar enough with a common phonetic alphabet to use it reliably in a high stress environment.

Abbreviating Plus Codes

One of the fun attributes of Plus Codes is that the main Open Source library, provided by Google, and their implementation in Google Maps support the concept of a relative codes where the alphanumeric part is coupled with a place name which is used in place of the most significant digits, so that:

9C3XGWG8+7G, becomes the much more manageable GWG8+7G, London, England. In fact the number of digits stripped is variable and depends how close the location being expressed is to the reference point, so the above can be further shortened to: G8+7G, Hoxton, England. This is now starting to look fairly concise .

Spelling them out phonetically

Of course a web page or application that is aware of the users location can give that to a user spelt out phonetically and ready to be read to the operator: Golf Eight Plus Seven Golf Victor, Hoxton, England.

In many ways, it is a feature that a local place name is part of the text read out as it should alert both the user and the operator situationally, and give an opportunity to query any gross location discrepancies. It could however be problematic where the user has no good idea where they are and has issues pronouncing this place name. An option to change the placename reference to a different one needs to be part of the application. A user can toggle through alternative ways to express their location until they find one that is easy to express:
Hotel Juliet Plus Four Five Mike, Nunthorpe, England
Golf Romeo Hotel Juliet Plus Four Five Mike, Ormesby, England
Golf Romeo Hotel Juliet Plus Four Five Mike, Middlesbrough, England

All correspond to the same place.

Readback

The final component is readback using a different coordinate system. Sending the coordinate as a phonetically spelled out Plus Code, and then confirming the corresponding OS Grid Reference back as part of the conversation is a powerful way of detecting errors.

The full implementation of all of the above is available in a Github Repo and runs on a public URL at https://locus.plus.

This serves up a React app which installs on a mobile device as a PWA for offline use:

It also has a vestigial embedded operator console, more suited to desktop environments, accessed from the menu:

Futures

Locus Plus was a personal project done over a couple of days for education and fun. I felt it was more positive to demonstrate how easy it is to do the right, open, thing (even if only to myself) rather than criticising other people’s work. The domain name cost a few pounds and all of the work is done client side so the hosting will probably always be free-tier.

I will keep the hosted version alive until the domain name expires in just under 12-months time, maybe renew it for one more year after that. If you are interested in it as a project or derivative, then you can of course contact me, or just contribute or fork it. It is BSD Licenced.

Enjoy.

Read more