Determining the region of a system

[Orvidius]

I've written out an SVG of my region mapping (which seems to be accurate and is taken from the EDSM image, so only contains coordinates for that) overlayed with 10million systems from the galaxy. It feels to me like my conversion of galactic coordinates to image coordinates and the scaling are both off so I might have to revisit that.

Be warned this SVG is nearly 1GB in size: http://downloads.spansh.co.uk/regions.svg

Awesome, I'm pulling the SVG now, but I'll have to probably look at it in more detail later.

I could probably try to pull out the vector map for my region borders too. Haven't tried doing that in Photoshop yet though. But of course, as I said earlier, they were hand-placed based on FDev's imagery. Yours might be better, I'm guessing.

 

[Orvidius]

I could probably try to pull out the vector map for my region borders too. Haven't tried doing that in Photoshop yet though.

Looking at mine, photoshop wants to try to create closed shapes by adding its own lines to it. Ugh. It would probably take some work to clean it up.

 

[Orvidius]

Be warned this SVG is nearly 1GB in size: http://downloads.spansh.co.uk/regions.svg

FYI, it looks like it zips down to about 73 MB, in case you want to do that.

 

[Romeo India Charlie]

I'm working on something here but I want to clarify the objective to be sure I'm doing something useful. What we want to achieve is getting the sector name as a function of a system name, correct? Example f("Sol") = "Inner Orion Spur" or f("Sagittarius A*") = "Galactic Centre".

 

[Redfox]

I'm working on something here but I want to clarify the objective to be sure I'm doing something useful. What we want to achieve is getting the sector name as a function of a system name, correct? Example f("Sol") = "Inner Orion Spur" or f("Sagittarius A*") = "Galactic Centre".

Basically yes, although the input would not be the system's name, but rather its X-/Z-coordinates.

 

[Orvidius]

From the info above it seems clear, but has it been verified that the borders are independent from they Y-axis? Theoretically, the borders could be based on spheres (like the permit-locked areas) which would require a different approach.

I think it's probably at least 99% certain that the Y-coordinate doesn't matter, but I don't know if anyone has actually verified that experimentally. I haven't, personally, but maybe that's worth doing. Thankfully the math won't change much if this is the case. The "distance from center" polar coordinate bands would just have to do a 3D pythagorean distance instead of 2D, which thankfully is an almost identical equation.

 

[marx]

I'm working on something here but I want to clarify the objective to be sure I'm doing something useful. What we want to achieve is getting the sector name as a function of a system name, correct? Example f("Sol") = "Inner Orion Spur" or f("Sagittarius A*") = "Galactic Centre".

