Code lookup

[wilson.da...@gmail.com]

Hi,

I'm particularly interested in this benefit of your new codes format 

"Codes that are similar are located closer together than codes that are different"

I have a database of existing locations for which i have lats and longs. what would be the best way to search for results in my data

based on sub-codes ?

[Doug Rinckes]

This isn't something that I've done yet, but I'll describe the broad approach that I've been thinking about.

Let's say you have a database of codes, and a point, and you want everything from your database that is "close" to that point.

Basically, you're going to compute a list of OLC prefixes, and then select all the entries in your database that start with the prefix.

You can do it crudely - just pick a couple of areas that look promising (for example this area and this area, 8FVC9GCV+ and 8FVC9G9V+) and then take all codes that start with either of those codes. For example, if I want everything within about 100km of Zurich, and I'm not too fussy, I can just use 8FVC as a prefix and get all my entries that start with that.

If you care about the accuracy, you could draw a shape around the point of interest, and then compute a list of all the OLC codes that fit within the shape. Once you have the list of codes, you match the entries in your database in the same way.

This is possible because the code 8FVC9GCV+2J falls within 8FVC9GCV+, which falls within 8FVC9G, which falls within 8FVC, which falls within 8F.

This is appealing to me, because it means that instead of a complicated calculation for every entry in the db, I have to do some moderately complicated computations up front, and then it's just a string matching routine for the db selection.

If someone wants to do a library to compute coverings, it's probably worth looking at the S2 library (also on github) for a similar kind of thing. 

Doug Rinckes

Technical Program Manager

Google Switzerland

--
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 "open-location-code" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-location-c...@googlegroups.com.
To post to this group, send email to open-loca...@googlegroups.com.
Visit this group at http://groups.google.com/group/open-location-code.
To view this discussion on the web, visit https://groups.google.com/d/msgid/open-location-code/3881b1e3-db5e-48a9-a4da-c98df507ae36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sidd...@gmail.com]

Hi,

I think I am looking at a similar scenario and so, reviving this older thread. Excuse me if unrelated.

I have a bunch of plus codes (places within a city). I want to be able to find a subset of plus codes that fall within a radius of 'x' kms from another given plus code (current location of a user). Eg. get all bus stations within 5 kms of the current location of the user, where the plus codes of the bus stations are stored by my application.

Conceptually I think I should be able to determine similarity between plus codes and perhaps compute distances from this subset to the current user location.

Wanted the group's suggestion on how I may be able to accomplish this? 

Cheers,

Sidd

On Monday, 11 May 2015 18:17:35 UTC+5:30, Doug Rinckes wrote:

This isn't something that I've done yet, but I'll describe the broad approach that I've been thinking about.

Let's say you have a database of codes, and a point, and you want everything from your database that is "close" to that point.

Basically, you're going to compute a list of OLC prefixes, and then select all the entries in your database that start with the prefix.

You can do it crudely - just pick a couple of areas that look promising (for example this area and this area, 8FVC9GCV+ and 8FVC9G9V+) and then take all codes that start with either of those codes. For example, if I want everything within about 100km of Zurich, and I'm not too fussy, I can just use 8FVC as a prefix and get all my entries that start with that.

If you care about the accuracy, you could draw a shape around the point of interest, and then compute a list of all the OLC codes that fit within the shape. Once you have the list of codes, you match the entries in your database in the same way.

This is possible because the code 8FVC9GCV+2J falls within 8FVC9GCV+, which falls within 8FVC9G, which falls within 8FVC, which falls within 8F.

This is appealing to me, because it means that instead of a complicated calculation for every entry in the db, I have to do some moderately complicated computations up front, and then it's just a string matching routine for the db selection.

If someone wants to do a library to compute coverings, it's probably worth looking at the S2 library (also on github) for a similar kind of thing. 

Doug Rinckes

Technical Program Manager

Google Switzerland

On Sat, May 9, 2015 at 11:15 AM, <wilson.da...@gmail.com> wrote:

Hi,

I'm particularly interested in this benefit of your new codes format 

"Codes that are similar are located closer together than codes that are different"

I have a database of existing locations for which i have lats and longs. what would be the best way to search for results in my data

based on sub-codes ?

--
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 "open-location-code" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-location-code+unsub...@googlegroups.com.

[Stephan Büttig]

Exactly this would also be my use case!

[Andreas B]

Hi Sidd,

