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

So if we're going to allow data with 2 decimals (from the HUD) then we need to be more careful to pick the best reference systems to calculate from.

Not necessarily. The important thing to keep in mind is the whole 1/32 grid thing. For example, let's say you have 4 distances that are 2 decimal, or even 1 decimal accuracy. You can use those distances to get a good idea of where the star is - but you likely won't get the exact coordinate. *But* you can get more data to further refine the estimate.

The best way to think about it, imo, is to use trilateration to get an estimated coordinate, and then you can search the grid points around that estimated coordinate and see if there are multiple such points that match the data you have. The discrete nature of star placement makes this quite easy.

So the initial trilateration only uses 4 distances, but then you can use however many distances as you have for the second step, and as you add more distances, you'll rule out more and more grid points, until you get The One True Coordinate.

algorithm/pseudo-code:
Code:
est_coord = trilaterate(system1, system2, system3, system4)
matchingCoords = 0
for coord in generateNearCoordinates(est_coord): # generate, e.g. a 5x5x5 grid centered on est_coord
  matches = True
  for (star, distance, accuracy) in getAllDistances(): # gets all the distances to this star that we know of
    if round(distanceBetween(coord, coordinateOf(star)), accuracy) != distance: # rounds the distance to N decimal places, based on the accuracy of this particular distance
      matches = False
      break
  if matches:
    matchingCoords++

After that, if matchingCoords is exactly one, then you know you have the correct coordinate, assuming your input data is correct, and that the grid generated by generateNearCoordinates is big enough to encompass the largest "error" that the trilaterate function can generate. Some math (and/or experiments) would be needed to determine if a 5x5x5 grid would be sufficient. I suspect it would be, but an even larger areas could be searched if needed. That would be a .15625LY cube, which is at least larger than the +/- .05 error from a 1 decimal place distance.

The second step can also be used as a form of input validation - if no grid point matches all the data you have, then you know one of your data points is bad. Although, it's a bit harder to figure out which one is bad.
 
Last edited:
Not necessarily. The important thing to keep in mind is the whole 1/32 grid thing. For example, let's say you have 4 distances that are 2 decimal, or even 1 decimal accuracy. You can use those distances to get a good idea of where the star is - but you likely won't get the exact coordinate. *But* you can get more data to further refine the estimate.

Trilateration uses three points to calculate two candidates and then a fourth point to select which candidate is correct. Your algorithm then refines the candidate chosen. But if you read that example I gave, 2 decimals of distance data and a bad choice of reference systems can result in the wrong candidate being chosen during trilateration. In that example the chosen point was incorrect by at least 1 Ly in each axis, and more than 3 Ly in the z axis! Your algorithm won't help at all in that case because all the nearby 1/32 Ly grid points you're testing will also be wrong. But you could extend your algorithm in that case to go back to the other candidate and check the grid points around that.

Anyway there is always the degenerate case where all four reference systems are in a plane. You have to avoid that, at least.
 
Last edited:
This happens if you calculate Eranin using Sol, Flousop, and Tring with only 2 decimals:
Eranin-Sol: 43.10
Eranin-Flousop: 29.43
Eranin-Tring: 115.90
Calculated coordinates: (-24.259, 35.548, 2.329)
Real coordinates: (-22.844, 36.531, -1.188)

Note: if you're only using 3 systems, then the trilateration will result in 2 possible points. (Edit: I was still typing this reply up and didn't see your reply to the same effect... :) For the 3 systems and distances you mentioned, the two possible points (non-grid-aligned) would be:

-24.259, 35.548, 2.329 and
-22.777, 36.565, -1.342

While the second one is still off by a bit, it's quite a bit more accurate than the other one. And, as I had mentioned in my previous post, you could detect that the coordinate is less accurate by searching the near coordinates.

I also ran my experiment with the 5x5x5 grid using this data, which turned out to be too small in this case, since the z coordinate is further out. But expanding it to a 9x9x9 grid (around the closer coordinate) showed exactly 2 grid points that matched - one of them being the One True Coordinate, of course. This actually didn't match my mental model of what the grid was doing, so it sorta works still, just not in the way that I initially thought.

I was expecting basically a "volume" of hits, e.g. an ellipsoid or something that matched the given data, and that the estimated coordinate would be somewhere within that volume. And as you added more data, it would pare down that volume until it consisted of a single point. But that's not what's happening here, so it's back to the drawing board for that particular mental model :)


(Or maybe it's just that the ellipsoid is narrow enough in the one axis that it doesn't hit most grid points? More investigation to be done!)
 
Last edited:
Trilateration algorithm

I have been browsing away on math forums and wiki's to understand this Trilateration thingie but I can't seem to be able to get it into my head.

