As much as I like the vision of making coordinates easier to handle, I have a few issues with it:

1. Their convert algorithm is proprietary
2. It has a fixed resolution of 3 meters
3. In order to convert coordinates you need an arbitrary wordlist of at least 40 000 words
4. They patented the idea of converting coordinates into words

So I decided to invent my own coordinate system that simplifies coordinates into a single string. However, instead of using 3 random words I wanted my system to be logical and also easy to implement. Also I wanted a system where your coordinates could be as accurate as you want. A system like decimal numbers came to my mind, where adding a digit at the end improves the accuracy of the number.¹

As I want my coordinates to be a string that is easy to handle nevertheless compact in information I decided to use Base64. (Actually base64url for easier handling.) In order to use a Base64 string as a location I use an 8x8 grid on top of a map in equirectangular projection (because it is the easiest projection to use with latitude/longitude coordinates). Every cell in the grid corresponds to a single Base64 character.

This is the first letter of the L64 coordinate. With a single letter you can give a very broad location. It might not be useful for the most things, but the first letter can distinguish between East Coast (m) and West Coast (j) or Mediterranean regions (y) and northern Europe (4).

In order to get more accuracy we scale the grid down by a factor of 8 and put it in one of the cells of the first level grid. This second level grid tells us the second letter of the L64 coordinate.

If we repeat this scaling and inserting of the grid we can construct a L64 coordinate with as much precision as we need. However only 8 characters are needed to get an accuracy of about 2m. With only 2 characters more the accuracy in the order of centimetres.

You see that this system is relatively simple. Implementing it is even easier, because of the used order of the letters. There are actually two different convert algorithms:

Converting via quadkeys

This is the algorithm I implemented first. It uses quadkeys to convert a location. Quadkeys are a base 4 number that corresponds to a square on the map. They work by dividing the map into four quarters, numbering them from 0 to 3. The dividing is repeated until the level of detail required.

It is important to note that the Bing Maps quadkey uses the Mercator projection, whereas L64 uses the equirectangular projection. The specific projection used in L64 also has the (0, 0) coordinate at the bottom left, instead of the top left.

Therefore the used numbering of the quadkeys is \(\begin{matrix} 2&3 \\ 0&1 \end{matrix}\) instead of \(\begin{matrix} 0&1 \\ 2&3 \end{matrix}\).

The L64 convert algorithm functions the following way:

1. Convert the coordinates into a quadkey with as much accuracy as you want. Mind the projection!
2. Trim the quadkey to a length of \(3x\), where \(x\) is the wished length of the L64 coordinate.
3. Convert the base 4 quadkey to Base64 using basic math. The beauty of this is the fact that \(4^3=64\) which means that 3 characters in a quadkey correspond to a single base 64 character.

That’s it. This is all the conversion algorithm. Converting a L64 coordinate back is as easy as reversing the upper algorithm. The only thing to note is that a quadkey resolves to an area and not a single point. Therefore you might have to calculate the centre of the quadkey square.

Converting via binary fractions

After thinking about my implemented algorithm a bit I realized it could be simplified. If you look at a quadkey (or a L64 coordinate, as they are the same thing in different bases) in binary it has an interesting property. The first digit indicates if you are in the northern or southern hemisphere. The second digit reveals if you are east or west of greenwich. The third digit specifies the north-south position established in the first digit further. And so on and so forth.

So this is the simplified algorithm after that realization:

1. Project the latitude and longitude to numbers between 0 and 1 according to the right projection.
2. Convert the numbers to binary fractions
3. Drop the 0. at the beginning
4. Interlink those numbers by alternating their digits starting with the latitude so that abc and xyz would become axbycz.
5. Trim the result to a length of \(6x\), where \(x\) is the desired length of the L64 coordinate.
6. Convert the resulting binary number to Base64. While doing that 6 binary digits correspond to a single Base64 char. (\(2^6=64\))

The reverse is also as simple as doing every step backwards.

While this algorithm has more steps than the previous one it is still simpler. This is so because most of the complexity of the first algorithm is hidden inside the first step: Calculating the quadkey

With the second algorithm it is as easy as looking at a binary representation of the coordinates and combining them by alternating.

This makes L64 coordinates especially useful on machines with limited power like a microprocessor that is connected to a GPS module. L64 could for example be used to transmit coordinates from a GPS tracker via GSM or an other type of radio with limited bandwidth. And if human readability is not required L64 coordinates can be sent directly as binary, allowing them to be as compact as coordinates can ever be.

You can play with an implementation of L64 with the Google Maps API here.

The basic requirements were the following:

1. Allow the tracking of points over several rounds compliant with Tichu rules
2. Be easy to use
3. Work on Android and iOS
4. Work offline
5. (Should not take to much time to program)

Choosing the Right Tools

In order to archive the requirements 3 and 5 I choose html/css/js to build the app. This might not be the best choice to build smartphone apps that should run offline, but it is possible and my go-to way for quickly building anything.

As I am using GitHub Pages to publish the app/website I can use Jekyll’s built-in compilers for SCSS and CoffeeScript, which are often more comfortable to write. In order to use the latter, however, it is necessary to include a _config.yml file with the following content to load the CoffeeScript-Plugin:¹

gems:
    - jekyll-coffeescript

SCSS, on the other hand, is supported natively by Jekyll and doesn’t need a plugin. The only thing left to do is prefacing the SCSS and CoffeeScript files with a an empty YAML front matter consisting of two lines of three dashes (---) in order for Jekyll to process the file. In the published version these files will now be replaced by their compiled counterparts bearing the same name, but a different extension. This allows an easy workflow with these pre-processors.

Writing the Application

Writing the app itself was trivial by nature, as the app itself only stores two values and chances them on user input. Because of that I’m going to focus more on the challenges of building it, which were making it look and work like a native app on smartphones.

Optimizing the Experience for Smartphone Users

As this project was planed as an app and not a website I made the layout and design only for devices with a narrow screen, disregarding PCs and laptops completely. I also adapted Google’s Material Design with Materialize to give it a clean app-like look.

To make it look even more like an native app I also created a manifest for the “Add to Homescreen“-function in Chrome on Android. This allows the website to be opened without the navigation elements from chrome and also have a custom high-resolution icon on the homescreen. (Which I didn’t create yet)

Caching

The most important part, however, was still missing. The requirements included that the app needed to work offline. In order for this to work, I created an manifest.appcache file and included it in the html via <html manifest="manifest.appcache">. This file tells the browser which resources to cache and which to load from the internet.

However, because some browsers apparently don’t support external links in the cache manifest I needed to include all used libraries locally first. That meant downloading jQuery, MaterializeCSS and the Google Icon fonts and adding them directly to the project.

Then I added the following to the manifest to create it dynamically with Jekyll:

---
# Empty front matter so that the file will be processed
---
CACHE MANIFEST                         # First line of the manifest
# {{ site.time | date_to_xmlschema }}  # Add a comment with the time the site
                                       # was last compiled, in order to check
                                       # for changes after the site is modified

CACHE:                                 # The following files will be cached

{% for file in site.static_files %}    # Loop over all static files
.{{ file.path }}{% endfor %}           # and print their path

{% for file in site.pages %}           # Loop over all generated files
.{{ file.url }}{% endfor %}            # and print their path

NETWORK:                               # Allow any other used resource to be
*                                      # loaded from the web

The last two lines are only needed for Google Analytics to work if the user is online, as everything else is cached.

Final Thoughts

While there could be still more done to make the app better (Refining the design for devices with very narrow screens, adding an icon, etc.) it works if you want to play Tichu regardless of your internet connection.

You can try the app here or look at the source code here.