Examples in other pages of
documentation here are still using version 3 so are incompatible with
the updated demo map and app. The algorithm is the same but uses the
The code does not prescribe further formatting but formatting rules might be applied depending on the application to which the code is applied. The code does not require the checksum character - though it would be essential for many applications.
As a generic code, adaptable to any territory or purpose, private or public (though most suitable to roughly square areas), its parameters are simply a western longitude, a northern latitude, a height and width in degrees, a string of encoding characters. The parameters proposed for Ireland are: west=-10.75; north=55.5; wide=5.4; high=4.2; alphabet="23456789CDFGHJKLMNPQRTVWX", checkalphabet="0123456789ACDEFGHJKLMNPQRTUVWXY".
Increasing the coding alphabets, for purposes with less language concerns, and decreasing the area size, both increase precision; and vice versa. Height information, for whatever purpose, could be added as an additional code, or incorporated into the code as a cubed base rather than squared.
The code is technically open to extra, "special region" codes, such as overseas interests (e.g., Rockall at 57.596667, -13.688611), military camps, embassies, offshore drilling fields, etc., using any of the non-code characters at the code beginning ("01ABEIOSUYZ") - conversion programs would revert to a database for the correct offset if available. However, it would be more logical to use the World Postcode implementation of the same algorithm: 4THJJJ/Y. Similarly, codes sections are open to being purposefully renamed to match "post-towns" - though it would be illogical and ugly. An example of other regional implementations: a Hong Kong OpenPostcode is defined by "west=113.8; north=22.6; wide=.7; high=.5; digits=6" and available at opcmap.org/N962-65/J.
An extension of the code to a world geolocation code
in 10 characters is available at opcmap.org
" is a variation and convergence to the familiar public-domain Geohash
code, but more precise at base-36, more orderly in placing neighbouring codes, and avoids the traditional Geohash's language problems with vowels. As case-sensitive the Geohash-36 is not a suitable code for human memory or communication but is perfectly suited to databases, URLs, and tweets. It uses the same OpenPostcode algorithm but with a 36 character alphabet "23456789bBCdDFgGhHjJKlLMnNPqQrRtTVWX". 36 is significant as the square of 6 - describing a 6 by 6 grid for each character. Lowercase characters are chosen where the lowercase representation is more than just a smaller version of uppercase in standard fonts. The checksum alphabet is the lowercase English alphabet - which distinguishes the Geohash-36 from other OpenPostcode regions. The checksum is not required - but usefully checks the code validity and confirms it as a Geohash-36 in applications which may have more than one code.
At 10 characters it is accurate to within 0.33m x 0.47m.
Example: geo36.org/bdrd5tb4Md-n. Altitude could be added using "A" as a delimiter, with metres encoded in the same base36 encoding (below sea-level delimited by "a"). The checksum would be calculated as normal with the value 0 for "A" or "a" - ensuring that altitude data could not be confused with location data.
The Geohash-36 is open to being applied in bespoke applications and databases to smaller regions for greater precision and shorter codes.