Nifty Online Map Generators

IsoMage has some nifty random map generators over at http://axiscity.hexamon.net/users/isomage/maps/ including subsectors, worlds, wilderness and caves. It uses seeded pseudorandom numbers for repeatability, just like the Elite universe. Check it out! Ω

Now Serving PDFs

It's live. (Be gentle!)

The API docs have been updated, but here's the short version:

For Poster.aspx, Tile.aspx or JumpMap.aspx, either pass an HTTP "Accept" header with "application/pdf" or include "accept=application/pdf" in either the query string (GET) or form data (POST).

Since it took a whopping 10 seconds, I also added a checkbox to the post example if you want to generate PDFs from your custom data.

Once any bugs are shaken out of this update I plan to add a link to the bottom of the main map page which offers "give me a printable version" of whatever you're looking at. I could make it either "smart" and offer Charted Space, Domain, Sector, Quadrant or Subsector depending on scale, or "dumb" and spew out exactly what you see on screen but in PDF form. I lean towards "smart". Ω

PDF Generation, Continued [SNEAK PEEK]

I have almost everything functional again under the PdfSharp code. The time consuming bit is that I was using GDI+ TexturedBrushes for a couple of things and PdfSharp (wisely) doesn't provide this, so you have to implement this manually. This actually ended up simplifying the code in several places. The only gotcha is that I was using it in a somewhat complicated way for rendering pseudo-random stars within the galactic arms at certain scales.

The old algorithm went like this:

if (inside charted space)
  draw a bunch of pseudo-random stars on the tile
else if (inside the galactic bounds)
  construct a tile-sized bitmap
  draw a bunch of pseudo-random stars on the bitmap
  load a path describing the galactic arms
  on the tile, fill the path using the bitmap as a brush

The new code looks like this:

if (inside charted space)
  draw a bunch of pseudo-random stars on the tile
else if (inside the galactic bounds)
  load a path describing the galactic arms
  use the path as a "clipping" region
  draw a bunch of pseudo-random stars on the tile

Simpler, huh? Well, yes, but it turns out that (1) it's a whopping huge path with lots of curves and segments (and I reduced it as much as I could), (2) bitmap-based clipping is heavily optimized, and (3) it's a single clip against a region, rather than once per star.

After pondering the importance of this (i.e. not very) I decided to simply ditch the pseudo-random stars away from charted space, and turn on the pretty galaxy image instead if you zoom out.

So... I'm pretty close to flipping the switch on this to make it live, but want to double check all of the changes first. But to whet your appetites, here are few more previews:

Spinward Marches - Eye-Candy - this one is a bit big (1MB) due to all the images
Charted Space

Enjoy! Ω

PDF Generation [SNEAK PEEK]

I'm playing with the PDFSharp library which provides PDF generation capabilities for C# with a liberal license and can be used with ASP.NET handily enough. The library nicely supports using the same rendering primitives to output via GDI+ or PDF, so I can actually just convert the site's entire rendering stack onto PDFSharp (which looks a lot like System.Drawing anyway) and then simply pass it either a bitmap or a PDF into which to render.

After a couple of hours of playing, here's sample output from the Poster API:

http://www.travellermap.com/tmp/spinward_demo.pdf

Warning: don't blithely hit "print" - I'm not doing anything clever with units yet, so I don't know how many pages it will try and span. Examine the print options carefully. :)

This is not live yet - there are several things not working yet and I'm concerned about performance when suddenly have the main map site running through this code. But so far, it looks promising.

When it is live, you'll be able to use the Tile, Poster and JumpMap APIs to generate PDFs by specifying either a Content-Type HTTP header or a query string parameter in the URI (since we can't always control header generation). Ω

Scale and Content Fixes

A handful of bug fixes

Fix ParsecScaleX constant from 0.868 to cos(30°). (Reported by Joachim Pfaff)

