G E B W E B

New user interface

Hold down shift while pressing reload to make sure the page fully reloads if OptiMap appears broken.

The first thing you’ll notice is a complete makeover of the user interface. The functionality has grown considerably since I first posted OptiMap in 2007, and the controls were scattered randomly around. Now, they are organized into neat little drawers on the left, in the order you are likely to be using them.

There is some new functionality as well. The ‘Edit Route’ section gives you the chance to re-order the trip after it has been computed. Have to visit one client first? No problem, drag to the top. You can also delete stops from the itinerary here.

OptiMap 4 also has a more powerful TSP solver routine. The new solver kicks in when there are more than 15 stops, and produces better and more robust solutions than the old engine. It is guaranteed to perform better than before, and in some hard cases I’ve tested, it improved the solutions by as much as 6-7%. That means that if you spent 8 hours on the road before, you now get home half an hour earlier.

Support for Garmin GPS units is underway, and will be added in a later update to this version.

There are some bug fixes as well: When pasting data from Excel spreadsheets into the bulk add box, the cell delimiters were lost. This is fixed. The print function used to show half a page of unnecessary white space at the bottom, thus it sometimes would print blank pages at the end. This is fixed so you won’t be wasting paper needlessly any more.

As a bonus, you may now access the service from a shorter address: www.optimap.net (the old address will continue to work, and the page will remain identical)

I hope you enjoy the update! Please post questions, feedback, bugs and suggestions here. I’m sure I broke something during the update…

For a long time now, my mantra has been optimization. To make the most out of limited resources makes sense both economically and environmentally. OptiMap was an example of this. Driving too far is just stupid. Using OptiMap saves you time and money and it saves the environment too.

There are many other wasteful behaviors we need to address to optimize the usefulness (utility) of our planet’s finite resources. When I started to learn about embodied energy, I was shocked by how much energy is spent in the process of manufacturing the products we buy. An average $20 book has an indirect footprint of 20 kg CO2, mainly due to extraction of the raw materials needed and manufacture of the book itself. This is the equivalent of driving an average car more than 130 kilometers. Given the sheer number of things that most people own, these indirect emissions certainly add up.

How can we optimize this? First, we need to realize that in many cases, ownership of these items is not why we buy them. We want access to the features that the item can provide. You don’t buy the boardgame Axis & Allies because you want to be the proud owner of it. You buy it to play it. And it probably collects dust 364 days a year.

If someone has the item I need, and it collects dust most of the time, they wouldn’t mind lending it to me, right. And I would certainly return the favor some other day. But we need to survey the resources available. Then make that information searchable. So that when you need a power drill, you can find the one closest to you. SkyLib.org is my attempt at doing this. Yes, it’s beta and yes it lacks many features. Certainly rough around the edges. But you can start organizing your stuff and building your personal library today.

Some features that are not done yet but under development:

• Friends support, invites and import from other social networks
• Buying and selling things
• User ratings
• Wanted-functionality (I need x)
• Renting and deposits
• Custom location search (Find item closest to me)
• Facebook login
• Embedding products on third-party websites
• Intro-video

Feedback is hugely appreciated! Please head over to www.skylib.org and give it a try. I’m already sharing 120+ items with you as of this post.

A reader asked me for some information on how the dynamic programming algorithm for the TSP works. I was surprised to find that a Google search found no good resources. Wikipedia merely acknowledges its existence: “One of the earliest applications of dynamic programming is the Held–Karp algorithm that solves the problem in time O(n²2ⁿ).”

Consider the TSP problem with N+1 points labeled 0, 1, …, N. We start at point 0. The distance from point i to point j is dist[i][j].

In dynamic programming, we seek to solve a problem by first solving smaller instances of the same problem. We start by looking at the really trivial size problem: What is the best order to visit just one of the destinations?

Assume we have N destinations. There are N size-1 problems, one for each of the N destinations. The best way to visit each is the shortest path from node 0 to node N. We store the best solution to each of these problems in a table:

