Okay, here's some further thoughts based on having gotten the program working for myself, and your responses here.
In terms of usage pattern, I'm not likely to run this on the same region over the course of months, and I'm not likely to use it extremely often in general, but in the process of exploring this region, I am likely to run it many times in a row (with, say, slightly different start and end points). And I'm likely to do that again at some point in the future, when I encounter another interesting but tricky gap or fringe region. As such, I'd be hesitant to tell a prospective user like myself that the only good way to use the tool is to download a multi-GB file first. Far better experience if it can grab what it needs (even if that isn't super speedy the first time) and cache it for future runs on the same region.
I respectfully disagree - I think the people who most need this kind of tool are the fringe explorer types. For getting around the galaxy in general, something like Spansh's neutron router works great, and even the in-game router is adequate most of the time. Where things break down is in the sparse case, when the mean separation between stars becomes comparable to the jump range of the ship. The in-game plotter stops working because it won't plot through synth jumps, and it won't make large detours to find its way around local gaps. And the online routing tools assume you can use the plotter to find your way to the next waypoint. Meanwhile explorers like me can see in EDSM that a given destination has been reached, but you can't tell if it's accessible in your ship or just some extreme jumpaconda build. Most of the galaxy hasn't been sufficiently explored for routing with EDSM data alone to make sense, but the fringes are different: dedicated perimeter explorers like Alitnil actually have plotted a great deal of the outer fringes. Using the VisitedStarsCache dump currently being discussed in another thread, I was able to see that in the region I'm looking at now, probably over 99% of stars in the area are already in EDSM.
In terms of usage pattern, I'm not likely to run this on the same region over the course of months, and I'm not likely to use it extremely often in general, but in the process of exploring this region, I am likely to run it many times in a row (with, say, slightly different start and end points). And I'm likely to do that again at some point in the future, when I encounter another interesting but tricky gap or fringe region. As such, I'd be hesitant to tell a prospective user like myself that the only good way to use the tool is to download a multi-GB file first. Far better experience if it can grab what it needs (even if that isn't super speedy the first time) and cache it for future runs on the same region.
Maybe less important for now. Having used the tool, it seems acceptably fast for the intended case of a sparse region with only a few thousand stars to consider. I didn't realize until I saw it in action that you aren't exploring the entire graph, but stopping on the first acceptable solution and shuffling a few times to optimize stochastically. Might be worth eventually adding the option to pick different routing algorithms for harder cases, and/or using Numpy to vectorize just expensive portions like the bulk distance calculations.
In terms of development priorities, I think my two highest would be 1) a better user interface, and 2) better use of the EDSM API (namely reliability and cacheing). I'm already knocking up #1, since it bugs me greatly to have to modify a source file to use a program. Python has a great built-in library for doing command line argument parsing. So if you don't feel like doing that, I'll send you a PR in a few days. I might make some progress on #2 as well, just in the course of debugging why it sometimes fails.
.
