Discussion What is the most efficient way to crowdsource the 3D system coordinates

[Harbinger]

Newly mapped stars:

• Beurex (-1.65625, 28.53125, -7.84375).
• G 148-13 (-0.40625, 27.09375, -7.0625).
• Gweir (3.125, 31.75, -11.625).
• LHS 316 (-5.875, 24.40625, -9.34375).
• SZ Ursae Majoris (-13.0625, 21.96875, -13.875).
• LHS 2211 (-12.53125, 24.28125, -21).
• LHS 2191 (-13.03125, 28.3125, -25.5).
• Youdu (-7.84375, 33.875, -26.125).
• LFT 747 (-15.1875, 43.1875, -26.90625).
• LP 62-147 (-20.5, 38.5, -30.3125).
• LFT 679 (-29.8125, 31.53125, -30.21875).
• LHS 2088 (-23.3125, 25.71875, -28.34375).
• LHS 256 (-18, 21.4375, -24.0625).
• LHS 2126 (-19.59375, 22.25, -22.96875).
• LFT 671 (-17.875, 24.09375, -22.71875).
• LFT 668 (-19.03125, 25.65625, -24.21875).
• LHS 3297 (-36.46875, 22.6875, -16.53125).
• LP 9-231 (-42.15625, 25.53125, -19.59375).
• LDS 1503 (-51.78125, 19.90625, -31.71875).
• LDS 1503A (-43.46875, 16.4375, -26.46875).
• Taranis (-52.53125, 18.46875, -28.6875).
• LHS 534 (-58.21875, 11.90625, -26.9375).
• LFT 19 (-56.28125, 7.875, -32.28125).
• BD+69 45 (-58.59375, 9.625, -38.15625).
• Wregoe QA-Q B46-6 (-54.34375, 18.25, -36.34375).

Verification

 

[wolverine2710]

Wow. Quite a list of systems. I know it must have been quite some work.
A suggestion: Would it be possible for your script to automatically generate inserts for TD. That way a simple copy/paste is all what is needed for for example Smacker.

Something else: You've read I assume that RW is willing to help with the frontend stuff. Have you been able to contact him to work things out?

Smacker has 398 coords now, with your 24-25 its about 423. If you keep working that way we don't need to a crowd sourcing effort at all ;-) Perhaps best to also put your list in the TD thread - like you've done in the past....
Well its of the bed for me...

 

[Smacker]

Newly mapped stars:

• Beurex (-1.65625, 28.53125, -7.84375).
• G 148-13 (-0.40625, 27.09375, -7.0625).
• Gweir (3.125, 31.75, -11.625).
• LHS 316 (-5.875, 24.40625, -9.34375).
• SZ Ursae Majoris (-13.0625, 21.96875, -13.875).
• LHS 2211 (-12.53125, 24.28125, -21).
• LHS 2191 (-13.03125, 28.3125, -25.5).
• Youdu (-7.84375, 33.875, -26.125).
• LFT 747 (-15.1875, 43.1875, -26.90625).
• LP 62-147 (-20.5, 38.5, -30.3125).
• LFT 679 (-29.8125, 31.53125, -30.21875).
• LHS 2088 (-23.3125, 25.71875, -28.34375).
• LHS 256 (-18, 21.4375, -24.0625).
• LHS 2126 (-19.59375, 22.25, -22.96875).
• LFT 671 (-17.875, 24.09375, -22.71875).
• LFT 668 (-19.03125, 25.65625, -24.21875).
• LHS 3297 (-36.46875, 22.6875, -16.53125).
• LP 9-231 (-42.15625, 25.53125, -19.59375).
• LDS 1503 (-51.78125, 19.90625, -31.71875).
• LDS 1503A (-43.46875, 16.4375, -26.46875).
• Taranis (-52.53125, 18.46875, -28.6875).
• LHS 534 (-58.21875, 11.90625, -26.9375).
• LFT 19 (-56.28125, 7.875, -32.28125).
• BD+69 45 (-58.59375, 9.625, -38.15625).
• Wregoe QA-Q B46-6 (-54.34375, 18.25, -36.34375).