Yes, but sectors and regions are two entirely different things. You meant regions there. (If you don't know what the difference is, see the EDAStro interactive galaxy map, and switch between Sectors and Regions to see which is what.)

I think it's probably at least 99% certain that the Y-coordinate doesn't matter, but I don't know if anyone has actually verified that experimentally.

I did, both via the galaxy map just today, and earlier by travelling up and down below a specific region border, looking to see if a certain bio type could be found in the next region or not. In both cases, it seems only x and z were relevant, I never crossed regions by going higher or lower.

 

[Orvidius]

So I went back and looked at my in-progress images from when I first put together the region boundary overlay. It's not an FDev image I worked from originally, but rather one that CMDR Qohen Leth had traced first, and then apparently that's what I used as the basis for mine, retracing it again into a higher resolution. But apparently I made tweaks since it doesn't line up exactly in some places, so I probably compared against other images later. I wish I could remember better what I did.

 

[Romeo India Charlie]

Yes, but sectors and regions are two entirely different things.

Yes, I was using the terms interchangeably and I shouldn't. Thank you for clarifying. I'm in fact focusing on regions. I'm trying to run a quick test to see if I can determine region of system and region of (x,z) coordinate. It's all bitmap based so it will be as good as the resolution of the bitmap but a good place to start. I'll be using Orvidius image to create a bitmap. If I'm able to do that I should be able to create the remaining functions and offer some sort of a working prototype.

EDIT: Since I'm at it, I'll explore another idea...

Another possibility is to have classifier but I don't know if we have good enough data to support that. In principle, if we have a dataset with region, x and z for each known system, we should be able to have a predictive model that would return region of new observations based on x and z. There are many issues with this approach but the one that I'm most concerned with is data quality and size. Since our only two predictors would be x and z, we would need a lot of points near to the edges. With that we can try some algorithms to create models.

If anyone knows of such dataset, let me know, I can work on such an approach easily with the right dataset.

 

[Orvidius]

I think it's somewhat safe to work from the assumption that all of the straight edges are intended to point to the same center point, and that all of the curved edges are circle segments also centered there. I think the lack of precision in all of our border maps is an artifact of transferring them from various sources, including the maps that FDev provided early on, and the in-game map lines also being an approximation.

However, it's also still possible that these things don't perfectly line up with the same center point, if Fdev did a bunch of manual data entry for region borders, for instance. And it's also possible that the curves aren't actually curves, but approximations via straight line segments, or that the curvature isn't perfectly circular. I doubt these are the case though, since simple polar "distance and azimuth" from the center would be the simplest calculation for FDev to have used, which could make our life easier as a result.

But for our purposes, we can probably get reasonably close to accurate if we can get good coordinates for all of the vertices / corners, and then extrapolate the center point accordingly. The problem lies with getting people to fly out to all of them and bounce back and forth through a few systems at the region transition, to get the coordinates to be as precise as possible. Until then, we can only approximate it.

 

[Romeo India Charlie]

Well, how precise do we want to be? Even a classifier with 99.9% accuracy on multi million rows of data would not survive manual edits from FDev, assuming such edits would occur in border regions.

 

[Agony_Aunt]

This is what I see with my eyes closed when I snort meta-alloys.

That's not going to work unless you have a connection with Harmony by burning some Lerasium.

 

[Orvidius]

So I went back and looked at my in-progress images from when I first put together the region boundary overlay. It's not an FDev image I worked from originally, but rather one that CMDR Qohen Leth had traced first, and then apparently that's what I used as the basis for mine, retracing it again into a higher resolution. But apparently I made tweaks since it doesn't line up exactly in some places, so I probably compared against other images later. I wish I could remember better what I did.

And, then I found the FDev image I worked from. Looks like I did tweak based on that, so I kinda used both.

Well, how precise do we want to be? Even a classifier with 99.9% accuracy on multi million rows of data would not survive manual edits from FDev, assuming such edits would occur in border regions.

That's true, and we can't assume we'd ever hit 100% anyway. I just know that my current mapping could be off by a few hundred lightyears in some places. Until we have more precise coordinates, it's probably the best I can do (that colorized region mapping I shared earlier). It sounds like Spansh is pretty happy with his borders too.

 

[Romeo India Charlie]

That's true, and we can't assume we'd ever hit 100% anyway. I just know that my current mapping could be off by a few hundred lightyears in some places. Until we have more precise coordinates, it's probably the best I can do (that colorized region mapping I shared earlier). It sounds like Spansh is pretty happy with his borders too.

I'm digesting your PNG and I think the best I could do is just to make the process a bit more direct. The problem I'm finding is that an increase in resolution will just bloat memory.

I'd like to try the machine/statistical learning approach but I don't think we have the data. I fully agree that only getting data of vertices and edges would make a difference. We would still need quite a number of rows at vertices and edges to have a good model though.

 

[Sysmon]

Yes, using Raxxla as the reference point should make everything else fall into place nicely.

S

 

[MattG]

I had some time earlier, so I picked 3 points I believe to be on the same circle and attempted to use the Galaxy Map again to pinpoint the coordinates for crossover. For most of the coordinates, I think I'm within +/- 0.2 LY but the X for one of them I was only able to narrow down to +/- 1LY. With these coordinates, I pinpoint the center as around 400.48, 26958.46.

There are a few more points on the same circle I will try and pinpoint, and see if they all agree. I also need to choose a different circle and see if that produces the same results. This also doesn't account for the jagged-ness, but it's a start and more readings will help pinpoint further.

(I also learnt today there are multiple, different centers of a triangle.)

 

[Spansh]

So https://downloads.spansh.co.uk/regions2.svg looks much better, it turns out I'm an idiot. The image I was basing my calculations off was 2048x2048 not 1900x1900. Regions on my site should get better now, though still inaccurate for all the reasons we've been talking about.

 

[Lance 'Spacecat' D.]

If I can pipe in, I helped Spansh by getting as-precise-as-possible coordinates around Temple, zipping around the galmap. From my finding those points I observed the following:
-Galactic region edges use 'cubes' for sure, In temple those cubes looked to be about 49 light years to a side, give or take a fraction of a ly. (I got that number by going around the cube at one pointed area of the temple region)
-Vertical coordinate didn't matter. I often went high and low hundreds of lightyears and the boundary of the galactic region stayed reliable.
-I'm looking at a 'cube' in the northeast corner of the galactic center (region 1). Upper edge is marked by...
EOR CHRUIA FV-N C20-1724 (3607 : 99 : 28007.7) at the top
EOR CHRUIA ZO-I D9-8054 (3603 : 98 : 27958.7) at the bottom
So that's 49 light years top to bottom, confirmed the same in temple and in galactic center... Accuracy within a tenth of a lightyear. (Thank you high star density)

From this and the curvature of the regions, my guess is FDev took a circular coordinate map set against the center of the galaxy, resolved it to a 'pixel' map with a resolution of around 49 light years, then slammed said map atop the galaxy to give a region number to each star.

Soo, if you guys use a circular coordinate system we'll have a 'fairly good' result that can break around the edges.
If you guys use a 'pixellated map' to figure regions, it'd need a resolution matching the 49 light years pixels that apparently Fdev was using.

(For the record, here are the coords I got for Temple, all are 'just inside temple'. I didn't fly to those stars so some aren't in EDSM)

Spoiler: Temple coords

 

[Orvidius]

Huh, what a strange resolution to choose. The image map I'm using has 10 ly to the pixel (similar to the A-mass boxels), so it's already a higher resolution, but of course it could use a lot better calibration in order to match against individual systems. Sadly, along the edges it would probably need calibration all along those lengths in order to be accurate. I know I won't have the time to trace them out in-game and verify them to that degree, so we may just have to settle for an approximation, knowing that the results are dubious at the edges.

 

[Spansh]

Huh, what a strange resolution to choose. The image map I'm using has 10 ly to the pixel (similar to the A-mass boxels), so it's already a higher resolution, but of course it could use a lot better calibration in order to match against individual systems. Sadly, along the edges it would probably need calibration all along those lengths in order to be accurate. I know I won't have the time to trace them out in-game and verify them to that degree, so we may just have to settle for an approximation, knowing that the results are dubious at the edges.

It's a little disheartening that fdev hasn't waded in on this. It would be nice if they could clarify what the actual situation is and, ideally what their actual plan was intended to be.

I'd be quite happy to write them some code which could calculate the region based off polar coordinates around Sagittarius A* (which I'm guessing was their actual plan) which would probably not be much more expensive than their current (apparent) bitmap check, especially with some sensibly chosen precalculation and lookup tables.

Hell, you could even calculate a bitmask for 95% of the galaxy and use one of the following two methods:

1 Each mask value is simply a region identifier and the mask for a region is wholely contained within the region with no overlap and gaps inbetween the regions. When a gap is found you revert to calculation via polar coordinates.
2. Each mask value is actually a bitmap (with 42 regions you could handle that with a 64bit unsigned int) and completely contains the region it's in. Where an overlap occurs the values are combined using an OR. Then when there is more than one bit present in the mask you revert to calculation via polar coordinates but you only have to check the regions contained within the mask.

Displaying the mask on the galaxy map is a little more work than putting a transparent overlay on the screen but you'd end up with properly curved edges as you'd simply subdivide more as you zoomed in.