Could anyone explain it? (imagine talking to a 1st grader).

Two sets of coords and distances gives an intersecting circle, three should isolate two points on that circle, four should eliminate one of those and leave you with the point that satisfies all distances. But how to cope with error margins?

A bit of pseudocode or calculation example would be nice. Just keep it simple, my brain isn't working as well now days.
 
I have been browsing away on math forums and wiki's to understand this Trilateration thingie but I can't seem to be able to get it into my head.

It sounds like you have a pretty good handle on it :)

The way I mentally visualize the way to handle the inaccuracy in the data is instead of finding the intersection of the surfaces of some spheres, you're actually finding the overlap of some spherical shells, where the thickness of the shell is based on the accuracy of the measurement. Although, it's definitely a bit harder to imagine that way, unfortunately. The end result (I think), is that you end up with some small volume where the coordinate might be located. i.e. if you take any coordinate in that volume, and then calculate the distance to the other 4 systems that you're using, the result will be within +/- the accuracy of the measurements.
 
Personally I am still having a hard time understanding how we have come to a point in 1300 years where we don't use coordinates anymore. Sure you don't see latitude and longitude on a GPS device on the main screen (except maybe the ones for boats). But you can usually look at them if you want to.

And the ones for planes. And trekking ones. Those even map co-ordinates to your local map grid system if you want (I miss my GPSR). Any ‘real’ (i.e. survival-grade, not street-finder) GPS receiver shows you co-ordinates.[/quote]

In other words: Coordinates of some kind should really be available in-game somewhere

I'm sure that'll be done. The DDF galaxy map is nothing like the current one. ED is a work in progress, after all. Besides, there were rudimentary co-ordinates in FFE (the BBS missions even gave you galaxy map coords when mentioning a system, so you knew where to look).
 
Note: if you're only using 3 systems, then the trilateration will result in 2 possible points. (Edit: I was still typing this reply up and didn't see your reply to the same effect... :) For the 3 systems and distances you mentioned, the two possible points (non-grid-aligned) would be:

-24.259, 35.548, 2.329 and
-22.777, 36.565, -1.342

While the second one is still off by a bit, it's quite a bit more accurate than the other one. And, as I had mentioned in my previous post, you could detect that the coordinate is less accurate by searching the near coordinates.

Oops, yeah I forgot to include the 4th point. It was Rahu at 33.32 Ly. Rahu's coordinates are -43.78125, 62.4375, and -0.25, so the distance to the first (incorrect) candidate actually matches better. So I think if all the 5x5x5 grid points near the chosen candidate miss then it'd be worth checking near the other candidate as well.
 
(Or maybe it's just that the ellipsoid is narrow enough in the one axis that it doesn't hit most grid points? More investigation to be done!)

Ok, yeah. After further investigation, it turns out that the candidate volume in this case is a thin sliver that mostly manages to pass between the grid points. Definitely a good test case :)


Oops, yeah I forgot to include the 4th point. It was Rahu at 33.32 Ly.
Ahhh, gotcha. That makes more sense now. I'm getting the same incorrect candidate selection in that case as well.
 
which coordinates to take?

I use the following algorithm:
  • permutate over all possibilities with 3 distances and one known system
    • calculate the two coordinates (rounding to 1/32)
    • iterate over all known systems with measured distances
      • calculate the distance
      • check calculatet distance against measured distance
      • remember if its a match or not
    • if all checked distances matches -> remember the coordinates (if the coordinates are allready know increase reference counter)
  • iterate over all remembered coordinates and print it with the reference counter

The one with the highest reference counter should be pretty accurate.
 

wolverine2710

Tutorial & Guide Writer
Michael said that it's difficult to extract the remaining unoccupied systems. But even if they did for beta 2 they won't be willing to do that for all 400 billion systems. The best we can hope for (IMO) is to be able to query some API for the names and coordinates of all systems in a sector, and even if we get that they probably won't take kindly to someone trying to iterate all the sectors in the galaxy.

I send him the PM and received his answer and the community later received his list. What he said in his second reply was:
Systems that are dynamically generated aren't always available in a format I can share. I'll try and get something out alongside the build, or tomorrow depending on how my day goes.

You can share this information.

Michael
I do NOT think Michael Brookes and FD are unwilling to help us but they don't have the time/resources to truly being able to help us. Developing a web-api would take time and is CONSIDERED for after the initial release. Creating a program to extract the hard coded coordinates and the procedurally generated ones also takes time and resources. But maybe just maybe they can help us a bit further and in way it does NOT costs them much. We still have to do our crowd sourcing BUT it can be automated. Its a much simpler variant of something I wrote in the OP of my thread "Reviving thirdparty (trading) tools using a poor man web-api solution -- XML dumps."