Verification

Great stuff. I have added those to the TradeDangerous merge queue. Plot updated HERE. 423 Systems!

 

[CMDR Generic EventHandler]

C# implementation.

Hi all, I've been reading this thread and using the information, and I want to give something back, so here is a C# conversion of the py that was provided.

thanks to Snuble and Zebidie

namespace Elite.Dangerous.Tools
{
using System;

public class Coord
{
public double X { get; set; }

public double Y { get; set; }

public double Z { get; set; }

public double Distance { get; set; }
}

public class Trilateration
{
public double[] Trilateration3d(Coord p1, Coord p2, Coord p3, Coord p4)
{
var ex = VectorUnit(VectorDiff(p2, p1));
var i = VectorDotProduct(ex, VectorDiff(p3, p1));
var ey = VectorUnit(VectorDiff(VectorDiff(p3, p1), VectorMultiply(ex, i)));
var ez = VectorCross(ex, ey);
var d = VectorLength(p2, p1);
var r1 = p1.Distance;
var r2 = p2.Distance;
var r3 = p3.Distance;
var r4 = p4.Distance;
if (d - r1 >= r2 || r2 >= d + r1)
{
return new double[3];
}

var j = VectorDotProduct(ey, VectorDiff(p3, p1));
var x = ((r1 * r1) - (r2 * r2) + (d * d)) / (2 * d);
var y = (((r1 * r1) - (r3 * r3) + (i * i) + (j * j)) / (2 * j)) - ((i * x) / j);
var z = (r1 * r1) - (x * x) - (y * y);
if (z < 0)
{
return new double[3];
}

var z1 = Math.Sqrt(z);
var z2 = z1 * -1;

var result1 = p1;
result1 = VectorSum(result1, VectorMultiply(ex, x));
result1 = VectorSum(result1, VectorMultiply(ey, y));
result1 = VectorSum(result1, VectorMultiply(ez, z1));
var result2 = p1;
result2 = VectorSum(result2, VectorMultiply(ex, x));
result2 = VectorSum(result2, VectorMultiply(ey, y));
result2 = VectorSum(result2, VectorMultiply(ez, z2));
r1 = VectorLength(p4, result1);
r2 = VectorLength(p4, result2);
var t1 = r1 - r4;
var t2 = r2 - r4;
var coords = new double[3];
if (Math.Abs(t1) < Math.Abs(t2))
{
// using the second version of the *32 / 32 code.
coords = new Double[] { Math.Round(result1.X*32, 0)/32, Math.Round(result1.Y*32, 0)/32, Math.Round(result1.Z*32, 0)/32 };
}
else
{
coords = new Double[] { Math.Round(result2.X*32, 0)/32, Math.Round(result2.Y*32, 0)/32, Math.Round(result2.Z*32, 0)/32 };
}

return coords;
}

public double VectorLength(Coord p1, Coord p2)
{
var a1 = p1.X;
var a2 = p2.X;
var b1 = p1.Y;
var b2 = p2.Y;
var c1 = p1.Z;
var c2 = p2.Z;

var dist = Math.Sqrt(((a2 - a1) * (a2 - a1)) + ((b2 - b1) * (b2 - b1)) + ((c2 - c1) * (c2 - c1)));
return Math.Round(dist, 3);
}

public Coord VectorSum(Coord v1, Coord v2)
{
var ret = new Coord();
ret.X = v1.X + v2.X;
ret.Y = v1.Y + v2.Y;
ret.Z = v1.Z + v2.Z;
return ret;
}

public Coord VectorCross(Coord v1, Coord v2)
{
var ret = new Coord();
ret.X = (v1.Y * v2.Z) - (v1.Z * v2.Y);
ret.Y = (v1.Z * v2.X) - (v1.X * v2.Z);
ret.Z = (v1.X * v2.Y) - (v1.Y * v2.X);
return ret;
}

public Coord VectorMultiply(Coord v1, double i)
{
var ret = new Coord();
ret.X = v1.X * i;
ret.Y = v1.Y * i;
ret.Z = v1.Z * i;
return ret;
}

public double VectorDotProduct(Coord v1, Coord v2)
{
return (v1.X * v2.X) + (v1.Y * v2.Y) + (v1.Z * v2.Z);
}

public Coord VectorDiff(Coord p1, Coord p2)
{
var ret = new Coord();
ret.X = p1.X - p2.X;
ret.Y = p1.Y - p2.Y;
ret.Z = p1.Z - p2.Z;
return ret;
}

public double VectorNorm(Coord v)
{
return Math.Sqrt((v.X * v.X) + (v.Y * v.Y) + (v.Z * v.Z));
}

public Coord VectorDiv(Coord v, double l)
{
var ret = new Coord();
ret.X = v.X / l;
ret.Y = v.Y / l;
ret.Z = v.Z / l;
return ret;
}

public Coord VectorUnit(Coord v)
{
var l = VectorNorm(v);
if (l == 0)
{
return null;
}

return VectorDiv(v, l);
}
}
}

 

