Interactive Maps and JavaScript

There are two major libraries for displaying interactive maps using JavaScript.

• Leaflet is quite easy to use, yet powerful enough for many if not most applications.
• OpenLayers 3 has more features but requires you to learn more before you can use it.

OpenLayers is used at our company to provide an application that is used in a number of locations, namely for the map of Cologne (at www.cologne.de). Seems as if they don't update their English pages that regularly, koeln.de is updated considerably more frequently.

Anyway, for a private project I use Leaflet instead. It visualizes the location of the Stolpersteins in Bonn and the nearby region. You can find it at stolpersteine.codeforbonn.de. It is part of the Code for Bonn project which in turn is part of the Code for Germany project, the German twin of Code for America.

The stolpersteins shown are taken directly from the OpenStreetMap database so adding a new stolperstein to the database means improving OpenStreetMap.

Math in the World of HTML and JavaScript

At work I use a lot of JavaScript as our company (among other products) offers a map client that runs in browsers. As a side effect I frequently come across interesing JavaScript libraries. I find worth sharing. Here is an example of using JavaScript to display math formulas in a nicely formatted manner. To give an example, Einstein's famous formula will look like this:

$E=mc^2$

The library used for this display is MathJax. It should be sufficient for everything formula you reasonably expect on a website that does not dig deep into natural sciences or mathemtatics. In most cases it should even suffice for these fields of application. Here is a slightly odder example:

$U^{ik} = \frac{c_g^2}{4\pi G} = \left(-g^{im} \Phi_{mr}\Phi^{rk} + \frac{1}{4} g^{ik}\Phi_{rm}\Phi^{mr} \right), \quad -\nabla_\beta U^{\alpha\beta} = \Phi_k^\alpha J^k$

Well, maybe we better say it should be sufficient for almost any application ;-)

A cute little bluetooth keyboard

I finally have one.

万歳🙌!
万歳🙌!
万歳🙌!

Odd Marlboro ad

So true.

Hanami 2016 in Bonn

Almost in front of the house I live in 😀

Removal of Firefox and Thunderbird Plugin pages

The content on these pages had become quite outdated and it is very unlikely that I will find time to update them any time soon. I therefore decided to remove them altogether.

The Sorrows of Young OSM User

OpenStreetMap (OSM for short) is a web site that not only displays maps but also provides access to the database from which these maps are rendered. So far, so good.

Our company now came up with the idea that given a street name and a region where the street is located (around the globe there are tons of streets that go by the name "main street") we use the Overpass API to query the ways that make up these streets.

The plural streets reflects an important issue: Even within a single city there may be several streets that go by identical names.

In principle this can be achieved assuming that the user is young enough not to die of old age before the query yields a result.

We looked into alternative ways for directly fetching data from OSM but all either turned out to be too slow or simply not up to the task.

It seems as if the only feasible way is to have two server tasks:

1. One that fetches the data from OSM.
2. One that provides the full path via an API.

The point is that there are still three possible ways of implementing the first server task.

1. To have a job that is triggered at certain times and that imports the data.
2. To have let the server operate as some sort of caching proxy for the data.
3. To have a mix of the two previous solutions.

My idea is as follows:

1. Initially the server's database is populated using an appropriate import feature.
2. If a request occurs it is checked whether the requested data is in the database and is not outdated (with a reasonable definition of to be outdated that does not require a request to OSM).
3. If the server's data is outdated an updated version is requested from OSM. This can yield two results:
   1. The query can quickly return the current information. In this case the data is stored in the server's database and delivered to the user.
   2. The query does not return the result within a reasonable time. In this case the server returns the data that is stored locally. Chances are very good that the outdated data still is a reasonable approximation of the most recent data. This case has two subcases:
      1. The query simply takes too long but still returns a result. In this case the returned data is used to update the database.
      2. The query times out and does not return a result. In this case the outdated data is kept.
4. Every now and then the server checks which data is most outdated and tries to obtain these data.

Comments?