Reference locations

[Doug Ewell]

I have a question about developing an OLC implementation. The coding scheme and conversion to and from lat/long is easy, but I'm hung up on this requirement:

> 19. Open Location Code implementations must provide the following methods:
> [...]
> ◦ a method to remove four or six digits from the front of an Open Location Code given a reference location
> ◦ a method to recover a full Open Location Code from a short code and a reference location.

To do this, you have to know the OLC (or lat/long) of the reference location, which would have to be stored in some sort of resource.

As a guideline, how many locations (or of what minimum size) would it be necessary to ship around with an application? Remember that not every application can store this on a web server. OLC was specifically not intended to require network connectivity.

Geonames distributes lists of cities with population over 15,000 (there are 24,000 of these), over 5,000 (48,000), and over 1,000 (127,000), plus a list of all "populated places" (4.6 million). How many is enough to conform to the requirement?

Note that an abbreviated OLC could be given with different reference locations, such as the name of the actual city or town containing the location, one of more adjacent towns where someone thinks the location is, a nearby major city, etc. Examples in the heart of huge cities such as São Paolo and Cairo don't address this problem.

[Rasťo Šrámek]

Hi Doug,

this is indeed one of the long term issues that is bugging us. I am writing a white paper detailing how we do this within google and we have often wondered whether we can create a set of locations that could be packaged with an app..

Right now, we take the geometries of localities, and if the point is within one, we check whether it is not 0.7 degrees or more in both N/S and E/W directions and use it if it isn't. (The only city which fails this that I know of is Jeddah)

If it isn't within a locality, we look for localities that are close and rank them by distance/log(area), omitting additive factors. The locality may not be further than 0.15 degrees away, so that 2*0.15+0.7 < 1.0 and one locality cannot be a

reference to two same 4+2 plus codes.

Further, we make sure the reference locality is within the same country, same state, and same disputed area (if applicable) as the plus code point.

Achieving the above without passing at least some geometries to the in-app database is tricky, but without it you end up in a situation where generated plus codes refer to a locality in a different country which may be completely harmless, or cause issues with post, etc.

Cheers,

Rasto

--
Public site: http://www.openlocationcode.com/
Github project: https://github.com/google/open-location-code
Demo site: http://plus.codes/
---
You received this message because you are subscribed to the Google Groups "Plus Codes Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-location-code+unsub...@googlegroups.com.
To post to this group, send email to open-location-code@googlegroups.com.
Visit this group at https://groups.google.com/group/open-location-code.
To view this discussion on the web, visit https://groups.google.com/d/msgid/open-location-code/edd18f1a-76e4-4a6d-a4cd-4ae5783ce1e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas B]

Hi Doug,

I think you are misinterpreting the requirement here. If you have a look at existing implementations (for example JAVA: https://github.com/google/open-location-code/blob/master/java/com/google/openlocationcode/OpenLocationCode.java), you will see that the shorten() and recover() methods take lat/long as arguments for the reference location.

You don't have to ship any name:coordinates lookup tables with your OLC implementation, but can rely on the application using your implementation doing the lookup itself and providing your code with lat/long coordinates.