[Chromatix]

I've taken a look at some of the new data.

The results aren't particularly pretty, mostly because the second source of data you linked to provides most of the measurements to a more limited precision than the game itself can provide, and so most of those measurements (generally the ones only given to 0.1 ly) end up being rejected by the script because they don't match the calculated result sufficiently closely. There are also some other validation problems with this data, but these are on the same order as in the first source (which I was already using), and tend to consist of typos.

Incidentally, I have a position for Sagittarius A* which is consistent with all available measurements, but which isn't very precise (uncertainty of a lightyear or so). The uncertainty will tend to be in the angular position rather than the distance, since the distances all match the position to within 1/64 ly. Given the extreme distance of that object, that's a reasonably pleasing result.

Currently, I don't quantise the resulting positions. However, I could quite easily add that.

 

[wolverine2710]

I've taken a look at some of the new data.

The results aren't particularly pretty, mostly because the second source of data you linked to provides most of the measurements to a more limited precision than the game itself can provide, and so most of those measurements (generally the ones only given to 0.1 ly) end up being rejected by the script because they don't match the calculated result sufficiently closely. There are also some other validation problems with this data, but these are on the same order as in the first source (which I was already using), and tend to consist of typos.

Incidentally, I have a position for Sagittarius A* which is consistent with all available measurements, but which isn't very precise (uncertainty of a lightyear or so). The uncertainty will tend to be in the angular position rather than the distance, since the distances all match the position to within 1/64 ly. Given the extreme distance of that object, that's a reasonably pleasing result.

Currently, I don't quantise the resulting positions. However, I could quite easily add that.

I've reread your post a few times but I'm afraid I have to say you lost me. My questions:

1. To whom are you referring to?
2. "mostly because the second source of data you linked to". What do you mean with that?
3. "generally the ones only given to 0.1 ly". What source?
4. What do you mean with "quantise the resulting positions" ?

Could you please elaborate?

In general I thought things were at this point in time progressing rather smoothly and that the calculated coords which are on a 1/32LY grid were reliable. Perhaps I misinterpreted your post but it gives me the feeling we are not as far as I thought and hoped....

 

[RedWizzard]

Incidentally, I have a position for Sagittarius A* which is consistent with all available measurements, but which isn't very precise (uncertainty of a lightyear or so). The uncertainty will tend to be in the angular position rather than the distance, since the distances all match the position to within 1/64 ly.

What did you get for it? The coords I'm currently getting are (25.28125, -19.71875, 25899.96875). That's based on 9 distances (see below) and matches the distances to 0.002 Ly or better. If you've got any other measurements I'd love to see them.
Wyrd 25903.984
LHS 2884 25898.322
h Draconis 25904.006
41 Gamma Serpentis 25877.164
Aulin 25895.313
Ross 905 25907.248
Theta Draconis 25900.135
Tring 25948.393
Keries 25887.457

 

[Chromatix]

Here's a small sample of the output from my resolver:

