Right, thanks.
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Not sure if this is exactly what you're looking for, but I've updated my systems.html page to include CSV output. Get the latest version of everything here.
A couple of things to be aware of:
The contributor names in systems.json don't really match what is in TD (and I credit multiple people if they've all added several distances), and I only have modification dates for stars that have been entered via entry.html which isn't many.
The page outputs the entire list of systems. If you just want the latest new stars they'll be at the bottom as the default order is the order the stars appear in systems.json. If you sort the table and then hit "generate" then the csv will be in the same order as the table.
No problem at all - I prefer frankness. Saves everyone time
Very long post (as are mine...) I'm not going to comment on it point by point (dangit I nearly ended up doing just that...)
Just a few take aways:
20 permutations vs 24 permutations - D'oh on my part.
I of course meant 24, no idea why I kept writing 20 - It was late
Nice catch.
---------
Ignore the below. Can't seem to find a
Had gotten my p1-p3 vs p1-p4 permutations mixed up.
That along with the --aside-- experiments below got the thing mixed up for me - apologies.
"the order of the 3 references used to generate the candidate points is not important."
I'm sorry - But it is.
Due to the rounding of the distances - Ie. the "delta" between the "true" value and the rounded value.
Some of those deltas are larger than the others.
The formula (wikipedia) first calculates x, then y and z.
The calculation for y depends on x, and z on both x and y.
If the calculated value for x is "very accurate" (due to the deltas being small) then y will be "less off" than if two other systems (with larger deltas) had been used.
etc.
So basically - If the rounded distance to say reference star 1 (r1 in wikipedia formulas) just so happens to have a very large delta, then the trilateration is more likely to be in-accurate.
Trilateration is very sensitive to the measured distances - hence why 4 digits precision works so much better (obviously).
So yes - The order does matter (not always -again, depending on how large/different the deltas are)
-- aside
I've done tests on this as well, putting in the deltas in the formulas - To see if one could somehow "isolate" them, or at least try and use them for accuracy prediction - based on how the coordinates are related to each other (another dead-end btw
)The formulas get extremely unwieldy ofc - But it's sorta interesting (if you are math inclined).
But put in max delta (+/-) and it's very visible what happens to the end coordinates (you get 8 formulas - for all possible combinations of max delta (+/-))
x is fairly predictive - always having a max and min range (so you can say if I err on the side of max delta on this, and min delta on these two - then i will always get the most accurate result)
y pretty much the same, but more spread out.
z on the other hand... appears entirely chaotic as you change the coordinates of the reference systems.
As said - a dead end for any predictiveness with regards to accuracy. But was a "fun" exercise in error-calculation.
-- end aside
----------
"Trilateration requires good reference systems, as has been mentioned repeatedly in this thread. I think it is better to use an algorithm that will work well with a specified set of references or that will warn when the chosen references are bad"
"I'm not sure there is much value in testing with random reference systems because we already know that can get you into trouble."
This is likely controversial - But I do not subscribe to the idea of "fixed reference systems".
The reason being my above observations regarding deltas on distances.
I know it has kind of been accepted as "the way to go" in this thread - But I'm sorry, the math says it's irrelevant.
Any set of "fixed reference systems" is just as likely to have large deltas as any randomly picked systems.
It all depends on what system you want to pin down - and if it just so happens that the coordinates for that systems will give rise to large deltas on the distances or not.
No "fixed reference systems" that one picks can ever guarantee that there wont me max deltas (large rounding errors on the distances)
And those deltas are what matters.
A "good reference system" is one that (just so happens) to give small deltas.
And that is entirely dependent on the target systems coordinates.
I'll gladly do a math post proving this if required. Let me know.
-------
Ignore the below.
Again my mixup of my p1-p3 vs p1-p4 permutations - With just p1-p3 permuted our results agree.
"I never get more than 2 coordinates (which would indicate that the order was significant)."
This flies in the face of my experimentation - With the same setup.
When you calculate r1,r2,r3 (which would be the user inputted values) do you remember to round them to 3 digits of precision before using them in the trilateration formulas?
I once made an "ooops" forgetting this - Only reason I mention it...
Otherwise I cant explain the difference in our results.
And this really is something we should look at.
Our test setup is the same (3 random systems (well 4..) - to determine 4th (that we already know what the result should be for)).
So that we get such divergent results is troubling.
------
"Our output point is an approximation of the shape generated by the intersection of those three shells. The intersection of the three shells can be quite large (if the reference stars are poorly chosen), large enough to contain multiple points on the 1/32 Ly grid."
Again, if by "non poorly chosen", you mean 3 (or more) fixed reference systems that are always used for the calculations of p0 - Then I have to disagree.
You can not pick such systems such that the delta on the distances to p0 will always be minimal.
Move p0 a bit to the side and delta-r1 will go up, and delta-r2 will go down (or also up - who knows) etc.
I do agree that any picked reference systems should be "spread around" the target system (p0) as this is more likely to reduces the area of the intersecting shells.
----
"Which means the reference stars are degenerate in some way, e.g. they all lie in a plane."
The degenerate case is if the reference stars are *collinear*.
The reference systems p1-p3 will always be in a plane (3 points always will be)
"Trying to use linear algebra to predict if your reference systems are a good set seems like an incredibly roundabout (and difficult) way to tackle the problem"
Very much so
.But that was to try to determine if p4 where in a plane with p1-p3, and if that was bad for the result of trilateration formulas.
The consensus in this thread seems to have been that that would be the case - as your comment just above also shows.
So I ended up disproving that - after all too much liniar algebra
Wether p1-p4 - or indeed p0-p4 all are very close to being in the same plane or not - has no impact on the final calculations.
Again - It all boils down to the deltas on the distances - Regardless the spatial positions (minus the colliniar case)
-----
"In my opinion the best measure of accuracy is how well the distances derived from the calculated coordinates match the input distances. "
The difference being the deltas as I call them.
And yes we agree - The smaller the deltas, the more accurate the result is likely to be.
"If the distances between p0 and p1 .. p5 match the supplied distances d1 .. d5 to the precision of d1 .. d5 (3 decimal places in the galaxy map) then p0 is as accurate as we need it to be (and in fact as accurate as we can test for)."
This is one test I haven't done for some odd reason.
Comparing the p1-p3 distances after the calculation...
Now I have something to do the rest of the day instead of writing mega posts here.
I'm going to correlate this with the results of my other tests - and see if they match up or not.
My suspicion is that that still leaves room for error though...
Replacing one of the reference systems (p1-p3) with another system (and then using my draconian acceptance measures), I still think will be better.
I might prove myself wrong though - I'll let you know what I come up with.
-------
resolved - see earlier strikeouts
As a last PS in this ridiculous long post, so that it doesn't disappear in the wall of text: I really am very very interested in finding out why our tests give different results, as mentioned further up (the "maybe you didn't round the distances" suggestion - I'm sure you did but then what?)
Last edited:
Harbinger
Volunteer Moderator
Let me break down the method I use for you.
First I input the distances in LY to all 9 of these systems to which we have confirmed coordinates courtesy of FDEV (or in the case of Sol we know to be at 0,0,0).
- Sol
- Wolf 497
- Huokang
- Demeter
- Clotti
- Fu Haiting
- San Guaralaru
- Haras
- Arabha
With the exception of Sol which is outside the pill, all of these systems are at the edges of the pill which gives them good placement for calculation of anything else.
Once I have the measurements I test all 126 permutations of 4 star groupings (I don't waste time and effort testing the same 4 star groupings in different orders).
This gives me 126 sets of 1/32 rounded (x,y,z) coordinates which for the most part are identical but there are some slight disagreements on the position.
I then count the results for each individual axis and select the candidate with the highest count. Typically the winning coordinate has 120+ counts out of the potential 126. This is true of all 3 axis.
Now I have my winning set of coordinates I test the distance from that set of coordinates back to all 9 of the reference systems to see if there's any variance on the inputted distances. This tells me if the calculated distances are out by even 0.001 LY of the inputted data.
I've only recently started testing the distance in this way but with the last set of 22 systems I released the coordinates to, I only had a warning once and that was because I actually entered a typo.
tl;dr
In short, yes it works.
Last edited:
NAem and Crowdsourcing methodology
Hi Guys
Wow this thread moves fast
Taking up on a couple of themes from today:
Name: How about "The Galactic Mapping Cartel" - lol, has a slightly sinister ring to it, but more on that later
Crowdsourcing Methodology: Now that most of the star are mapped for B2 (seriously well done to all the major contributors!), understandably contributors to this thread are looking at 'next steps' from when galaxy opens up. From a 'project management ' point of view, I see two main areas of focus, 1. How will crowdsourcing technically run, and 2. How do we approach enough CMDR's to crowdsource.
1. I think its fairly clear that a web based input interface is probably the best way to go. Inputs would be stored and and the trustworthiness of the data vetted buy using the trilateration methods, and possibly mine as a backup (with 5 targets instead of 4). Once these are accepted the star becomes a 'known star' that can be published. How it gets published for general consumption is another discussion.
2. This may be a bit controversial, but if we are to get general population CMDR's to help input data, there might need to be some incentive, otherwise only a few dedicated CMDR's may end up contributing. I would say the best inncentive would be to give information back in return for information. Eg if linked to trade calculator, ask the cmdr for distances from where they are to xyz (un mapped yet) stars, then the CMDR gets the trade info he/she wants. Or give an area in space's system coords in return for a few distances needing capturing, etc.
The problem of course is if all information is available to all CMDR's then this is no incentive. Ie. all coord's can't be published publically.
It is a bit cartel like, and it might not be workable, and I'm happy to get beaten down for this idea, but trading in information is the best thing I can think of to keep CMDR's feeding information in.
Hi Guys
Wow this thread moves fast
Taking up on a couple of themes from today:
Name: How about "The Galactic Mapping Cartel" - lol, has a slightly sinister ring to it, but more on that later
Crowdsourcing Methodology: Now that most of the star are mapped for B2 (seriously well done to all the major contributors!), understandably contributors to this thread are looking at 'next steps' from when galaxy opens up. From a 'project management ' point of view, I see two main areas of focus, 1. How will crowdsourcing technically run, and 2. How do we approach enough CMDR's to crowdsource.
1. I think its fairly clear that a web based input interface is probably the best way to go. Inputs would be stored and and the trustworthiness of the data vetted buy using the trilateration methods, and possibly mine as a backup (with 5 targets instead of 4). Once these are accepted the star becomes a 'known star' that can be published. How it gets published for general consumption is another discussion.
2. This may be a bit controversial, but if we are to get general population CMDR's to help input data, there might need to be some incentive, otherwise only a few dedicated CMDR's may end up contributing. I would say the best inncentive would be to give information back in return for information. Eg if linked to trade calculator, ask the cmdr for distances from where they are to xyz (un mapped yet) stars, then the CMDR gets the trade info he/she wants. Or give an area in space's system coords in return for a few distances needing capturing, etc.
The problem of course is if all information is available to all CMDR's then this is no incentive. Ie. all coord's can't be published publically.
It is a bit cartel like, and it might not be workable, and I'm happy to get beaten down for this idea, but trading in information is the best thing I can think of to keep CMDR's feeding information in.
Thanks - Your methology is clear.
I do disagree with your reasoning to ditch some of the permutations though - See my mega posts above. p1-p4 order *does* matter. EDIT: But not p1-p3 order.
But that is actually irrelevant for this test.
As it's the comparison of the distances afterwards that's interesting here.
And it seems they yield good (reliable) results.
If they are truly good enough to not let any "false positives" through - remains to be seen.
Have you tried to use one of the other candidate coordinates (ie. the 2nd best), which presumably would be off by just 1/32 - and see if the (rounded) distances would still match in that case?
I suspect that could happen in some cases...
Hence I'll be (yet again) in testing mode the rest of the day probably
Thanks for sharing.
(and yay for a non-mega post for once)
I do disagree with your reasoning to ditch some of the permutations though - See my mega posts above. p1-p4 order *does* matter. EDIT: But not p1-p3 order.
But that is actually irrelevant for this test.
As it's the comparison of the distances afterwards that's interesting here.
And it seems they yield good (reliable) results.
If they are truly good enough to not let any "false positives" through - remains to be seen.
Have you tried to use one of the other candidate coordinates (ie. the 2nd best), which presumably would be off by just 1/32 - and see if the (rounded) distances would still match in that case?
I suspect that could happen in some cases...
Hence I'll be (yet again) in testing mode the rest of the day probably
Thanks for sharing.
(and yay for a non-mega post for once
)
Last edited:
1:
We agree that a web based interface is the way to go (imo the only way to go in this day and age) (have you taken a look at EDSC?
Ease of use is the determinator if it's going to work (in the long run not just beta) or not.
Trustworthiness of data: Paramount imo as well.
Hence why EDSC is very draconian in what it accepts - and it also has a rating for how often data has been confirmed.
2:
"Don't cut off the branch you sit on"
Restricting access in any way - once we go full, will hurt you.
You have to think volume.
The more people you get to use your tool (because it's free - and ofc provides results) the more people will take that extra few minutes to provide some data.
It will *always* be a very small percentage, especially when we hit full (beta is a bad indicator as us betad are generally rather more dedicated than non-betas), but small percentage of a larger number is still better.
So my advice is to not "go cartel", it'll hurt your throughput in the long run.
Harbinger
Volunteer Moderator
Actually, no I hadn't tested prior to you mentioning it but it's a good idea to test it.
On one of my released sets of coordinates earlier I found the best fitting set of coordinates of Trua to be (-87.46875, 12.9375, -38.3125) but there were disagreements on the coordinates in 5/126 permutations:
Code:
[36] => Array
(
[permutation] => SOL|DEMETER|CLOTTI|FU_HAITING
[x] => -87.5
[y] => 12.90625
[z] => -38.28125
)
[37] => Array
(
[permutation] => SOL|DEMETER|CLOTTI|SAN_GUARALARU
[x] => -87.5
[y] => 12.90625
[z] => -38.28125
)
[38] => Array
(
[permutation] => SOL|DEMETER|CLOTTI|HARAS
[x] => -87.5
[y] => 12.90625
[z] => -38.28125
)
[39] => Array
(
[permutation] => SOL|DEMETER|CLOTTI|ARABHA
[x] => -87.5
[y] => 12.90625
[z] => -38.28125
)
[100] => Array
(
[permutation] => HUOKANG|DEMETER|HARAS|ARABHA
[x] => -87.46875
[y] => 12.90625
[z] => -38.3125
)4 of these permutations gave the coordinates (-87.5, 12.90625, -38.28125) and the other (-87.46875, 12.90625, -38.3125) so I again entered the distance data but instead forced these outweighed coordinates to be selected.
In the first case:
And the second case:
As you can see in both forced errors it detects distance variances in all 9 reference stars.
Harbinger
Volunteer Moderator
Forgot to mention. I did find another unmapped system on my travels (WREDGUIA LW-E D11-129). It's right on the edge of the pill next to HIP 2453.
No matter how many times I attempted to enter that system in order to map the coordinates I got the infinite hyperdrive animation. (I still need to ticket that.)
Not sure if any of you guys can get in.
No matter how many times I attempted to enter that system in order to map the coordinates I got the infinite hyperdrive animation. (I still need to ticket that.)
Not sure if any of you guys can get in.
wolverine2710
Tutorial & Guide Writer
Can't play ED atm - guests. Have you tried SOLO online?
Note: Great you have found a system for which we don't have coords yet!
Harbinger
Volunteer Moderator
Yeah, I map in solo.
wolverine2710
Tutorial & Guide Writer
Soon its time to get to bed. I hope some other commander can this test for you. If not I will fly my Hauler (20LY jumprange) there and see if I can get in.
Probably much better - what I personally would do in this case. Please create a new thread for it and ask if someone can reproduce the problem. If so please create a ticket for and point to that thread.
Harbinger
Volunteer Moderator
As we're nearing 570 stars in the pill it's getting very hard to locate the missing ones now but:
Verification
- Upsilon-1 Cephei (-87.09375, 13.875, -7.15625).
- Wolf 1080 (-77.8125, 12.84375, -5.78125).
- LTT 16470 (-64.375, 9.5, -19.625).
- Liabefa (-77, 39, -56).
Code:
'Upsilon-1 Cephei',-87.09375,13.875,-7.15625,'Harbinger','2014-10-19 19:06:35'
'Wolf 1080',-77.8125,12.84375,-5.78125,'Harbinger','2014-10-19 19:16:07'
'LTT 16470',-64.375,9.5,-19.625,'Harbinger','2014-10-19 19:26:28'
'Liabefa',-77,39,-56,'Harbinger','2014-10-19 20:12:43'Verification
If you require a single person to input all the data required to calculate the coordinate for a star, then only "explorers" visiting new stars will be able to enter data - and it puts a larger onus on them because they have to gather more data.
If you let anyone from anywhere enter some data.. then you'll end up getting a lot more data.
As for actually getting a list of star names - I still see that being primarily an explorer's job. But instead of actually having to visit each and every system and get N distances, which isn't really feasible, they only have to grab the names of the systems and enter those, maybe with a distance to the "current" system as well. And then rely on everyone else to add more distances.
Let's say you're in some area, and you want to get coordinates for stars in that area.. so you grab all the names, enter them into the system, maybe with a few distances of your own, and then let the website collect distances from others.
Great post! I had started writing up something as well, but realize that it was going to be an hour long post, and decided it was too late for that
In any case, just a couple of comments - regarding "random reference systems" - I'm not a fan of using a fixed set of references. Especially as we move out further into the galaxy, you won't be able to use the same set of stars, because they'll be too far away and too clustered together due to the distance.
Although, I think you alluded to the solution -- the algorithms we use to calculate the coordinate should be able to determine if/when more data is needed, as well as being able to detect bad data.
Re: lower precision distances - the higher precision distances are always better of course. It is possible to get the coordinate using lower precision distances, but it takes potentially a lot more data. As you might have noticed, to upgrade my coordinates from the original "estimated coordinates" that I gave, to a high confidence "correct" coordinate, I went back and gathered a lot of high precision distances
The only reason to use low precision data would be in the case when someone is out exploring unknown territory, and they're grabbing the names of adjacent stars from the nav panel. It doesn't take much more effort to grab the distance shown there, and that's a quick, easy way to get 50+ distances in some cases. And, with my proposed system, they wouldn't have to go visit *each and every* one of those adjacent stars to get high precision distances, but rather, just grab the names, maybe some low-precision distances, and continue exploring.
Personally, I don't like this, and I probably wouldn't contribute to such a system. Plus, I don't think it's feasible to keep the coordinates private in any case. If we try to go that route, then someone will get the "rep" or whatever necessary to see the coords.. and then publish them themselves.
My accumulated data calculation shows this:
Code:
CHI Hercules (unknown): not enough data
Mirfak (unknown): not enough data
Paul Friedrichs Star (unknown): not enough data
LHS 465 (unknown): not enough data
Ross 868 (-24.6875,19.125,21.3125): ref: 2; calc: 4;
LP 329-18 (-26.625,39.875,23.28125): ref: 3; calc: 4;
Wredguia YS-O B47-4 (-135.59375,39.75,-40.71875): ref: 4; calc: 4;
LTT 14542 (-57.21875,57.84375,-14.625): ref: 4; calc: 4;
Wredguia DO-O B47-1 (-69.71875,26.375,-31.625): ref: 4; calc: 4;
Wredguia XH-Q B46-3 (-81.96875,46.71875,-40.375): ref: 4; calc: 4;More detailed output:
Code:
New: Sagittarius A* (unknown): data not good enough
Aulin : 25895.313
Ross 905 : 25907.248
41 Gamma Serpentis: 25877.164
Theta Draconis : 25900.135
SDSS J1416+1348 : 25888.027
Tring : 25948.393
Wyrd : 25903.984
LHS 2884 : 25898.322
Keries : 25887.457
h Draconis : 25904.006
35 Draconis : 25928.682
Ross 868 : 25878.734 (unknown)
calculations: 1304; time: 1.774000; coordinates: 0
no insert
New: CHI Hercules (unknown): not enough data
Eranin : 16.364
calculations: 0; time: .000000; coordinates: 0
no insert
New: Mirfak (unknown): not enough data
Theta Draconis : 488.791
calculations: 0; time: .000000; coordinates: 0
no insert
New: Paul Friedrichs Star (unknown): not enough data
Perkwunos : 14.746
calculations: 0; time: .000000; coordinates: 0
no insert
New: Ross 868 (-24.6875,19.125,21.3125): references: 2
Zeta Herculis : 6.88 6.88
LP 275-68 : 8.64 8.64
Miquich : 7.18 7.18
G 181-6 : 8.55 8.55
Sagittarius A* : 25878.734 (unknown)
calculations: 4; time: .008000; coordinates: 1
no insert
New: LHS 465 (unknown): not enough data
WISE 1647+5632 : 6.43
calculations: 0; time: .000000; coordinates: 0
no insert
New: LP 329-18 (-26.625,39.875,23.28125): references: 3
HIP 105906 : 118.928 118.928
HIP 91906 : 100.855 100.855
Jurua : 83.118 83.118
Moros : 62.136 62.136
calculations: 4; time: .007000; coordinates: 1
no insert
New: Wredguia YS-O B47-4 (-135.59375,39.75,-40.71875): references: 4
HIP 105906 : 28.673 28.673
Jurua : 77.079 77.079
Moros : 92.853 92.853
35 Draconis : 53.324 53.324
calculations: 4; time: .006000; coordinates: 1
no insert
New: LTT 14542 (-57.21875,57.84375,-14.625): references: 4
HIP 105906 : 70.951 70.951
Jurua : 49.741 49.741
Moros : 45.197 45.197
35 Draconis : 31.701 31.701
calculations: 4; time: .006000; coordinates: 1
no insert
New: Wredguia DO-O B47-1 (-69.71875,26.375,-31.625): references: 4
HIP 105906 : 56.778 56.778
HIP 91906 : 49.254 49.254
Jurua : 21.235 21.235
35 Draconis : 29.863 29.863
calculations: 4; time: .006000; coordinates: 1
no insert
New: Wredguia XH-Q B46-3 (-81.96875,46.71875,-40.375): references: 4
HIP 105906 : 36.362 36.362
HIP 91906 : 28.95 28.95
Jurua : 32.82 32.82
Moros : 47.32 47.32
calculations: 4; time: .006000; coordinates: 1
no insert
Last edited:
This really isn't an optional "after the fact" check that I do, it's more an integral part of my algorithm for finding the coordinate.
I've described it elsewhere, but basically - trilaterate to find an initial coordinate and then do a hill descending algorithm on the error function (the sum of the squares of distance errors for all known distances). At this point, you'll have a non-grid aligned coordinate that is within the "candidate region" - the region where all the spherical shells overlap. (Or, if you don't, it means that one of the data points is wrong, and there is no common overlap). And then, I start "exploring" the grid-aligned points in the vicinity of that non-grid aligned "good" coordinate, to find all grid-aligned coordinates that are within the candidate region.
It's easiest to think of it in 2-d terms. Basically you have a function that forms a valley, with an area of "floor" that is at 0 (the "candidate region"). And I have a point on the floor. So then I start looking in one direction until I see the wall of the valley, and then I look in the other direction until I find the other wall.
Of course, we actually have a 4d function (3d + the error value), so it's actually searching in an additional 2 dimensions, but that's the gist of it.
Once I've fully mapped out the candidate region, if I've found multiple grid aligned points within the candidate region, then I know that I don't have enough data for that star yet. Or, if I didn't find any, then I know there's an error in the data somewhere (although, this is normally caught earlier, when doing the initial hill descent to find the candidate region)