Even if problems with determining the "correct elevation" didn't exist, I wonder how useful it really would be to have a code where all three dimensions are integrated. Having not only latitude and longitude subdivisions alternating (*XYXYXYXY+XY*), but also having an elevation subdivision (*XYZXYZXYZXYZ+XYZ*) would make the code longer and less readable. Appending it, for example by using "^" as a separator, would keep the code compatible with OLC and would allow the elevation information to simply be dropped where not necessary.
Brainstorming: Regarding useful units for height, I'd guess that elevation information is available mostly via GPS altitude, which actually is the height above the WGS84 ellipsoid. This could be clipped to sensible values (ellipsoid surface +/- 100km?), normalized into "distance to the center of earth" (http://www.summitpost.org/distance-to-the-center-of-the-earth/849764), and then subdivided using Base20 digits just like lat/long values. Four of those digits would get you into the range of 1m precision, which should be enough in most cases. -- 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+unsubscr...@googlegroups.com. To post to this group, send an email to email@example.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/e8fb142a-f45a-4e55-af33-7f74656a43ed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.