Only 3 measurements provided for Bidmere
System Culann discovered at [-36.07877643 14.6866846 13.65562459] with 4 samples, precision 0.005406536989986807 ly
Suspect measurement De Bootis to LHS 3080 at 18.1 ly, more likely 18.05081981354284 ly
Suspect measurement De Bootis to LHS 371 at 17.0 ly, more likely 16.959227252672935 ly
Suspect measurement De Bootis to Tilian at 18.8 ly, more likely 18.762243626013607 ly
Suspect measurement De Bootis to Miquich at 17.2 ly, more likely 17.161629634110774 ly
Suspect measurement De Bootis to Miquich at 17.2 ly, more likely 17.15874490412595 ly
Suspect measurement De Bootis to 37 Xi Bootis at 15.7 ly, more likely 15.662907902134908 ly
Suspect measurement De Bootis to Aganippe at 13.1 ly, more likely 13.07406915480006 ly
Suspect measurement De Bootis to LP 271-25 at 10.2 ly, more likely 10.17350461868562 ly
Suspect measurement De Bootis to Zeta Herculis at 17.3 ly, more likely 17.27507653192307 ly
Suspect measurement De Bootis to Coelrind at 14.8 ly, more likely 14.776961197702677 ly
Suspect measurement De Bootis to LP 440-38 at 12.1 ly, more likely 12.080895990118558 ly
Suspect measurement De Bootis to LHS 350 at 17.5 ly, more likely 17.479828341543193 ly
Suspect measurement De Bootis to LHS 355 at 17.6 ly, more likely 17.580135997483623 ly
Suspect measurement De Bootis to Rakapila at 10.9 ly, more likely 10.880564999097473 ly
Suspect measurement De Bootis to Ross 1015 at 14.4 ly, more likely 14.379713236829252 ly
Suspect measurement De Bootis to Wolf 497 at 12.7 ly, more likely 12.68198323825428 ly
Suspect measurement De Bootis to Sigma Bootis at 16.6 ly, more likely 16.583143319280307 ly
System De Bootis discovered at [ -7.45882143 32.63587465 16.98863362] with 22 samples, precision 0.0012042900560622742 ly
Suspect measurement Devi to LHS 2764a at 18.5 ly, more likely 18.46903175208478 ly
Suspect measurement Devi to Wolf 497 at 16.2 ly, more likely 16.175747675907495 ly
Suspect measurement Devi to Ross 130 at 13.0 ly, more likely 12.979748580168529 ly
System Devi discovered at [-10.28277573 52.188727 18.15200676] with 19 samples, precision 0.0015060328581525987 ly

Here you can clearly see the script rejecting a lot of data simply because it is insufficiently precise. One decimal place isn't enough - each such data point has 6.4:1 odds against survival.

My coordinates for Sagittarius A* are [23.460, -15.232, 25899.986], based on 6 samples. I wonder how significantly different from [0, 0, 25900] it really is; the galactic coordinate system is supposedly based on this object as one of the defining reference points (Sol being the other).

 

[TunaMage]

Smacker (or anyone), is there a straightup list of all the actual co-ords we have so far? The trade dangerous list has co-ords re-formatted for your graphic plots, unless I'm mistaken?

I'll try and find some more unknowns, and build up my algorithms a bit further this weekend.

 

[Biteketkergetek]

Smacker (or anyone), is there a straightup list of all the actual co-ords we have so far? The trade dangerous list has co-ords re-formatted for your graphic plots, unless I'm mistaken?

I'll try and find some more unknowns, and build up my algorithms a bit further this weekend.

What graphic plots are you referring to? As far as I can tell they are correct XYZ coordinates. Have a look at the TradeDangerous.sql file. I use them in my map (in which the screen coords are dynamically generated), and they appear correct (actual XZ coords here)

If you have sqlite3 installed (its a single exe/binary), just import this file, and run a select to get them in the format you prefer.

 

[RedWizzard]

I'll try and find some more unknowns, and build up my algorithms a bit further this weekend.

I've found your algorithm to be spot on with those four reference stars (h Draconis, Wyrd, LHS 2884, Keries). But I recommend adding one more reference just for confirmation: it's easy to make a mistake inputting the distances and with your spreadsheet it's impossible to tell that you've made one.

Your algorithm does struggle with bad choices of reference stars but I think that's unavoidable for any algorithm relying on just four references. Adding another reference will also help with this I think.

