From https://github.com/google/open-location-code "Open Location Codes are a way of encoding location into a form that is easier to use than latitude and longitude. They are designed to be used as a replacement for street addresses, especially in places where buildings aren't numbered or streets aren't named. Open Location Codes represent an area, not a point. As digits are added to a code, the area shrinks, so a long code is more accurate than a short code. Codes that are similar are located closer together than codes that are different. A location can be converted into a code, and a code can be converted back to a location completely offline. There are no data tables to lookup or online services required. The algorithm is publicly available and can be used without restriction. Codes are made up of a sequence of digits chosen from a set of 20. The digits in the code alternate between latitude and longitude. The first four digits describe a one degree latitude by one degree longitude area, aligned on degrees. Adding two further digits to the code, reduces the area to 1/20th of a degree by 1/20th of a degree within the previous area. And so on - each pair of digits reduces the area to 1/400th of the previous area. As an example, the Parliament Buildings in Nairobi, Kenya are located at 6GCRPR6C+24. 6GCR is the area from 2S 36E to 1S 37E. PR6C+24 is a 14 meter wide by 14 meter high area within 6GCR." ... A basic support in Marble would allow searching for Open Location Codes by implementing a search runner for it. src/plugins/runner/localdatabase/ should be a good template for an offline running search plugin.
There is a C++ implementation that can be used as a base at https://gist.github.com/Steve132/ca2308a9cef0cd7e7127 Needs to be tested of course, but should provide a nice start to implement the open location code decoding.
Created attachment 94342 [details] Implemented Open Location Code Search plugin. I've tested isValidOCL(QString) and decodeOCL(QString) separately and though about implementing a unit test in Marble for them, but I couldn't include the runner I implemented into a test. :) Also, I can't think of a way to test if the plugin is working properly as a whole.
You can use the approach shown in https://techbase.kde.org/Projects/Marble/Runners/Search to access the plugin in a unit test without having to #include it directly. Regarding the implementation of OpenLocationCodeSearchRunner::search() I think it does a bit too much: It calculates the bounding box and then returns all placemarks from the internal database found inside. Instead I'd just create a single new placemark, give it a name equal to the search string (i.e. the OLC code) and set the bounding box as its geometry, then return that. Marble will probably not show its bounding box in the search result, but its center point. That's ok for now.
Created attachment 94588 [details] Implemented Open Location Code Search plugin. On Open Street Map searching for an open location code displays a polygon on the map.
Git commit c802b43e5c63cb69400ba9fcec59d072bd4ee224 by Constantin Mihalache. Committed on 28/11/2015 at 20:18. Pushed by cmihalache into branch 'master'. Add open location code search plugin. REVIEW: 125377 M +1 -0 src/plugins/runner/CMakeLists.txt A +19 -0 src/plugins/runner/openlocation-code-search/CMakeLists.txt A +67 -0 src/plugins/runner/openlocation-code-search/OpenLocationCodeSearchPlugin.cpp [License: LGPL] A +46 -0 src/plugins/runner/openlocation-code-search/OpenLocationCodeSearchPlugin.h [License: LGPL] A +198 -0 src/plugins/runner/openlocation-code-search/OpenLocationCodeSearchRunner.cpp [License: LGPL] A +57 -0 src/plugins/runner/openlocation-code-search/OpenLocationCodeSearchRunner.h [License: LGPL] http://commits.kde.org/marble/c802b43e5c63cb69400ba9fcec59d072bd4ee224