Thanks Andreas. The fact that we can sort codes by comparing prefixes would also be helpful to just build an offline search directory to get started.
I think we wouldn't need to store all possible 8 character codes on the device but only those that have been tagged by users with a location name. In addition, when a user has an internet connection he can choose what blocks/areas he wants to download the data for (like google maps) and we could update that data with new listings whenever the user has internet again. The only issue of not storing every plus code is that a user would only be able to search plus codes that have been listed in the app. Thanks again for the explanation. It's definitely worth looking into and possibly implementing as feature improvements, depending on user feedback. Also, I'd really like to stay connected over linkedin. Mine's linkedin.com/in/abizer-jafferjee Thanks On Thursday, December 5, 2019 at 12:28:53 PM UTC, Andreas B wrote: > > Hi Abizer, > > yes, something like that should be possible. One great feature of plus > codes is that nearby codes mostly have the same prefix. This means that, if > the user wants to navigate to some location that is new to them, it would > be easy to look up all codes already stored on the user's device that start > with the same, say, eight characters. This would allow you to help your > users find their destination by a statement like *"Thomas's home is near > Tees Pizza"* (assuming that the user already navigated to the Pizza place > before). > > If there's no known place near the destination itself, something similar > could be attempted for nearby tiles (eight characters adjacent to the > destination), tiles along the direct route to the destination, or if all > else fails for the whole rectangular area that has start and destination in > opposite corners. In that case, a navigation statement could be something > along the lines of *"You want to go to Thomas's home. Looks like Tees > Pizza is about half way between your current location and that place."* > > The above seems to be realistic for users that use the app a lot in the > same place (for example their home town), if you cache a good number of > previously used locations. It is less realistic to do for the whole country > in advance. > > I did a quick back-of-the-envelope calculation to estimate what we're > talking about. With an area of ~950,000km², I would except there to be on > the order of 35,000 six-digit prefixes in use across Tanzania - but each > "tile" that could be addressed by a six-digit prefix has a size of > approximately 30km². I think it would be possible to find a "best city > name" for that number of tiles, for example by outsourcing that task to > your users - but that would mostly help with cross-country navigation and > postal services, but not really be useful for a step-by-step navigation > within one city. This data (35,000 x some bytes for a city name) would > probably fit on most user's devices, though, so it could be great to have > for offline functionality. > > Going from six- to eight-digit prefixes means a factor of 400, so roughly > 14M entries - which is likely too massive to either store or build in the > first place. > > On Wednesday, December 4, 2019 at 5:54:48 PM UTC+1, Abizer Jafferjee wrote: >> >> Hi Andreas, >> >> Thanks for the quick response. This is a really good idea. Currently, my >> focus was just on getting users used to the idea of using a plus code as an >> alternative to an address. But I didn't think enough about how helpful the >> plus code would be in navigation because I thought you'd still need to be >> online to make use of plus codes to get directions. >> >> I wonder if it would be possible to build even more detailed offline text >> navigation through the geo tiling idea. E.g if someone wants directions >> from current location to point B and the app has stored plus codes of some >> points in between e.g. road intersections, then we could string together a >> complete route by calculating the distance between closest plus codes at >> each point of the route. >> >> While the urban areas within countries like Tanzania have good data >> connectivity yet still expensive, the rural areas sometimes don't have any >> connectivity at all so a completely offline routing system would be really >> useful for organizations working within these areas. >> >> On Tuesday, December 3, 2019 at 9:49:19 AM UTC, Andreas B wrote: >>> >>> If you are including the OLC library in your project directly, you will >>> be able to calculate a plus code from the user's device location, and also >>> translate any plus code back into latitude/longitude coordinates. All on >>> device, without any need for connectivity: >>> https://github.com/google/open-location-code/tree/master/java >>> >>> Calculating the distance could then be performed on the lat/lng >>> coordinates using something like the Haversine formula ( >>> https://en.wikipedia.org/wiki/Haversine_formula) - or, alternatively, >>> following something like this wrapper class I created a while ago if very >>> rough approximations are good enough for an offline, step-by-step >>> navigation: >>> https://github.com/bocops/open-geotiling/blob/master/java/org/bocops/opengeotiling/OpenGeoTile.java >>> >>> In any case, displaying the current and destination plus codes while the >>> user approaches might help them find the exact location more easily. >>> >>> On Tuesday, December 3, 2019 at 6:20:27 AM UTC+1, Abizer Jafferjee wrote: >>>> >>>> Actually, connectivity is a big issue because mobile data is still >>>> relatively expensive in Tanzania. >>>> >>>> Currently the QR code has a deep-link back to the digital address >>>> within the app. >>>> >>>> One option I thought of was to create a USSD application which can be >>>> triggered from the app and would retrieve text directions to the location. >>>> >>>> I like your idea about giving some helpful information. How would I >>>> calculate the distance between two plus codes? And how would I know the >>>> plus code of the location the user is standing at? >>>> >>>> Thanks Andres >>>> >>>> On Monday, December 2, 2019 at 3:52:54 PM UTC-5, Andreas B wrote: >>>>> >>>>> That makes sense, thanks for the explanation. I agree with the >>>>> conclusion that plus codes aren't that useful in any scenario where both >>>>> users are online, and can just access a database with all the necessary >>>>> information. I wonder if it would make sense for your app to use plus >>>>> codes >>>>> as a fallback for scenarios where one or both users sharing an address >>>>> are >>>>> currently *not *online? >>>>> >>>>> For example, I assume the QR codes displayed by your app contain an ID >>>>> value referencing the address data. If the QR code *also* contained a >>>>> plus code directly, that could be used to at least display *something* >>>>> even if the user is not currently online. >>>>> >>>>> Would a statement like "1.5km to the north-west - more information if >>>>> you're back online" be useful, or is connectivity not an issue that needs >>>>> to be solved in your app's case? >>>>> >>>> -- 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/f8f96aec-08c5-4238-8d65-fd27f9a23d60%40googlegroups.com.