assuming that you have full, 10-digit codes for all locations (both stored and the user location), you can generate "neighboring" code areas and compare string prefixes as necessary. An example:

1. Assume that your user's location is CFGHJMPQ+RV. At ten digits, this corresponds to an area of at most 14m by 14m. This means that every other location starting with the same 10-digit code is within a couple of meters of your user's location.

2. This might be too precise for your application, so you could just cut two digits from your code. Every other location starting with CFGHJMPQ is located inside the same 275m by 275m area, meaning that is is at most ~390m away (diagonal of this area).

3. Cutting another two digits, every other location starting with CFGHJM is located inside the same 5.5km by 5.5km area, at most ~7.7km away.

4. Then, considering the eight adjacent six-digit codes: CFGH[J+/-1][M+/-1] gives you an area of three times that width and height, very roughly centered around your user's position. This should include all locations that are less than 5.5km away, but may include some locations up two 15km (two times the diagonal) away. These would need to be filtered in a second step, but for a short list of potential candidates this wouldn't be too hard.

One thing that is important to consider is that the above values for the area size are only correct at the equator. The areas shrink in width towards the poles, which you would need to take into account by considering more neighbors if necessary.

A while ago, I wrote a Java class wrapping OpenLocationCode objects that does some of this. There haven't been many updates in the last year or so, but it does the trick for some of my very similar use cases. Perhaps you can get an idea here: https://github.com/bocops/open-geotiling

[Rasťo Šrámek]

I'd simply decode the plus codes into lat/longs and then calculate the distance between the center point and all points, sort by that distance, and cut off. As Andreas points out, you need to worry about latitude: the distance from (a, b) to (c, d) is roughly sqrt((|a-c|*111.12)^2 + (|b-d|*cos((a-c)/2)*111.12)^2) if you (a,b) and (c,d) are close enough. If not, you can use a library such as S2 to do the calculations on a sphere/geoid.

--
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-c...@googlegroups.com.

To post to this group, send email to open-loca...@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/f783fbe0-e460-43a4-9d17-98418aa64ba2%40googlegroups.com.

[Andreas B]

Yes, that is an important concession to make - sometimes, it is easier to deal with the underlying coordinates directly than it would be to handle OLCs or any other representation. :)

The process I outlined above can still be useful to trim a dataset by an order of magnitude or two, before a more exact calculation is performed on the remaining candidates.

[sidd...@gmail.com]

Thank you, Andreas. Pointers were really helpful. 

I need a quicker & easier, even if bit approximate, way of scanning through several thousands of points than a more accurate comparison. 

OLC gives that with the prefix comparison. Taking the approach Andreas outlined seems to be a fairly easy way of handling my use-case.

Thanks guys!

Sidd

PS: Stephan - hope your query got resolved too :-)

[Stephan Büttig]

Hi,

sorry for the delay. Many thanks for the hints and instructions, they helped me a lot.

[Seb Verity]

Sorry for jumping on this thread at such a late stage, but I have a similar use case to the OP.

We have used 12 digit OLCs within a Postgres database to create unique IDs for a range of property assets across the world. Each 'thing' in the database should therefore be capable of being analysed in relation to its neighbours, both in the table & in reality, using simply the unique ID.

I was wondering if anyone had had similar thoughts or use cases - or indeed had implemented any functions to work with plus codes in this way? The US Dept of Energy have done some interesting exploratory work in this area: https://buildingid.pnnl.gov/pdf/UBID_Year_in_Review_Final_265829.pdf

[Seb Verity]

Actually - ignore that. I think I may have now answered my own question, thanks to this link: https://github.com/bocops/open-geotiling

Keep up the good work Doug!

[Andreas B]

Hi Seb,

great that you already found my "geotiling" repository. I haven't done much with it in the last year, but if you think there's anything worth discussing in that regard, feel free to open an issue there. I'm also watching this space in case there's further discussion.

Regarding the PDF you linked, I can't shake the feeling that using two OLC of the bounding box of an object to address something is probably not a good idea because it defeats the purpose of having a hierarchical address that allows comparing objects simply be their string prefixes.

[DƯƠNG VĂN THẠCH]

Thach...@gmail.com

[Seb Verity]

No I agree. Forcing a 'real world' entity into an OLC bounding box in that way is going too far. Centroids of features is more than satisfactory for this purpose. What was being suggested by the US Energy Dept looks an attempt to be too clever for the sake of it!