best[subset][end] = dist[0][end]

Here, subset represents which destinations have been visited. More specifically, subset is a bitmask: an integer where bit i is 1 if destination i has been visited and 0 otherwise. Also note that the stored solution is the solution to the A-Z TSP problem, so it does not include the cost to return to the origin. The variable end is the destination that this A-Z problem ends at.

Now, lets expand to all the A-Z TSP problems of size one larger:

best[subset][end] = min(best[subset \ { end }][i] + dist[i][end])

Here, i is an intermediary node that is 1 in subset and not equal to the end variable. Before we move on to the next size problem, we have to fill in all the possible subsets of the current size. Finding all of those subsets of size s is what the function nextSetOf(s) in BpTspSolver.js does. How do we justify this expansion? It does not matter to the distance of the larger problem in what order the intermediary destinations of the 1-size smaller problem ending at i was visited in, so we are safe to only store and look at the optimal such sub-solution.

Finally, when we reach the desired size where all the destinations are visited, we only need to look up the best solution to the A-Z TSP problem in the table:

best[2^(N+1)-1][N]

(2^(N+1)-1 is simply the integer with all the first N+1 bits set to 1). If we want to return to the origin, we instead take the min over all i of

best[2^(N+1)-1][i] + dist[i][0]

This then becomes the best solution to the roundtrip problem. It is important to note that while this solution may look fast, there are 2^(N+1) different subsets involved (really 2^N, because 0 is always visited). Also, each subset solution needs to be stored, causing high memory usage. However, O(2^N) is still much better than the brute force O(N!) solution. 10! is 3 628 800 while 2^10 is only 1024. With the brute force solution, OptiMap could solve optimally up to 9 destinations. The dynamic programming solution now allows OptiMap to solve optimally up to 15 locations.

After being “almost ready” for way too long, the next version of OptiMap, based on Google Maps API version 3, is now launched. While I have tested most aspects of the application, there are most likely bugs, since the update touched almost all areas of the code. There are some improvements too, however:

• More robust address lookups (a lot of people experienced a “failed to geocode” error when entering many addresses. This was due to too many requests in a short period of time, and a queue-system has been added to avoid this from happening. The lookups may take slightly longer due to this.
• Progress indicator for directions lookups. Because version 3 of the Google Maps API only allows 10 waypoints in a single request (down from 25 in the previous version), this part is now a bit slower, so a progress indicator is needed.
• Tuning of the solver code based on faster browsers becoming more common. This should improve the quality of the solutions for cases with more than 15 locations.

Please help me solve any bugs that you may encounter by posting a comment on this site. Information that will be helpful when locating the bug includes:

• Browser (with version if possible)
• List of addresses or locations and a description of how to reproduce the bug
• The output that you see (error message, why you think the solution is wrong etc.)

I’ve created a map which shows the measured radiation values in Japan (note that this map is no longer online – the rest of this post is out of date). The data is scraped (credits go to Marian Steinbach) every 10 minutes (hit refresh to get the newest data). You can also click on each measurement location to see a chart of the measurements from that station over time.

Currently, there are about 200 measurement stations, but I’m having trouble finding the latitude and longitude of each measurement station. I’m sure someone who knows Japanese would have more luck…Anyway, I’m slowly working my way through the list of measurement stations, so more locations will be added continously. Any help with this would be much appreciated. Feedback and criticism is welcome, and should be added as comments to this page.

Update 2011-03-20: With the help of volunteer “hosoyamane”, a Japanese translation of the map is now available. It’s great to see volunteers pop up so fast!

Update 2011-03-20: A small spike in radiation is showing up in the stations in the Ibaraki prefecture around 10 am Japan local time this morning. However, the levels are still low (1000 nano-Gray is still 2000 times less than the average yearly dose of background radiation).

Update: The original radiation map I created is no longer maintained. Instead, users are redirected to a map created by the Institute of Information Design of Japan.