Building a Galactic Map

[Durakken]

So what I'm doing is building a Galactic Map that increases its scope from 50 ly, to 500 ly, to 5000 ly, to 50000 ly.
At the smallest scope I can include all the stars (2000 of them in 1400 systems), but larger scopes I'm not sure what to cut out/keep.


- O and B stars seem like they wouldn't be useful for anything and as such would be a good thing to drop.
- F and A stars might be ok for mining but not sure how they really rank, especially since it seems that most of their mass is likely to be tied up in Gas Giants and as such seems like they can be ignored. Even though F stars are said to be good candidates for life too.
- G and K stars I think are obvious that they need to be on the map.
- The problem is that Red Dwarfs, M stars, are 1500 of the stars and to me, they seem like you'd want to have them on a map for Mining, if not for the possibility of life.

If we include F, G, and K stars at the 500 ly scope, that's ~300,000 stars. which is way too many imo. So limiting stars by habitability doesn't seem like a good idea.
And then we face the same problem at the 5000 and 50000 ly scopes, because the same rules would produce that many stars times some magnitude higher.

Any ideas?

[waldronate]

Why are you building this map? Is it a static 2D map or a dynamic, zoomable 3-D map?

[Durakken]

It's for a game and a reference for myself for the universe I'm building for this as well.

the stars won't move, nor can you zoom in to see the planets, but you'll be able to click on (visit) a star and see the system with all the planets and stars in that system.
the map itself will be presented as a cube that you can zoom in and out of as well as twist and turn.

[waldronate]

If it's a dynamic map, you should be able to use dynamic filters (depending on how you have the thing set up). You're describing a GUI-based query engine for a database, and (as you have pointed out) those can be tricky when there is a large amount of data. The fun thing about having a dynamic map is that you can (or should be able to) apply filters like "G2 stars less than 20 ly from this star" and so reduce the information overload that way. If you allow metadata for each star (e.g. "Occupied by Empire A" or "Discovered by Empire B"), then you can go further with your searches. Adding in the concept of routes between stars (either for technical reasons or for simple convenience of organization) would give you another way to view things. If you can code visual information like the color and size of system markers by some data (population, number of routes, metallicity, etc.), then you can have even more fun!

edit: I forgot to mention use of Level of Detail techniques. For the base visualization map, you might start with the brightest stars in an area and then add progressively brighter stars as the zoom into an area goes up. These techniques can apply to all of the above ideas, with the system reducing the importance (perhaps to imperceptibility) of systems that don't match the current filter set well.

[Durakken]

What if I said it was a 2d top down map?

[waldronate]

All of the 3D things are eventually squished down to 2D to put them on the screen, but I understand your point. I think it was the original Traveller: 2300 maps that tried to do that sort of thing, but they didn't have a whole lot of stars to deal with (it may have only been a 100 ly radius). If you're not dynamically generating the view, but are instead using a large pre-rendered 2D map, I'm not sure that you're going to avoid clutter. You can do some sort of slippy map thing to get a large effective map with detail in one area. Filtering the data set to pick "useful" stars is, as you pointed out in your original post, going to be a difficult problem and might be best solved by having more than one map to show the different kinds of information that are behind the map's purpose.