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 open-location-code@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/e8fb142a-f45a-4e55-af33-7f74656a43ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to