Finally your algorithm produces less accurate results for several distant stars (Alpha Cygni, Enif, Rigel, Sagittarius A*). Again this is down to the references: I think those four you've chosen are not far enough apart for more distant systems. This probably doesn't matter. If you're interested I can give you the distance data I have for these cases.

 

[RedWizzard]

Update to post #316.

I've collected some extra data to verify a few suspect results from Codec's spreadsheet and to locate some more systems mentioned in his distance data. There was one bad distance in the spreadsheet, affecting SDSS J1416+1348. I believe these 15 systems are correct:

Spoiler

LDS 1503 (-51.78125, 19.90625, -31.71875)
LHS 396 (-9.875, 30.84375, 20.46875)
LHS 457 (-31.75, 16.65625, 15.5)
LP 229-17 (-23.03125, 9.03125, 8.96875)
LP 336-6 (-23.46875, 5.09375, 11.4375)
LP 625-34 (-9.46875, 17.8125, 30.4375)
Marcov's Point (-22.34375, 14.625, 17.65625)
NLTT 47491 (-89, 47.125, -35.25)
OT Serpentis (-11.125, 30.34375, 18.40625)
Polaris (-322.6875, 194.59375, -212.4375)
SDSS J1416+1348 (-0.6875, 27.15625, 12)
Veren's Stop (-12.96875, 21.96875, 20.28125)
WREDGUIA **-Q B46-2 (-98.125, 32.5, -61.1875)
WREDGUIA **-Q B46-3 (-86.25, 31.78125, -61.875)
WREDGUIA ZH-Q B46-3 (-73.375, 26.59375, -55.09375)

TradeDangerous DB inserts:

Spoiler

INSERT INTO "System" VALUES(,'LDS 1503',-51.78125,19.90625,-31.71875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LHS 396',-9.875,30.84375,20.46875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LHS 457',-31.75,16.65625,15.5,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LP 229-17',-23.03125,9.03125,8.96875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LP 336-6',-23.46875,5.09375,11.4375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LP 625-34',-9.46875,17.8125,30.4375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Marcov''s Point',-22.34375,14.625,17.65625,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'NLTT 47491',-89,47.125,-35.25,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'OT Serpentis',-11.125,30.34375,18.40625,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Polaris',-322.6875,194.59375,-212.4375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'SDSS J1416+1348',-0.6875,27.15625,12,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Veren''s stop',-12.96875,21.96875,20.28125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'WREDGUIA **-Q B46-2',-98.125,32.5,-61.1875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'WREDGUIA **-Q B46-3',-86.25,31.78125,-61.875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'WREDGUIA ZH-Q B46-3',-73.375,26.59375,-55.09375,'2014-10-17 10:13:20');

For completeness, the 24 "confirmed" from post #316:

Spoiler

16 Cephei (-108, 30.03125, -42.25)
4 Cephei (-132.09375, 35.5, -27.875)
Achenar (67.5, -119.46875, 24.84375)
Alpha Cygni (-1405, 46.09375, 132.5)
Alphard (138.84375, 88.46875, -73.5)
Austern (-25.15625, 15.34375, 9.375)
Culann (-36.0625, 14.625, 13.8125)
Dziban (-62.15625, 38.46875, -14.3125)
Enif (-536.59375, -363.03125, 236.1875)
Etamin (-132.46875, 74.875, 25.53125)
GD 356 (-50.9375, 44.15625, 7.3125)
Hagalaz (-50.59375, 45.15625, 11.09375)
HIP 103014 (-132.46875, 33.25, -28.5625)
HIP 109479 (-127.5, 29.875, -48.5)
HIP 111494 (-106.9375, 30.0625, -48.4375)
HIP 94802 (-114.59375, 51.40625, -25.90625)
LHS 6354 (-65.28125, 27.34375, -16.125)
LP 180-17 (-56.84375, 37.71875, 12.71875)
Mirphak (-274.96875, -47.625, -422.65625)
NLTT 44050 (-57.46875, 38.8125, -21.09375)
Rigel (385.78125, -360.40625, -682.53125)
Ross 52 (-8.4375, 29.15625, 13.3125)
Taran (-42.5, 45.46875, -3)
WREDGUIA XX-O B47-2 (-116.4375, 55.125, -38.3125)

