Stellar Navigation Using Network Analysis

Not the author, I found it thru Patrick Durusau's blog: http://tm.durusau.net/

Came here to say this. When i was playing with space cartography like this, back in the late '90s, Hipparcos had just come out, and i was the first person in my little coterie to try working with it. I'd just gone to university, where i had 10 Mb/s ethernet in the computer room, whereas most other people were on dialup, and the multi-megabyte file seemed impossibly vast!

I can't remember the details of what i did with the data. I know i spent ages trying to merge it with the Gliese data to get better names; the Hipparcos dataset just has Hipparcos catalogue numbers, whereas Gliese has cross-references to other catalogues, and traditional names, which makes for much more inviting navigation ("Ah, i can plot a route from Barnard's Star to BD-44826 via Cygnus IV" rather than "HIP-18237 to HIP-8901823 to HIP-77123"). The problem is, though, that Gliese predates Hipparcos, so it doesn't have Hipparcos numbers, and Hipparcos doesn't have cross-references to Gliese. I ended up trying to overlay the proper-motion-corrected positions of the stars in the two datasets and match them up, which was not particularly accurate.

I also wrote some code to generate VRML (remember that?) models of stars and links between them; my puny machine couldn't really render them fast enough for that to be much fun, though.

One of the basic operations in this kind of mapmaking is deciding where to draw the links between the stars; the nodes in the graph are what fall out of the data, but how you draw the links is up to you. The OP used a distance cutoff, which is standard but leads to somehow unsatisfying networks. I hit on the idea of using a Delaunay triangulation (i doubt i'm the first to do this - in fact i think there's an appendix to 'The Mote in God's Eye' which essentially specifies it), which gives much 'nicer' networks, without birds' nests of overlapping links in dense regions of space. After implementing some horrifically inefficient homebrew algorithm for it, i switched to computing it using qhull:

http://www.qhull.org/

I had all this fun in the context of a wargaming mailing list (FTGZG-L, later GZG-L), and had many long and interesting conversations about the subject there. The lists's resident cartographer-in-chief was Nyrath the Nearly Wise, whose site remains the standard reference on the subject:

http://www.projectrho.com/public_html/starmaps/

http://www.projectrho.com/public_html/starmaps/mapindex.php

http://www.projectrho.com/public_html/starmaps/catalogues.ph...

Good times.

Thanks for posting this. I've grabbed those files and will have to run this on it in the future.

Thanks for the information (fascinating!). A gravitational fly-by of Sirius B would be crazy.

Straight-shot trajectory (and/or gravitational assist) would be the simplest way to get the ship there, but other constraints might force one to "stop and refuel":

* Energy needed to maintain life for duration of journey (e.g. hibernation) may exceed what you can store in one "charge" for your ship.

* Instead of 3D trajectory travel, perhaps the energy needed to "warp" or establish a worm-hole is proportional to the distance being travelled.

* Or, perhaps, the reliability and precision of calculated trajectories breaks down after certain distances; forcing a series of "hops" vs. a single trajectory in order to make the journey safe/reliable.

* Time may factor in. You may have enough energy, but perhaps components of the ship can't be expected to operate without error/failure for such long times. In that case, "stopping to refuel" might include expected repairs as well.

All hand-wavy a bit, but interesting to think about.