OLC in three dimensions

[X]

Greetings,

We are interested in using OLC to index a geographically partitioned and distributed open source GIS system for unmanned aircraft systems. OLC seems like a natural fit for a variety of reasons (varied resolution, cogent grid system, concise address, open standard, etc). However, we operate in three dimensions (as do our underwater unmanned system colleagues and our building information management system colleagues). I'm not sure how this also pertains to the addressing problem worldwide, but I have lived in places with no clear address scheme that included multi story buildings. This is the case even using OLC for our business where our office location is on the 2nd floor. In many of these cases, a vertical dimension would be helpful.

We could do our own implementation by appending some sort of elevation or z-axis, but I'm curious if there are thoughts from the team on a three dimensional implementation of the system.

Thank you,

X

[Doug Rinckes]

Hi X,

We designed OLC as a solution for unnamed streets, or places where street addresses aren't possible/don't exist. We didn't include a 3rd dimension because:

1. it's not necessary in probably >90% of addresses
2. we didn't see any unit being widely used or useful (floor number? meters? meters over ground? meters over sea level? which sea level?)
3. even floor numbers aren't consistent across countries, some use 1 as the ground floor and others use 0, or G, or L, etc.

So we left it out. For your case, maybe use OLC as the XY location and then meters or barometric pressure for height?

Doug Rinckes, Technical Program Manager, Google Switzerland GmbH; 9GHJ+P88 Zürich

--
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+unsub...@googlegroups.com.
To post to this group, send 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/d8f12db8-a73c-4e6c-8518-25b0b2399c84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[X]

Greetings Doug,

Thank you for the background information. You are right about the additional challenges in determining altitude. Both above ground level and above sea level pose challenges since both may vary in certain grids. We'll do some thinking on the problem and let you know if we figure out a useful 3d implementation.

X

[Doug Rinckes]

Cool! Yeah, UAVs are an interesting use case. If you come up with something we'd love to hear!

Doug Rinckes, Technical Program Manager, Google Switzerland GmbH; 9GHJ+P88 Zürich

--

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+unsub...@googlegroups.com.
To post to this group, send 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/790b3079-c7ee-4799-ae6d-bd846e001844%40googlegroups.com.

[Andreas B]

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.