SQL:

Spoiler

INSERT INTO "System" VALUES(,'16 Cephei',-108,30.03125,-42.25,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'4 Cephei',-132.09375,35.5,-27.875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Achenar',67.5,-119.46875,24.84375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Alpha Cygni',-1405,46.09375,132.5,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Alphard',138.84375,88.46875,-73.5,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Austern',-25.15625,15.34375,9.375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Culann',-36.0625,14.625,13.8125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Dziban',-62.15625,38.46875,-14.3125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Enif',-536.59375,-363.03125,236.1875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Etamin',-132.46875,74.875,25.53125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'GD 356',-50.9375,44.15625,7.3125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'HIP 103014',-132.46875,33.25,-28.5625,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'HIP 109479',-127.5,29.875,-48.5,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'HIP 111494',-106.9375,30.0625,-48.4375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'HIP 94802',-114.59375,51.40625,-25.90625,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Hagalaz',-50.59375,45.15625,11.09375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LHS 6354',-65.28125,27.34375,-16.125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'LP 180-17',-56.84375,37.71875,12.71875,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Mirphak',-274.96875,-47.625,-422.65625,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'NLTT 44050',-57.46875,38.8125,-21.09375,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Rigel',385.78125,-360.40625,-682.53125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Ross 52',-8.4375,29.15625,13.3125,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'Taran',-42.5,45.46875,-3,'2014-10-17 10:13:20');
INSERT INTO "System" VALUES(,'WREDGUIA XX-O B47-2',-116.4375,55.125,-38.3125,'2014-10-17 10:13:20');

I'm going to make a few changes to my tools and then take a look at Harbinger's data.

 

[TunaMage]

What graphic plots are you referring to? As far as I can tell they are correct XYZ coordinates. Have a look at the TradeDangerous.sql file. I use them in my map (in which the screen coords are dynamically generated), and they appear correct (actual XZ coords here)

If you have sqlite3 installed (its a single exe/binary), just import this file, and run a select to get them in the format you prefer.

Thanks, that's the file I was looking for - got myself a bit lost in all the posts here.

 

[Harbinger]

@Chromatix: It's already been stated on a long discussion thread (I can't for the life of me find it though) that the position of SOL in relation to Sagittarius A* is not quite correct in the current version of the galaxy.

The coordinates we're attempting to provide are as accurate as we can make them given the maximum of 3 decimal places we have to work with when it comes to distances in the galaxy map.

Personally I am taking the distances (to 3 d.p.) to 9 stars that Michael Brookes has provided coordinates to. I then test all 126 unique permutations (no repetition) of 4 star groups which return x,y,z coordinates which will fit in a 1/32 grid. I then run a count of the number of matching coordinates on each axis. The coordinate with the highest count is the one selected.

Typically there are 120+ matching positions for each axis (many times the full 126). I'd like to think a 95%+ agreement on position on each axis is pretty good result.

 

[Biteketkergetek]

Thanks, that's the file I was looking for - got myself a bit lost in all the posts here.