Let me try to explain. If you look at the network log files you will see that it logs where you currently are, just left SC and are in deep space, in a station and with coordinates. According to wtbw (who extracted the 3D coordinates for SB1) those coordinates in the logs are most likely relative to the star system or whatever. Hence he could not use them to get the 3D coordinates for SB1. BUT the logs show that ED knows where the ship is. Also when you make a Hyperspace Jump ED HAS to know where you are and what the coordinates of destination star system is. This could be the 3D coordinates Michael supplied us with or some other internal format. But ED has them.

Suppose they could write in a single file, the star system name and the 3D coordinates of the star system of where you exited a HS jump. We could then write a simple program which parses that file and uploads the name and coordinates to a server. We still have to do crowd sourcing - visit every star in SB2/SB3/gamma/release - but it could be automated.

It IS definitely a long shot but I could send Michael Brookes a concise PM in which I make this request. He could ask a dev and when the dev says sure, no problem, it takes me 1 hour to do that then Michael Brookes and FD MIGHT decide to let the dev create it for SB3.

We all try to do our best to get the coordinates but it turns out to be a real 'challenge' - though we have learned a lot. I'm sure we will succeed in the end but if FD could help us with this small request it would totally make life SO much easier. What do you all think. Would it be worth a shot?
 
Last edited:
I dont think they are unwilling either.

But at the same time, if a distance is given for really far out systems, it have to be calculated some way, and by that also translated to something that can be used for calculations outside the game.

About the 2 decimal 3 decimal thing. Use 3 from galaxy map. This should be pretty accurate even if use big spheres closer to eachother (as opposed to having 4 spheres all around the target system, should be more accurate).

Anyone actually tried to find the system furthest away from Eranin? Never tought of checking that myself... Just curious if the distance still have 3 digit accuracy...
 
Hi Guys

I developed a way of getting the co-ords a while back. I haven't looked into the Trilateration method too carefully. My calcs are based on brute force algebra starting from first principles on the cartesion planes and solving for the equations.

I would have liked to have developed the spreadsheet a bit further to aid in capturing and updating for crowd sourcing, but maybe if there are web developers around they can rather use the formula's here and build something user friendly, in a better way that I can. Time tends to run away from me a bit :)

The spreadsheet is here: https://drive.google.com/file/d/0B2KDLy9CyUTxZmdmQnFrUTh2WjQ/view?usp=sharing

Fill in the grey areas on the first sheet and the coords will be displayed there. The second sheet shows the calcs, and I've put some notes in there.
The third sheet is the B2 coords given by Michael, which of course can be added to if you like.

The error will only be a factor of how many decimals you put into distances. Over very long ranges it will increase a bit, depending on the anchor star configuration as well.

BTW you can use any 4 stars as anchors, as long as they are known. Also pls note nothing is protected in the worksheet, so it is breakable!

If anyone is interested further in the algerbra, I'll see about putting that up - its fairly dry stuff, so I guess not too many will be. But PM me if you are.
 
Last edited:
To answer my own question, 3 digits distance holds across the galaxy. Puwaei NF-A D2 is 62149.547 LY from LHS 2764A (where I happen to be now)

If someone is in other places of the pill, it would be interesting if could post system and distance, and see if trilineration came back with something like -7763, 101, 61664, or if the angles become too small for it to work.
 

wolverine2710

Tutorial & Guide Writer
Hi Guys

I developed a way of getting the co-ords a while back. I haven't looked into the Trilateration method too carefully. My calcs are based on brute force algebra starting from first principles on the cartesion planes and solving for the equations.

I would have liked to have developed the spreadsheet a bit further to aid in capturing and updating for crowd sourcing, but maybe if there are web developers around they can rather use the formula's here and build something user friendly, in a better way that I can. Time tends to run away from me a bit :)

The spreadsheet is here: https://drive.google.com/file/d/0B2KDLy9CyUTxZmdmQnFrUTh2WjQ/view?usp=sharing

Fill in the grey areas on the first sheet and the coords will be displayed there. The second sheet shows the calcs, and I've put some notes in there.
The third sheet is the B2 coords given by Michael, which of course can be added to if you like.

The error will only be a factor of how many decimals you put into distances. Over very long ranges it will increase a bit, depending on the anchor star configuration as well.

BTW you can use any 4 stars as anchors, as long as they are known. Also pls note nothing is protected in the worksheet, so it is breakable!

If anyone is interested further in the algerbra, I'll see about putting that up - its fairly dry stuff, so I guess not too many will be. But PM me if you are.

Out of curiousity I download the google spreadsheet as an MS .xlsx file. Opened it in excel and a miracle happened. It seemed to work. I tried by changing on the input page a value and a new value was calculated. Had NOT expected this.

