Including floors in open location code about open-location-code HOT 7 CLOSED

We thought long and hard about floors or heights but decided against
including them in the base specification, mainly because we couldn't see
any major benefit beyond saying "7QQ32HM7+CV, Floor 77".

A floor number is helpful but doesn't actually give the exact destination.
I'm thinking of office buildings or hotels where you need a room or suite
number, possibly in addition to the floor.

It turns out that floors are counted differently in different countries -
the ground floor can be 0, or 1, or G, so we'd need to either choose one
(and confuse everyone everywhere) or say "we use the local idiom" and risk
that travelers get confused.

If you put it at the start or end, truncating the codes end up removing it,
and we wanted to be able to retain it.

The reason we couldn't see a strong benefit is that the phone can guide you
to 7QQ32HM7+CV, through the use of location and GPS services, but it can't
guide you to the 77th floor, because it doesn't know how high up that is.
The floor number is something you need to know, so that you can press the
right lift button, so putting it into an opaque string cold be seen as
reducing it's usefulness.

Does that help?

Doug Rinckes
Technical Program Manager
Google Switzerland

On Fri, Aug 14, 2015 at 6:55 PM, Irvin [email protected] wrote:

We can use second + for floors, eg., 7QQ32HM7+CV+77 represent Google in 77
floors of Taipei 101.

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

from open-location-code.

I would love to have the 3rd dimension included as e.g. altitude but not separately, instead directly encoded like latitude or longitude and e.g. noted that the code is 3 or 2 dimensional. This way the application could theoretically convert it into a local floor definition but at least the smartphone could guide you to the correct height e.g. guided by local installed WLAN indoor systems giving precise height informations.

I'm thinking of office buildings or hotels where you need a room or suite number, possibly in addition to the floor.

If you have the location you have the room already or did I misunderstand this part?

from open-location-code.

If you go with altitude, I was thinking about @, because you are "AT some height". A Plus Code would be something like this: 9C3W9QCJ+2VX@100 to say you are at 100 meters high. (But I can imagine that other symbols can be choosen too; as long as it isn't #, ?, / or \, because you probably want codes to be used in HTTP URLs).

I think that it is possible to add some altitude-like thing to the OLC spec, as long as it is mentioned that it is a suffixed thing and not part of the core string. That should mean that the suffix stays when recovering or shortening: +2VX@100.

Also, what sign should be used when doing extraterrestrial stuff: #499?

from open-location-code.

+ is already in use as a separator, eg. 22222222+22

from open-location-code.

We can use second + for floors, eg., 7QQ32HM7+CV+77 represent Google in 77 floors of Taipei 101.
(Or we can use other separators.)

from open-location-code.

Enough to understood. However as your example, people still need to know the floor numbers when we locate some place, so a floor numbers must come with the code in metropolitan. In this situation, it's always better to decide a specific format that machine can read and process, which floor 77 / 77F / 77 階 / 77 樓 / G / T / R... or it's many various represent methods across different language and culture are hardly to recognize by machine and obviously not good enough.

Looking forward to see this into next version of spec.

from open-location-code.

If you go with altitude, I was thinking about @, because you are "AT some height". A Plus Code would be something like this: 9C3W9QCJ+2VX@100 to say you are at 100 meters high. (But I can imagine that other symbols can be choosen too; as long as it isn't #, ?, / or \, because you probably want codes to be used in HTTP URLs).

I think that it is possible to add some altitude-like thing to the OLC spec, as long as it is mentioned that it is a suffixed thing and not part of the core string. That should mean that the suffix stays when recovering or shortening: +2VX@100.

Also, what sign should be used when doing extraterrestrial stuff: #499?

I think this is a very good idea, but I'd rather go with altitude (orthometric height) instead of floors which is imprecise, plus most of systems already use meters as primary unit.

We'll use the starting index for plus codes at sea level, which is 100 meters.

import openlocationcode as olc

def encode3D(lat, lon, alt, codeLength=10):
    """Get a 3D+ code from a latitude, longitude and altitude."""
    return f"{olc.encode(lat, lon, codeLength)}@{alt}"

def decode3D(code):
    """Get a latitude, longitude and altitude from a 3D+ code."""
    code = code.split("@")
    codeArea = olc.decode(code[0])
    lat, lon = format(codeArea.latitudeCenter, 'F'), format(codeArea.longitudeCenter, 'F')
    alt = int(code[1])
    return lat, lon, alt

if __name__ == "__main__":
    
    print("North Pole, 1000m altitude")

    code = encode3D(lat=90, lon=0, alt=1000, codeLength=13)
    short = olc.shorten(code.split("@")[0], latitude=90, longitude=0)
    decode = decode3D(code)

    print(short) # in short +X2RRR @ 1000
    print(code) # CFX2X2X2+X2RRR@1000
    print(decode) # ('90.000000', '0.000001', 1000)

Hey @drinckes & @bocops it should be noted here that:

The Geohash-36 and Natural Area Code definition includes an optional altitude specification, and an optional checksum, neither of which are provided by Open Location Code.

from open-location-code.