Well, it might not be the file you want Smacker has many branches, and there are other forks of TradeDangerous as well (the official being kfsone's of course). The file is from the NewCoords branch which is the one Smacker pointed to me as far as I can remember.

Perhaps if there was a separate repository for this SQL (and maybe a readme to import/export/use it) then the situation would be better for us coordinate consumers. The "data" directory of trade dangerous could be a git submodule then (referring to this separate project), so in the end normal work on TradeDangerous would not be affected.

 

[TunaMage]

I've found your algorithm to be spot on with those four reference stars (h Draconis, Wyrd, LHS 2884, Keries). But I recommend adding one more reference just for confirmation: it's easy to make a mistake inputting the distances and with your spreadsheet it's impossible to tell that you've made one.

Your algorithm does struggle with bad choices of reference stars but I think that's unavoidable for any algorithm relying on just four references. Adding another reference will also help with this I think.

Finally your algorithm produces less accurate results for several distant stars (Alpha Cygni, Enif, Rigel, Sagittarius A*). Again this is down to the references: I think those four you've chosen are not far enough apart for more distant systems. This probably doesn't matter. If you're interested I can give you the distance data I have for these cases.

Yes, I agree with the above, and will add the 5th star to the equation.

Regarding distant stars, yes the accuracy will drop. Bear in mind that any four (or soon five) stars can be used as reference stars in my algorithm, their names just need to be entered. This of course is dependent a bit on the user knowing what they are doing when they use it. But I'll see about having a secondary check system in place that will tell the user if the reference stars are not great, and possibly recommend other candidates.

On a sightly different note, my coding strengths are with excel, more than other options. The spreadsheet I released so far was intentionally macro free. But If I make it more sophisticated, I'll need to start introducing macros back into it at some stage. Do you think this would be a problem for general users?

 

[RedWizzard]

My coordinates for Sagittarius A* are [23.460, -15.232, 25899.986], based on 6 samples. I wonder how significantly different from [0, 0, 25900] it really is; the galactic coordinate system is supposedly based on this object as one of the defining reference points (Sol being the other).

For the 9 references I've got putting SA* at [0, 0, 25900] causes those distances to be out by 0.02-0.12 Ly compared to the values reported in the game. That's much worse than the 0-0.002 Ly variation between calculated and reported distances that my coordinates give. Your coordinates give 0-0.007 Ly variation so they're also much better than [0, 0, 25900]. I wonder if SA* was originally placed at those coordinates (or even [0, 0, 25000]) but later moved as FD got updated information.

 

[TunaMage]

Well, it might not be the file you want Smacker has many branches, and there are other forks of TradeDangerous as well (the official being kfsone's of course). The file is from the NewCoords branch which is the one Smacker pointed to me as far as I can remember.

Perhaps if there was a separate repository for this SQL (and maybe a readme to import/export/use it) then the situation would be better for us coordinate consumers. The "data" directory of trade dangerous could be a git submodule then (referring to this separate project), so in the end normal work on TradeDangerous would not be affected.

Yup, or maybe even a simple csv. As I mentioned in my post above, I'm working mostly directly in excel, others in Python, and others in different languages. Ultimately there seem to be quite a few tools emerging here for capturing analysing and presenting data. So if a simple base format of data is available somewhere, it could be handy for everyone working on it from their various angles...

 

[RedWizzard]

Yes, I agree with the above, and will add the 5th star to the equation.

Regarding distant stars, yes the accuracy will drop. Bear in mind that any four (or soon five) stars can be used as reference stars in my algorithm, their names just need to be entered. This of course is dependent a bit on the user knowing what they are doing when they use it. But I'll see about having a secondary check system in place that will tell the user if the reference stars are not great, and possibly recommend other candidates.

I was thinking it would probably be enough if you just let the user pick a 5th star and then show the calculated distance to that star. If that distance matches what ED tells them then the coords should be good and if not then they've made a mistake somewhere (either in the distance data or in the choice of the main 4 stars).

On a sightly different note, my coding strengths are with excel, more than other options. The spreadsheet I released so far was intentionally macro free. But If I make it more sophisticated, I'll need to start introducing macros back into it at some stage. Do you think this would be a problem for general users?

I think the only problem with macros would be that a lot of people have macros disabled by default. I'm not sure if that can be worked around or not.

 

[Biteketkergetek]

Yup, or maybe even a simple csv. As I mentioned in my post above, I'm working mostly directly in excel, others in Python, and others in different languages. Ultimately there seem to be quite a few tools emerging here for capturing analysing and presenting data. So if a simple base format of data is available somewhere, it could be handy for everyone working on it from their various angles...

I thought of using json, but in the end there will be many stars, so I believe neither json nor csv will work in the longer term. Once such a project is up, scripts to export a csv (eg. all stars in a sphere defined by the query) could be added though in a tools subdirectory. I believe this is the only right way to do it, even if it is a bit more cumbersome for coordinate consumers, otherwise people needing data other than the coordinates would (could) not use and update it.