Perhaps one or two commanders who have created a program can check his/her results with their results. Especially the case were things did not go as expected. As in not a correct calculated coordinate because of the place in the plane relative to the other reference points. I sadly lack the skills for this.
 

wolverine2710

Tutorial & Guide Writer
To answer my own question, 3 digits distance holds across the galaxy. Puwaei NF-A D2 is 62149.547 LY from LHS 2764A (where I happen to be now)

If someone is in other places of the pill, it would be interesting if could post system and distance, and see if trilineration came back with something like -7763, 101, 61664, or if the angles become too small for it to work.

I'm currently stationed at Pata Thewi, 107,482LY from LHS 2764A. So pretty much at the other side of the pill.
I believe this is what you asked for. If you need more info like distances, please let me know.
 
Hi Wolverine

If you are at Pata Thewi, look at distances to the four anchor stars on the spreadsheet, and see if the calculated coords match the ones from Michael's list. Should be a straightforward way for you to verify the calc's :)
 

wolverine2710

Tutorial & Guide Writer
Hi Wolverine

If you are at Pata Thewi, look at distances to the four anchor stars on the spreadsheet, and see if the calculated coords match the ones from Michael's list. Should be a straightforward way for you to verify the calc's :)

Cool, your spreadsheet checks if the system has already been calculated. Done calc with spreadsheet converted to excel sheet. Distances data, perhaps useful to compare with other progs.
New System Name Pata Thewi
Check Match System Already Captured!

Anchor Name Distance LY
Anchor System 1 H DRACONIS 75,927
Anchor System 2 Wyrd 101,726
Anchor System 3 LHS 2884 91,315
Anchor System 4 Keries 101,162

X Y Z
Calculated Coords Pata Thewi -108,4712 52,0651 -27,3445
Michaels Coords Pata Thewi -108,46875 52,0625 -27,34375
Diff calculated minus Michaels Coords -0,00245 0,0026 -0,00075
0,03125

Code:
Calculated Coords	Pata Thewi	-108,4712	52,0651	-27,3445
Michaels Coords	        Pata Thewi	-108,46875	52,0625	-27,34375

Diff calculated minus MB Coords           -0,00245	0,0026	-0,00075
1/32LY= 0,03125

So it looks as if when placed on a 1/32LY grid they are the same - IF I'm not mistaken.

Would it be possible for you to create an extra row which shows the calc coords but then rounded to the nearest 1/32 grid. Easier to check. Also a diff row would be nice, though that one I could create ;-)

Any extra candidates to check? I mean a star system which has an unfortunate place - not well described. I'm in a Hauler with 20 LY capacity, so I can jump around a bit. Also what would be really bad reference points? And how can I change it in the spreadsheet - I'm programmer, not a spreadsheet guy...
 
Last edited:
Would it be possible for you to create an extra row which shows the calc coords but then rounded to the nearest 1/32 grid. Easier to check. Also a diff row would be nice, though that one I could create ;-)

Any extra candidates to check? I mean a star system which has an unfortunate place - not well described. I'm in a Hauler with 20 LY capacity, so I can jump around a bit. Also what would be really bad reference points? And how can I change it in the spreadsheet - I'm programmer, not a spreadsheet guy...

I've added the 1/32 grid for you to check - just download again from the same link. However, I don't think this is a good way to go. My feeling is that the real coords are not actually on a 1/32 grid, but the data extracted from Michael is.

Therefore we will also be introducing errors by going to a 1/32 grid. After all the purpose of the calculator is to get new coords not given by Michael, so the new coords don't have to be on the grid. Anyway its in and is useful for testing purposes.

Regarding bad reference points, the 4 reference/anchor stars should be well spread out compared to the target star. If the reference/anchor stars are all close together and far away from the target this is bad. If the reference stars actually surround the target, this is best. For the purposes of the B2 'pill' the stars given as anchors are well enough spaced for anything else in the pill.

Regarding changing the reference stars, just re-type the names in the cells (C8-C11) on the first page. As long as the stars exist on the list on the 3rd page (and no typos) the calcs will work. ;)
 
I've added the 1/32 grid for you to check - just download again from the same link. However, I don't think this is a good way to go. My feeling is that the real coords are not actually on a 1/32 grid, but the data extracted from Michael is.

Therefore we will also be introducing errors by going to a 1/32 grid. After all the purpose of the calculator is to get new coords not given by Michael, so the new coords don't have to be on the grid. Anyway its in and is useful for testing purposes.

Indeed... has anyone checked that working out the distance between pairs of MB provided stars results in the same distance between them as shown on the map ? If they all match, then the game would appear to be using the 1/32 ly grid, if not it's just MB's extract of the data that has that feature.
 
Back
Top Bottom