This has been wrong since the site was created - I must have estimated the number (or it was a typo - it's closer to 0.866) and never corrected it. This unfortunately means that permalinks - which encode a non-scaled x/y - are now slightly off. Given that the coordinate system starts at Reference, this means the farther you get from the center of the Imperium the more the old permalinks will be off.

Fortunately, this isn't far - compare Regina - new permalink, old permalink. Since it's less than a parsec, I'm not going to call on Plan B, which would be to honor old permalinks and tag new permalinks in some way (additional argument, changed coordinate names, etc.).

Fix erroneous inclusion of invalid neighbor subsector labels. (Reported by BeRKA.)

Stupid logic glitch on my part - I was allowing the "neighbor subsector" calculation to wrap around.

Fix subsector name for Zhodane (from Zhdant to Gaval) per Supplement 11. (Reported by Thomas Jones-Low.)

Dunno where "Zhdant" came from as the subsector name - probably an older sector file. But it's now corrected, per Supp 11. Ω

IE problems?

Long time user Alex Ingram reported a few months ago that the map tiles weren't fully loading for him in Internet Explorer.

I finally had a chance to put together a prototype page that reduces the number of map tiles loaded at once, which may address this problem. If you've experienced this, try the following URL and let me know if it improves the experience for you:

http://www.travellermap.com/index_pool.htm

(NOTE: That URL will go away at some point so don't get used to it!) Ω

Traveller Map in Second Life

Okay, this is pretty sweet.

About a year ago I took advantage of Second Life's "Parcel Media" support to build an in-world map browser of TravellerMap.com in SL. This basically just sets the media URL of a parcel (a chunk of land) to a map URL, and built an object that is textured with that media URL, along with controls to pan and scale the map. Here's what I came up with:


(I'm that attractive sea creature, by the way.)

Today I got a link from Corro Moseley pointing me at another in-world build by Daden Limited:


I believe it supports multiple map sources, not just TravellerMap.com, and wow is that integration nice. Look, look! I'm standing on Utoland! Look at the text board in the upper left corner - it's showing the RSS feed from this blog, and you can click to read articles! Ω

JSONP and XSS

Allen Varney asks:

...doesn't this functionality leave the map site open to -- at the very least -- cross-site scripting (XSS) hacks? The whole procedure sounds quite insecure.

Short answer: no (but read on)

But it's an excellent question, so let's analyze the potential security vulnerability.

First off, Wikipedia has a reasonable Cross Site Scripting (XSS) overview.

The short version is that a vulnerability in some site allows an hacker to add content that, when viewed by a victim, executes the hacker's code using the victim's data.

For example, let's say VulnerableForum.com allows evil hacker Eve to post arbitrary script code. When victim Alice visits the site, the web page loads and Eve's code can execute within the context of VulnerableForum.com. That means it could do things like make forum posts in Alice's name, change Alice's password, modify Alice's profile (perhaps to include additional copies of Eve's code, turning this into a viral worm), and so forth.

The Wikipedia article lists several variations of this beyond simple persistent content modification, e.g. Eve sends Alice a URL to VunerableForum.com that includes parameters which induce bugs in the forum software, allowing code injection.

The "classic" form of XSS was what led to the Same Origin Policy (SOP). In the old days, Eve's web site (EvilHacker.com) could load up AlicesBank.com in an IFRAME. If Alice visited EvilHacker.com, the IFRAME would load AlicesBank.com - and possibly log in automatically. The scripts from EvilHacker.com could then reach into the IFRAME and manipulate the now-authenticated bank pages to steal money. In response to this, browser makers implemented the SOP, which means that the scripts can't reach into the IFRAME if the content is from a different site.

This SOP has been extended to all web technology - Flash, AJAX calls, and so forth. Unfortunately, this means that sites that want to cooperate - say, your site and TravellerMap.com - don't have a way to share data. Flash exposes a cross-domain mechanism (where receiving second site can explicitly allow requests from requesting first site). For JavaScript there are some cross-domain-enabling proposals. But for now, JSONP is a workaround. JSONP requires that both sites cooperate – the requesting site must specify a JSONP parameter in a URL request, and the receiving site must understand the JSONP parameter and create an appropriate response.

So…. back to the question of security.

• Does accepting JSONP requests expose TravellerMap.com to XSS attacks? No – the site does not interpret the content of the JSONP parameter beyond %-decoding. It is simply pre-pended (along with "(" prefix and ");" suffix) to the data being returned.

• Does using JSONP requests expose your site to XSS attacks? Ah, there’s the rub. By making JSONP requests you are allowing TravellerMap.com to inject script and data into the execution context of your web pages. Let’s analyze how this could be exploited:

(1) TravellerMap.com could THEORETICALLY add malicious script to the JSONP results. In that case, instead of emitting "callback(…);" the site emits "make_forum_post(…);" or something. Since the script is executed automatically (via the JSONP mechanism) and the data can’t be filtered (it appears as a script tag which executes the content, not data you can deserialize with paranoid JSON parsing code), there is no simple defense against this. If TravellerMap.com is compromised (or I turn to the dark side…) then your site is vulnerable.

Note that this vulnerability is restricted to XSS behavior, that is, users of the site would have code executed in the context of the web site. This doesn’t allow arbitrary code execution on the victim’s machine (it’s still in the web page sandbox), or on the web server (it’s all client-side). So this isn't a "pwn'd your machine" exploit, but it is a (theoretical) "pwn'd your account" exploit.

Also note that sites like Flickr expose JSONP APIs with the same risks, so it’s not a flaw in the design of the TravellerMap.com API. Either you trust the site you’re calling into with JSONP or you don’t.

For the paranoid (i.e. you want to use the TravellerMap.com JSONP APIs, but don’t trust the site to remain exploit-free), one mitigation would be to sandbox any use of the JSONP APIs. For example, your main site might be mytravellerforum.com, and create a sandbox.mytravellerforum.com subdomain that doesn’t do anything with users' forum accounts. And of course, if you are implementing server-side functionality, you can call directly into the non-JSONP versions of the APIs, in which case you’re parsing the data yourself.

(2) TravellerMap.com could THEORETICALLY expose a vulnerability that allows JSONP requests to include arbitrary content.

Here’s how a hacker might exploit that:

• Your site exposes a "make a map for sector X" form. The user can type the sector name into a form, which causes a JSONP request to TravellerMap.com
• A hacker crafts a URL which makes your site make that request automatically (due to the architecture of your site, possibly a redirect). The URL includes the sector name as: "); do_evil(…); void("
• Your page turns that into a JSONP request
• The TravellerMap.com site THEORETICALLY blithely outputs that as part of a valid response, un-escaped
• Your site executes that script with the do_evil() content (which, say, makes a forum post)
• The hacker posts this nasty URL to a forum. Any user that clicks on the link ends up with do_evil() running within their authenticated context.

It’s a bit convoluted, but that’s how these XSS attacks happen. A further THEORETICAL vulnerability would be if the TravellerMap.com site allowed users to post arbitrary data which could then be retreived by a third-party site, but it does not. (No submitted data is retained by the site beyond the lifetime of the request.)

So how to mitigate it?

• Sanitize user input on your site – don’t make arbitrary requests to external sites
• Ensure JSONP logic exists in a sub-domain sandbox (see above)
• Perform your own security audit – try the TravellerMap.com JSONP-enabled APIs and send test data. To the best of my knowledge, all data from successful requests are properly escaped (user data would appear as strings within JSON data) and errors are returned as 404s (the scripts should not execute).

Again, the same issues exist with any JSONP API - you must trust the site you're calling both to not return malicious scripts intentionally and to be hardened against vulnerabilities that would allow someone to cause malicious script to be returned.

So... an excellent question with a non-trivial answer. Feedback, as always, appreciated! Ω

SEC/MSEC go JSONP

You can now slap a JSONP parameter to SEC and MSEC calls to get data in cross-domain-friendly format.

Add something like this to the code in your page, triggered (for example) after the user clicks a link or fills in a form field:

   var sector = "Spinward Marches";
   var url = 'http://www.travellermap.com/SEC.aspx' +
       '?q=' + encodeURIComponent(sector) +
       '&jsonp=myfunction';
   var script_tag = document.createElement('script');
   script_tag.setAttribute('src',url);
   document.body.appendChild(script_tag);

This adds a new <script> element on the fly, filled in with "source code" by TravellerMap.com. The script it generates will look like this:

    myfunction("# Spinward Marches\r\n# blah blah\r\nRegina    1910 ...";

The script will run immediately when it is done loading. So you add a function called "myfunction" (or whatever) to your code and it will be called with a whopping huge string containing the sector data, ready for your parsing needs. Ω

JSONP - It's what's for breakfast

Good news, everybody!

I've added JSONP support to the data APIs (the image APIs don't need it). JSONP allows web pages living on your sites to call APIs on the TravellerMap.com site without any server-side work - it's all in the JavaScript.

More details: JSONP in the TravellerMap.com API Documentation

Here's a short introduction to using JSONP from jQuery which is my favorite JavaScript framework. (You'll note that I don't use any frameworks on the TravellerMap.com site; I was loathe to touch them when I started, and the site was a grand experiment in building everything from scratch. But I digress...) Ω

Spinward Marches Data Update

Despite numerous updates to the bulk of the Imperial data (thanks to the CotI cleanup crew), the Domain of Deneb has suffered in comparison. There has been so much attention paid to this area that there are multiple updates and contradictory canonical and quasi-canonical publications (Supplement 3: The Spinward Marches, The Spinward Marches Campaign, MegaTraveller Journal, Regency Sourcebook, etc). Of course, between the Second Survey (1065) and Rebellion (1116-) there was also the Fifth Frontier War (1107-1110) that redrew borders. So even if you set your campaign on the eve of the Rebellion (not coincidentally the end of the Classic Traveller era and the branch point with the GURPS Traveller alternate timeline) - which is ostensibly the era of my map - it's tricky to get the data just right.

A few weeks ago I sent email to Jerry R. Mapes asking if I could include his cleaned up Spinward Marches data in my site. He granted permission, with a warning that there was additional cleanup to do and that his failing health precluded spending time on it, but that he was optimistic for the future. Sadly, reality intervened, and Jerry passed away a few days ago. (

I've taken his SM 1105 file and made some further corrections by comparing it with other extant data files to turn up anomalies, and set the allegiances to Post-5FW which match the borders on my map.

Here are the specific changes:

• 0605 name "Algeblaster" --> "Algebaster" (per S3:SM, RSB) - this is consistently mis-typed in SEC files, but is consistently "Algebaster" in print.
  
• 3228 name "Fen's Gren" --> "Fenl's Gren" (per S3:SM text) - the alternate "Fen's Gren" name appears on the S3 map and in SMC and RSB. I have no particular attachment, but I saw no big reason to deviate from S3:SM
  
• 2125 pbg "725" --> "723" (per RSB) - probably just a typo
  
• 2519 name "Plannet" --> "Pannet" (per S3:SM, RSB) - another consistently mis-typed name in SEC files, but consistently "Pannet" in print
  
• 0234 name "Andory" --> "Andor" (per SMC, RSB) - this is contraversial. In S3:SM this "Andory" in both the data and map but later sources use "Andor". As this is a fairly well-known world (one of the few multi-world Droyne states in Charted Space) I kept "Andor".
  
• 1110,1209,1210,1311 alleg --> "Fa" - the Federation of Arden worlds, post-5FW
  
• 1324,1325,1522,1523,1524,1525,1526,1529,1626,1627,1628 alleg --> "Bw" - the Border Worlds, post-5FW
• 0236,0336 alleg "Im" --> "Dr" - S3:SM left these as Imperial, but later sources annotate these as trade code "Dw" (Droyne world) or allegiance "Dr" (Droyne). Again, since these are Significant in Charted Space, I decided to make them stand out on the map.

As always, comments appreciated. Ω

Stellar Data

A week or so ago I slipped out a file format page, adapting Marc Miller's article in Challenge #26 describing the first standard sector data file format. It's pretty bare bones at the moment - just what's in the article so it is preserved for posterity - but I plan to grow this over time to document other sector data file formats that have appeared over the years. Call this "Version 1.0".

(Honestly, posting it was inspired by site users wondering what the various base codes in the data meant. But everyone seems to love file format discussions...)

Then, inspired by Yet Another Thread on sector data file formats on CotI I decided to finally tackle stellar data.

• Stellar data now output by SEC.aspx API when present in source data. The following grammar is used:

// Basic:
//   system     ::= star ( w+ star )*
//
// Extended: (Malenfant's Revised Stellar Generation Rules)
//
//   system     ::= unit ( w+ companion )*
//   companion  ::= near | far
//   near       ::= unit
//   far        ::= "[" system "]"
//   unit       ::= star | pair
//   pair       ::= "(" star w+ star ")"
//
//   star       ::= type tenths w* size main?
//                | dwarf
//                | unknown
//   type       ::= "O" | "B" | "A" | "F" | "G" | "K" | "M"
//   tenths     ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
//   size       ::= "D" | "Ia" | "Ib" | "II" | "III" | "IV" | "V" | "VI" | "VII"
//   dwarf      ::= "DB" | "DA" | "DF" | "DG" | "DK" | "DM" | "D"
//   unknown    ::= "Un"
//
//   main       ::= "*"
//
//   w          ::= " "

• "Un" in stellar data is from Mendan 0221 in Challenge #46 (by Mike Mikesh). That could be a typo, but I'm interpreting it as "Unknown" (mysteries abound!). Note that the world is an Amber zone, so it's a navigational hazard at least!
  
• Like other SEC.aspx output, the data is normalized - that is, it's been parsed and then re-output. In some cases this may filter the data. You get what you pay for. In particular, although Malenfant's revised stellar generation data is now consumed by my site, only basic star data is output. Anyone have a link to Malenfant's rules?
  
• SEC.aspx output now has a sector header, similar to the GEnie data. The field lengths are NOT guaranteed to remain fixed, however. Consumers that rely on fixed width fields (rather than Regular Expression or Grammar-based parsers) should parse this header to determine the field lengths.
  

 1-25: Name
27-30: HexNbr
32-40: UWP
   42: Bases
44-68: Codes & Comments
   70: Zone
72-74: PBG
76-77: Allegiance
79-98: Stellar Data

• I tidied up some bogus stellar data: Night (Core 0839) "K8 VI M4" to "K8 VI M4 D" (presumably a truncation); and Tender Mercy (Ley 0314) "2 V A6 D" to "K2 D M6 D" (ditto); in both cases I used older GEnie data as the source
• While I was there, I fixed a couple of O/0 (oh/zero) typos: Kaskar (Vland 1933) stellar "MO V K6 D" to "M0 V K6 D", and Zdienjbats (Far Frontiers 1801) PBG "BO4" to "B04". The latter actually inhibited the world from showing up on the map - oops!

That's it for now! Ω

Two Cool Maps

Two non-traditional renderings of some of our favorite subjects.

First up, a Traveller subsector, created and illustrated by Merxiless over on CotI:

http://www.travellerrpg.com/CotI/Discuss/showthread.php?t=18839

Second, the Milky Way... in logical "subway map" form:

http://arbesman.net/milkyway/

(When we moved back to San Francisco a few years ago we noted that it the light-rail Muni lines finally had "logical" maps - just like a real grown-up city!) Ω

Mismatch Resolved (For Now)

I've settled on a solution to the galaxy scale mismatch discussed in the previous post.

I analyzed the Mikesh map and, while the horizontal/vertical parsec ratio is only 0.9, that's closer to the actual ratio than 1.0 which is the ratio of the Linehan map.

So I've decided to keep the Mikesh map as the primary data source. The galactic structure is now scaled to fit it, which means the Galactic Rifts line up. The change is subtle enough to be pretty much unnoticeable unless you zoom in to where the Core Route and the Galactic Rifts line up - then they are off by several sectors. But honestly, these were wonky anyway.

BeRKA suggested dropping some of the Core Route sectors, but they actually have route metadata winding through them. Honestly, I think they're mostly just a "cute" addition to the site and don't take them particularly seriously, but enjoy having them. So I might as well keep them intact.

By the way, the horizontal/vertical parsec ratio is noticable in Classic Traveller material as well. If you compare the shape of the Imperium presented in the Atlas of the Imperium (by, say, photocopying each page and laying it out like a poster... not that I ever did that...) with the shape of the Imperium as presented in the Alien Module maps you'll see that it's "squashed" in AotI. This is because the AotI-style maps use square hexes. The "Atlas"-style rendering on the site uses rectangular hexes. I believe this "squashing" infected the DGP dotmaps as well (in Vilani & Vargr and Solomani & Aslan). Ω

Galaxy Scale Mismatch

Hrm... my two sources of data for the Traveller galaxy structure don't quite equate, leading to fairly dramatic mismatches.

If you measure the Local Arm's girth at the Ray 0 i.e. through Reference (Core 0140) on the detailed map from Security Leak by Mike Mikesh, you get a distance of 1600 parsecs. If you measure the distance on the detailed map by Clifford Linehan - which he used to construct the Zhodani Core Route - you get a distance of 1760 parsecs.

Composite of the two maps.

That's about a 10% difference... and it's going to bother me. I dug a bit further and it looks like the Security Leak #5 map is the original source, per this conversation between Marc Miller and Clifford Linehan. Mr. Linehan took Mike Mikesh's original, scanned it, cleaned it up, and handed the results back to MWM who took it under the FFE fold. This would indicate that either Mr. Linehan corrected the size (to fit known dimensions of the galaxy) or accidentally scaled it up. (Charted Space doesn't quite line up either.)

Since Traveller parsecs are based on a hexagonal grid, it's actually easy to introduce an error of around 14% - hexes pack more tightly horizontally than vertically, with a ratio around 0.868. This is factored in when I map from image-space to world-space (and you'll see residue in the API). Here's a sample - the red square is precisely 10 parsecs tall, but more than 11 parsecs wide - yet it's a perfect square if you count the pixels.


If I had to guess, I'd say that one of the two galactic-scale map authors was unaware of this, and and used a horizontally-biased parsec scale for determining the number of sectors between Charted Space and the galactic core.

Bleah. :( Ω

That article on rifts from Security Leak fanzine was too good to pass up, so I've incorporated Mike Mikesh's speculation on the extent of the local rifts. Check it out:


Rift rendering using vectors has been dropped, and it now relies on a bitmap - this gives softer edges which IMHO is an improvement. If you zoom out the rifts gradually fade as they become insignificant relative to the overall Galactic structure. If you zoom in they fade in, then disappear at the same point where the map stops rendering "background" stars - now at 4 pixels/parsec. In between they're quite pretty - and look somewhat like an absorption (or "dark") nebula.

The effect is present but not particularly visible in non-Candy styles as well, most notably now as dark shading in the "Atlas" style which mimics (crudely) the shading of the rifts shown in the Alien Module maps. The edges of the rifts are a bit coarse, and I'll probably tweak them over time.


As always, comments appreciated. Ω

Far Out, Man!

Start at Reference in "Candy" style - and then zoom out. A lot.

Go ahead, I'll wait for you.

Nifty, huh?

Okay, if you're lazy, here's the image:

Well, I think it's nice, at any rate. This is inspired by the latest renderings of the real Milky Way galaxy, such as the one over at the Atlas of the Universe:

(Milky Way image © Richard Powell, c/o Atlas of the Universe.)

However, the TravellerMap site is a map of the Traveller galaxy, not the real Milky Way, so I had to pull out the image editor and build it from scratch. This is based on the Traveller galaxy map first introduced to the site back in 2005, courtesy of Clifford Linehan from his (now defunct?) Zhodani Core Route site, sourced by Marc Miller:

(Traveller Galaxy image © Far Future Enterprises, c/o Clifford Linehan)

There are definite differences between the real and fictional galaxy. For example, in the real Milky Way, Earth's sun is part of the Orion Arm, which is mere spur off of the Perseus Arm, next to the Sagittarius Arm. In the Traveller galaxy, Terra appears to be in the main body of a major arm. The real Milky Way is a distinctive barred spiral, whereas the Traveller galaxy is not notably barred (although I rendered a subtle bar in anyway). In a real galaxy, there are nearly as many stars in the rifts between arms as there are in the arms themselves - the arms are slowly propagating gas density waves that induce more star formation, so they are full of bright young stars. In the Traveller galaxy, the rifts have much lower density, which makes things trickier for the Zhodani core expeditions. I don't have a problem with this difference - after all, space in Traveller is 2D. I view this as a perfectly acceptable simplification for the game universe, and don't attempt to fit it to reality. To me, it's a lot like chess. Real battles between opposing armies rarely take place on a perfectly flat 8x8 grid, but that doesn't mean chess isn't a fun game that teaches real strategy.

To create the image I took the galaxy map (isolated to a white-on-black mask), the pseudorandom stars from the map site, Paint.NET and experimented with various layers, blurs, and mixing functions. The cloudy arms were created by blurring the map, rendering in clouds, then using a twist filter. This had various densities of galactic structure and stars layered on top. The core was generated with several overlapping gradients to get an overall white glow, the rosy core, and the bright bar.

If you zoom in, the "Galaxy" image will gradually fade to the "Nebula" background used for candy-style rendering (c/o Wayne Peters). The only really grody bit is that the local rifts fade in as well, and they have abrupt edges. I'm pondering what to do there. Classic Library Data states:

Situated in the center of the Imperium, Capital's astrographic location has proven of prime importance, as it controls the only gap in the Rifts for thousands of parsecs. Besides being a communications hub, Capital is a cultural center, and educational focus. - Adventure 3: Twilight's Peak (emphasis mine)

The emphasized portion is not present in Supplement 8: Library Data (A-M) and later updates of the Library Data for Capital, possibly because the Traveller universe was more refined. However, looked at on the scale of hundreds of parsecs, it is true that the Imperium - centered on Capital, does control the only large gap in the rifts... if the Great Rift and Lesser Rift are presumed to continue on for a thousand parsecs in each direction.

w00t! Google just found me an issue of Security Leak Magazine where Mike Mikesh analyzes the local rifts in the context of the overall Traveller galaxy - sweet! Well, I guess I know what I have to do next...

(EDIT 2015-10-17 - restored the galaxy bitmap to the one in use circa 2009; the blog post contained a link to the live resource which was replaced so the post had become nonsensical.)

Ω

Data Overview 2009

At the start of 2008 I posted a data overview, showing how much things had changed since 2006. This should probably become a yearly tradition, so here's the official 2009 overview:


Not a whole lot of change. So far as I can tell by doing a "blink compare", at this scale the only differences are:

• Routes in Delphi
• Coreward half of Far Frontiers
• Rework of Kaa G!'kul
• Sector data updates to Theron

Anything else I can plug in, dear readers?

(I used TortoiseIDiff to do the blink comparison. I used a similar technique while doing the Solomani and Aslan Dotmap Reconstruction.) Ω

More search tweaks

Okay, a few more tweaks:

• The handling of multi-word searches is now "Web-like". Multiple words in a search turn into multiple AND clauses. So "so ri" would find Solomani Rim sector.
• You can specify exact: as a prefix to force an exact name match of that term. So "exact:sol" will find only Sol subsector.
• You can specify uwp: as a prefix to match a UWP. (Searching only for XXXXXXX-X remains as a shortcut for a UWP search.)
  
• If you use wildcards, the "prefix search" functionality is turned off. That is, normally "reg" would match "Regina" and "Beta Regilis". "reg*" will only match names starting with "reg"

And you can combine these, for example:

• t* uwp:*f - find worlds starting with T with Tech Level F
• exact:terra uwp:a* - find worlds named Terra with Class A starports

Limitations:

• Searches are performed on specific item data only, not the context of the item. By that I mean: you can't search on "solomani rim uwp:a*" since it would only search for worlds named "solomani" and "rim".
  
• Search results may include alternate languages or spellings that are known to the site metadata but aren't shown. For example, Solomani Rim is known as Kushuggi in Vilani, so "kush*" would find it, although it won't be apparent why.

Ω

Search: Now with UWPs

Has this ever happened to you?

Damn... where did I leave that world?!?! I know it's UWP is A7899B9-B but I can't for the life of me remember where I left it! Well, I'm not sure... maybe it was B7899B9-C or A7899B9-C... ugh...

If so, your days of trouble are over! You can now search for UWPs. Here's how it works:

• By default, search still only looks for names (sectors, subsectors, and worlds), matching starts of words (so "sol" matches "Solomani Rim", "Sol", and "Nowa Sol")
  
• If your search term has the pattern XXXXXXX-X (7-1) the search looks for exact matches of UWPs instead (not prefixes)
  
• You can also make it explicit and use a uwp: prefix on the search to force UWP matching

And for added bonus:

• Wildcard searches are supported, using either the % or * character. They mean the same - match zero or more characters. So you could search on R*g*a to find Regina. Note that searches have an implicit wildcard at the end, so that's the same as R*g*a*

You can combine wildcards with the uwp: prefix as well. The Search API documentation has been documented to reflect this.

A cookie to the first commenter that finds my missing world!

Ω

Search: Better, Faster, Stronger... Geekier

I've taken the plunge - the search feature (and back end of the Search API) is now powered by a real honest-to-Turing database engine. Yes... I've entered the 1970s!

If you were playing with the site for the last hour or so, you may have noticed that search went wonky. As usual, code that worked fine in my staging environment (my laptop) ran into scaling/performance issues when in the production environment - 130k separate INSERT statements took longer than ASP.NET likes to wait. A little fiddling with DataTables and SqlBulkCopy and now a rebuild of the database takes under ten seconds. Hooray!

What you'll find:

• Search is better. Instead of exact word matches it will now do stem matches. So "Sol" will find "Solomani Rim (sector)" and "Sol (subsector)"
  
• Search is faster. Previously, the search was done by creating an in-memory hashtable-based index that could be disposed of at ASP.NET's whim. So the first search on a cold index would take >10 seconds; subsequent searches would be faster... until the server decided to reclaim memory. I don't believe my hosting provider executes the site across multiple hosts, but that's now feasible at least.
  
• Search is stronger. The database can be rebuilt in a few seconds from the raw data files (and ginormous metadata map) but that will only be necessary on data updates.

Now, all that said...

• It's not going to give any additional result data back just yet, nor allow searching on other fields. The outstanding request - that should now be easy to service - is to allow searching by UWP. I have the data ready, I just need to write the glue, but I'm out of time for tonight.
• The results are fairly arbitrary - matching sectors, matching subsectors, then matching worlds - and a max of 20 results total. Previously that wasn't a problem, but with the looser matching it could be less than idea. Feedback?

What else do you want? What problems have you noticed? Ω

It's Just Not There

I was pondering the X-Boat route from Tenalphi to Strouden in the Spinward Marches - which, as everyone knows, is 5-parsecs long despite X-Boats being J4 - and settled on an explanation IMTU.

Spinward Marches 2127 doesn't exist.

Jump Space goes non-Cartesian for that parsec. You can't jump to that hex. Jump distances measured across that hex are one parsec shorter than they would appear to be. It's like... oh, I don't know... someone cut out that hex and stretched the map around it in to fill in the gap.

Now... who could do a think like that? And why would they want to erase an entire hex in the Spinward Marches? Ω