Wow! I can’t believe it’s been five years since I developed Rikitraki. A lot of things have changed in Web development since then, so I think it is time to implement some sorely needed renovations.

Some of the changes are simply to bring the code up to snuff with today’s best practices. But some other changes will be functionality improvements that I have been thinking about for a long time.

In this post, I lay out what I am thinking for the next big release. Comments and suggestions are greatly appreciated.

Code base renovation

When I developed Rikitraki five years ago, I decided to forgo any heavy duty frameworks in favor of plain Javascript and JQuery. At the time, React was really hot, but I thought it was overkill to implement the features that I had in mind for Rikitraki. Besides, it was not all that clear to me how easy it would be to incorporate big libraries such as Leaflet and Cesium into a reactive framework such as React. So I went ahead and implemented the project without a framework.

Another big decision I made back then was to incorporate two mapping libraries simultaneously: 1) Leaflet for 2D mapping and 2) Cesium for 3D. This added complexity to the code base, but at the time I though it was worth it, because I needed a fall-back capability to support devices where Cesium would not be supported or simply it would be too heavy to run.

Fast forward five years:

• I had the opportunity to learn and use Vue.js and Gridsome, both of which have been a real pleasure to use. I really like the component-based approach to coding: easier to read, easier to maintain, better reuse.
• Cesium has been around and continuously improving. I think it is pretty safe these days to use Cesium-based applications on a reasonably recent device and a modern browser.

So I think it is time to rewrite the front end in Vue.js, Gridsome and Cesium. No JQuery, no Leaflet, no Bootstrap.

Front end scalability improvements

Right now, Rikitraki retrieves the entire list of tracks stored in the database and displays track markers on the map and the globe (the list is limited to MAX_TRACKS, defined in the back-end, and currently 5,000). In 2D, the markers are clustered, but in 3D, each marker is shown individually.

Even though marker clustering helps, it does not seem to be a great idea to put everything on the map, especially if the number of tracks grows above a few thousands. The current version of Rikitraki has a filtering function to pare down the number of tracks to be loaded at once, but I don’t think it is very intuitive to the casual user. I believe that I need to incorporate a very explicit and friendly way to limit the amount of data shown on the map.

I have learned that my original concept of “just show a map” as the main user interface, does not seem to scale well with a very large number of tracks.

I have been thinking about framing the map with interactive info panels that can be used to filter tracks as well as make it more explicit to the user about what they are actually seeing on the map.

I have done something similar already in a number of projects (e.g., HOWL, Libro Rojo, and Geoportal. Of course, I still need to define the details of the info panels, but that will happen as I develop the new application incrementally.

Back end

The current Rikitraki back end consists of a set of REST services running on Node.js, accessing a MongoDB database, hosted on Google Cloud Platform. Even though I am not too keen on having to host and babysit a services layer and a database server, this seems to work just fine, and it is super cheap.

I may entertain going serverless using Cloud Functions functions and a cloud database, but I am skeptical about finding something cheaper than what I currently have. So for the moment, no changes.

Features

As a baseline, I will retain most, if not all, of the features currently available. I will also work on some new features I have had in mind for a long time (documented on Github):

• Implement a more seamless transition between 2D and 3D visualizations - By using Cesium as the single library for mapping, switching between 2D and 3D should be very straightforward.
• Add the option to pin tracks to the surface of the 3D terrain - This is still tricky. Cesium now supports ground clamping of polyline geometries. However, performance of dynamic lines (i.e., path graphics) clamped to ground is pretty slow. I will need to deep dive into this to see if I can figure out an reasonable approach or a workaround.
• Add the capability of filter tracks “near me” or near a selected click marker on the map - The Rikitraki back end already has support for location-based queries. It is just a matter of integrating the front end.
• Add “swipe” support when displaying track pictures - Not hard to do, especially since I will be using Vue.js.
• Auto-assign region tags based on trailhead location - I will need to integrate a reverse geolocation service. Nominatim looks really promising.

Please feel free to comment and/or suggest new features in the comments section below, or in the issues section of the Rikitraki Github repository. You can also send me a Tweet.

I will be posting here once I begin development, including a link to the early version, which will run in parallel since the back end is not changing.