Atlas Permalink Bugfix

The new Atlas option was being saved to Permalinks and was respected in the map, but wasn't being properly respected in the map frame. That's fixed now. Ω

Add a map to your site!

I was browsing the Great TML Landgrab site and lamented the fact that many of the grabbee sites don't have maps showing where the systems are.

Now there's no excuse - just add the following line of HTML to your page, adjust the coordinates, and you've got a full fidelity map:

<iframe src="http://www.travellermap.com/iframe.htm?x=-95.914&y=70.5&scale=64&options=887" style="width: 200px; height: 200px; border: solid 1px black;"></iframe>

Note that it looks like a Permalink from the site, but with one subtle difference: "/iframe.htm" is specified rather than just the default page ("/"). This is a version of the map with no UI, specifically for embedding.

You can get the x/y by finding the system on my map site and using the "Permalink" feature in the footer - click it and it will give you the full permament URL of what you've got centered. Then copy/paste into the URL above - remembering to change the URL to include "iframe.htm"

You'll get something like this:



Note that it's a fully functional map - you can drag with the mouse and zoom by using the mouse wheel or double-clicking (hold Alt to zoom out).

Go wild!

Edited 2007-03-19 to call attention to the "iframe.htm" part of the URL necessary for embedding. Ω

How did you do that?

The map works the same way (I assume - I don't know for sure) as the latest generation of commercial map sites - Windows Live Local , Google Maps, Yahoo! Maps, etc. Which is...

There are two parts: an HTML page and a special Web server application.

There's an HTML page with script in it. The page keeps track of three things: where your view is centered (in my case, astrographic coordinates), what your zoom level is (pixels/parsec) and what view options you have selected (coded into a binary number). When the page loads it runs a simple subroutine that tries to answer the question: "gosh, what should the user see here?"

This subroutine first figures out how big the window frame is, then breaks it down into 256x256 pixel "tiles", and then figures out specifically which tiles it needs to fill the frame based on where the user is looking.

Here's an example tile URL:

http://www.travellermap.com/Tile.aspx?x=-1.2&y=-1.0&scale=2&options=881

(For historical reasons the x/y values are actually scaled by the zoom level, so if you change the zoom level your point of focus will change. Strictly speaking, the x and y are in screen space rather than world space, but it's all just a transform away.)

The HTML page then just says "add a tile image at this URL to the page at this position" - in HTML parlance, it just creates a new IMG element with a SRC like the above and and uses STYLE to position it. It does this until the window frame is full. Drag/scrolling is actually pretty easy - the page captures mouse events and when the mouse drags, say, 10 pixels to the left, it simply offsets the HTML element which contains all of the tiles by 10 pixels to the left. And then (here's the magic bit) it simply runs the whole logic all over again - "gosh, what should the user see here?" which determines if any new tiles need to get loaded around the edges. Any time you change options the same thing happens - it just throws away the images you're looking at and figures out which tiles to ask for.

That leaves the server side. In this case it's an ASP.NET 2.0 web application on IIS6, but you could do the same thing with pretty much any server. The nice thing about ASP.NET is that you get GDI+ (a high fidelity graphics subsystem of Windows) available easily, but again there are equivalents for PHP if you were doing this on Apache.

The web app handles the incoming request for a tile URL (like the above), creates a temporary image in memory, and falls into a big rendering routine. Based on the zoom level, it figures out what to draw - from the whole galaxy to borders and rifts to routes and dot-maps to hexes and systems. Based on that, it figures out which data files to load (from a cache) and it either loads XML vector shapes which define the borders/rifts, a big XML file which defines which sectors are where and the metadata, or (at a low level) the standard .SEC files. It figures out what subset of that should be drawn in the current tile and draws it. (The way modern graphics systems work, you can draw "sloppily" outside the bounds of a box and it'll get clipped. This is convenient - I just draw everything "close" to a tile, and the right stuff shows up.)

Then the server takes the image in memory, converts it to a GIF, and returns it to the Web browser. Rinse and repeat.

Make sense? Ω

New Features: Options, Styles, and Eggs

While moving to the new host I snuck in a few more features:

• Simplified options - there's really no need for the "minor borders" and "minor names" label options, and it just made the page harder to use.
• New rendering style - toggle the Poster and Atlas radio buttons at the top to see the map in the "Imperium Map"/"Spinward Marches" Poster-style (color-on-black) or the Atlas/LBB style (black-on-white).
• One new easter egg added: type "(Arrival Vengeance)" (with parenthesis, but no quotes) into the Search box and you can retrace the last epic journey before night fell on the remnants of the Third Imperium. (And see some glaring examples of sector data issues.)

I haven't tested the map in Opera or Safari for a bit, so please report any issues encountered.

[Update: January 25th, 2008]

D'oh... I'd spelled "Vengeance" as "Vengance". Fixed in the blog and on the site.
Ω

New URL

The Traveller Map has a new home:

http://www.travellermap.com

This should be a little easier to remember! Note that it may take a few days for this new domain to propagate across the 'net. If it doesn't work for you, try again in a day or two. Once it's been up for a bit I'll decomission the original site. Ω