ED Astrometrics: Maps and Visualizations

The issue here is you don't know why they've been deleted. I assume they get nuked because they're invalid (someone manually adding them), or invalid data received through EDDN.

If you're generating output from EDSM data, I would personally use only the EDSM data. I wonder how/what Spansh does.
 
Hi, me again. I'm off Wolf hunting and have a small request: would it be possible to separate out Wolf-Rayets from the 'oddballs' map and display them on a separate map?

Many thanks.
 
Hi, me again. I'm off Wolf hunting and have a small request: would it be possible to separate out Wolf-Rayets from the 'oddballs' map and display them on a separate map?

Many thanks.
Should be doable. I have it added to the list, so hopefully today's run will generate it properly. I'll add it to the website after it completes, probably later today.
 
OK, I have the image available now
That's awesome, thanks so much! What I find really interesting about the Wolf-Rayets is that their distribution appears to be (uniquely amongst the star classes) coded into separate 1 kLY × 1 kLY × 1 kLY cubes, each with their own W-R density. Which leads me to a further totally-pushing-my-luck request...

What would be insanely useful for Wolf hunters like myself is if we could get horizontal (i.e. X/Y axis) 'slices' of the galaxy that show the W-R distribution in each 1 kLY thick 'layer'. There are basically only four layers that matter:
• 1 to 2 kLY (on Z-axis)
• 0 to 1 kLY
• -1 to 0 kLY
• -2 to -1 kLY
[• >2 kLY and <-2 kLY - could be useful for completionists or highest/lowest record seekers, but hardly contain any W-Rs]

And if, say, these 'layer' maps had a slightly higher resolution to them, it would be the perfect tool for a Wolf hunter to identify 'gaps' in a W-R cube, where they might hope to find some juicy undiscovered W-Rs (after cross-referencing against other star classes to check the gap isn't just a permit-locked region).

Anyway, just throwing an idea out there. It would be amazing if you could do something with this, but feel free to ignore.
 
That's an intriguing thought. And that can probably be automatized. How sure can one be that the distribution of WR's is uniform within a cube? Because it all depends on that.
 
How sure can one be that the distribution of WR's is uniform within a cube?
I'm fairly certain that the distribution isn't uniform, but it does appear – by eye – to be at least pseudorandom within each cube. I guess I'm saying if I find a cube that has ¾ high W-R density but ¼ low density (and is not permit locked), then I'm fairly confident there's a good chance of finding undiscovered (in EDSM at least) W-Rs in that low-density region.
And that can probably be automatized.
There is also some interesting potential for a GIS type approach with overlaid data layers, but that would also require each PNG map to be generated as with a transparent (not black) background. I wonder if that is also possible?
 
Chances are that it's based on the 1280 ly sector cubes, and the boundaries are offset a little bit. On the vertical/altitude axis (Y)*, the center boundary is actually at -25, so the slices would actually be more like (from top to bottom):

1255 to 2535
-25 to 1255
-1305 to -25
-2585 to -1305

Let me see what I can do.

EDIT: (*) The ED galaxy follows the annoying game developer convention of using X,Z as the map coordinates, and Y as the altitude.
 
Last edited:
EDIT: (*) The ED galaxy follows the annoying game developer convention of using X,Z as the map coordinates, and Y as the altitude.
Interesting that you should mention this, because for many, it would be equally annoying to suddenly be using z as the vertical axis. Personally, before this, I didn't even consider this wasn't the standard convention. In physics, y is often used as the "altitude" coordinate, or rather, the gravity axis. The reason for this is quite simple: at the very beginning of classical mechanics, you want to do 2D problems, so x is chosen as a horizontal axis, and y is vertical, so that you can have gravity and still stay in 2D. Imagine if the same were "x is horizontal and z is vertical, uhh, let's just forget about y for now". Plus even after you can go into 3D after a couple of lessons, you often want to solve 2D problems anyway.

On a map though, it does make more sense to have x and y as the main plane's coordinates and z as an altitude, but I'd guess that Frontier went with the xz horizontal plane standard because their game engine likely works the same, and mixing the two up when transitioning to the galaxy would just be a source of errors.
 
Yeah, in general mathematics X,Y are of course used for to 2D problems and Z gets added if a third is needed. This has translated into using "Z" as altitude in CAD and 3D modeling software, and works naturally in any map-related applications as well. But the entire games industry has adopted a standard of using Y as the altitude, as an artifact of 2D game engines using X,Y screen coordinates. When 3D games first started getting developed, Z was added as a "depth" into the screen view, and hence X,Z are used for the horizontal plane. However the coordinate system has also adapted after that, since screen coordinates start with Y=0 at the top, and increase downward. But 3D coordinate systems use positive Y values extending upward.

So nothing matches anything anymore. :D
 
Top Bottom