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! On Friday, 29 May 2020 17:07:42 UTC+1, Seb Verity wrote: > > 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 > > On Sunday, 7 April 2019 08:21:49 UTC+1, Stephan Büttig wrote: >> >> Hi, >> >> sorry for the delay. Many thanks for the hints and instructions, they >> helped me a lot. >> >> Am Mittwoch, 27. März 2019 13:42:48 UTC+1 schrieb sid...@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 :-) >>> >>> >>> On Wednesday, 27 March 2019 00:49:57 UTC+5:30, Andreas B wrote: >>>> >>>> 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. >>>> >>>> On Tuesday, March 26, 2019 at 8:02:26 PM UTC+1, Rasťo Šrámek wrote: >>>>> >>>>> 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 <http://s2geometry.io/> 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-code+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/open-location-code/b017f590-a07a-4205-93a3-58d7e2f234a8%40googlegroups.com.
