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

[wolverine2710]

I've added three programs -which were mentioned yesterday here to the OP. I've this nagging feeling I missed one. So perhaps you commanders who created tools/programs can visit the OP and check if your program is in there. If I missed something please let me now - PM is also fine.

I believe there are programs/algorithms used for the crowd sourcing which have not been publicly released. Also I believe there was someone who created an algorithm which ended being used in another program (rewritten in a different language). The programs of course don't have to be released but I would like them to be added to list 1: "List of tools and programs created for the crowd source project". So the list reflects better the immense effort of all volunteers. If you will uncomfortable to post it here, just write me a PM.

 

[wolverine2710]

Standard Beta 2 system coordinates published.

I've taken the liberty to create a thread called "Standard Beta2 System Coordinates" which contains all SB2 coordinates. In the canonical format aka The One Reference aka TOR and a CSV format compatible with Trade Dangerous.

 

[Athan]

Have briefly looked at it. Are there plans to use all SB2 coordinates? I've added it to the OP.

If it wasn't clear... that tool is using real star data and the information I could find on transforming that to the ED co-ordinate system. It's absolutely not based on the actual ED stars at all. Thus it will be missing every single procedurally generated star, and it's also at least missing all the WISE ones as well. I highlighted it here purely as a helper if people are wondering "hmmm, I wonder which ED star such and such real star is based on". It's not intended as a source of actually accurate in-game positions, or a source of all in-game systems.

Edit: Oh, and I had an idea about why positions might be out. So far I only tried using proper motion data to run the positions forwards to 3300AD, but it's possible that FD also ran each star forward by the number of years equivalent to its light-years distance, i.e. to get a "current real position" for them in absolute terms. I'll try and look at this later today.

 

[Athan]

The assumption has been that the first of those formats is the one that will be used. The problem with the other two options is that it means the server must keep distances for systems with insufficient data to fix a location and I don't think that's the plan (at least not initially). Personally I have done quite a lot of data collection that way but I've manually been adding it to a file containing "unused" distances (distances.json in my source) which I can then extract systems from when there are enough distances to get a location. So I'd be in favour of it, but I think it's more important to get something running first.

I think it would be a mistake to insist on only storing offered data when a single submission contains enough to accurately calculate a system's position. We want as much data as possible. So TGC should store it all and work out if it has enough for an accurate position calculation.

Sure, ideally anyone offering input to TGC would be providing at least 4 distances for a reasonable chance at an accurate position, but then TGC has to do some verification on the result any way, so an extra initial step of "do we have at least X distances already?" is hardly onerous.

 

[wolverine2710]

If it wasn't clear... that tool is using real star data and the information I could find on transforming that to the ED co-ordinate system. It's absolutely not based on the actual ED stars at all. Thus it will be missing every single procedurally generated star, and it's also at least missing all the WISE ones as well. I highlighted it here purely as a helper if people are wondering "hmmm, I wonder which ED star such and such real star is based on".

Missed that one. My bad...
Still a very nice tool. It will stay on the OP, have made it clear that commanders know what it does and what it does not do.

 

[Chromatix]

I've added you to list1 on the OP. Just used SourceTree to clone your git repository. I'm getting an error when running it.

Python version: Python 3.4.1
Command: python edist.py "C:\Data\Games\Elite Dangerous\RW-3d coords git\systems.json"
Error:
File "edist.py", line 166
print "******************************"
^
SyntaxError: invalid syntax

Not sure what I'm doing wrong.

That looks like you're running Python 2.x code with a 3.x interpreter. Either don't do that, or run it through 2to3 first.

 

[wolverine2710]

That looks like you're running Python 2.x code with a 3.x interpreter. Either don't do that, or run it through 2to3 first.

Not a Python guy. You are probably right. I can't seem to find any reference by JesusFreke or the git repo about which version of Python is needed. Assumed 3.x. Not sure if I can install Python 2 and 3 alongside each other so I can test his tool. Google awaits....

 

[TornSoul]

I think it would be a mistake to insist on only storing offered data when a single submission contains enough to accurately calculate a system's position. We want as much data as possible. So TGC should store it all and work out if it has enough for an accurate position calculation.

The main problem is with data like below.

Spoiler

A challenge (I hope)


5 distances to known systems are submitted.
Unfortunately one of the distances has a typo (is wrong)

The challenge:
Can you determine p0
Can you determine which is the wrong distance

Data

	       x 	    y 	              z 	dist
p1	  -6.00000 	 36.28125 	-19.87500 	109.337
p2	 -51.87500 	 16.78125 	 -0.37500 	 67.447
p3	 -45.46875 	 18.56250 	 12.59375 	 79.204
p4	  -1.62500 	 16.81250 	  4.00000 	116.216
p5	 -20.12500 	 19.28125 	 19.00000 	104.498

A human can sit and ponder and try this and that, to try and make it fit.
In this particular instance - You will get several (6) candidates.
Of those, two of them can make 4 distances match (but not all 5) - Unfortunately not to the same 4 reference stars...
Either p1 or p5 doesn't fit the distance check. So which candidate to pick?

RW's tool in this instance, is able to fairly accurately predict that p5 has a wrong distance reported (as in a typo by someone (deliberately introduced by me in this case)).
While mine (EDSC) would simply reject it (as there are different candidates - My tool require them all to be the same or I don't trust the data)

I've however posted other examples that shows that RW's tool can also be "fooled" and end up not being able to pick the correct candidate - even when all distances are correct...
etc etc etc....

I think (at first at least) the job of doing "clever things", with retention of data that don't fit at first etc, belongs in the hands of the tool makers.
As this usually also allow an amount of human intervention (double check the map or whatever).
And having various lists of "we need more distances to star X" etc

And once the tool has (thinks it has) figured it out THEN it submits to the TGC.
TGC will obviously then run it's own checks - But with it's mission as just described, there is less loss in it rejecting submitted values - as hopefully the tool will try to rectify it (and then perhaps resubmit with better values)

TGC has NO user interaction - And there's a limit to how much cleverness we can automate (with as close to 100% accuracy as to not make a difference)

I think it's better for TGC to simply go "I'm sorry Dave, I can't do that", and then let Dave (the tool) figure something out (or not).

 

[Harbinger]

As Beta 3 is due out today I've done some updates to my coord calc site to fix some issues I introduced by adding distance checking and not taking into account the user may have supplied less than 9 distances.

I've also added a Contributor field to the form. It now outputs a RedWizzard style JSON output upon request and of course outputs the line to add to System.csv in TradeDangerous.

@TornSoul: With 5 supplied distances to reference stars it's easy enough to find the typo with a distance check on the most likely coordinates and report back which one has a distance variance and how much it is out by.

I get what you're saying by discarding the data entirely, my site now presents the user with an error message encouraging the user to double check their distances and if possible provide distances to additional referenced stars.

RedWizzard's approach is still sound though, even if there was a typo some of the distances will be correct. We just mark it as bad until further distances are gained. Further distances will highlight which of the data is bad easy enough.

 

[Snuble]

Harbinger, could you provide a distance and coords download too?

 

[TornSoul]

Perfect - That's exactly how I was thinking it.

For the tools to do the "clever stuff", including poking the enduser to "try again".


*re "With 5 supplied distances to reference stars..."
But did you see this one?

Spoiler

RW here is one specifically for you (I got more)

Jurua             75.449
LHS 246          116.532
Nang Ta-khian    120.834
LHS 3006         118.445
Hepa             120.902

Your entry form reports: Coordinates: (-134.625, 33.25, -38.0625)
While the correct coords are : Bhotepa (-134.625, 33.21875, -38.0625)

This is more of a question than a test - As I've already seen what happens

In my case I would throw it all away as unreliable data. But I know you have a different view on this.

My question is - How would you handle a case like this one?
- With regards to the optained coords (which are wrong)
- The submitted distances (which apparently have errors - They don't)

Unlike in the previous example there is error!=0 on more than one distance (so you can't pinpoint one and say that one must be wrong)

Thing is, I can't see a way of systematically categorizing the various error readouts, so that we can accurately (with as close to 100% accuracy as to not make a difference) determine which candidates to keep and which distances to keep - and which not.

Much better, as you've done, to get a human touch to it.

And absolutely use the RMS method to try and guide the user - Every bit helps.
And in special cases like the first I showed - The RMS method accurately picks the wrong distance.
Just not always (as in the 2nd case) - Hence the human touch is needed.

 

[wolverine2710]

As Beta 3 is due out today I've done some updates to my coord calc site to fix some issues I introduced by adding distance checking and not taking into account the user may have supplied less than 9 distances.

I've also added a Contributor field to the form. It now outputs a RedWizzard style JSON output upon request and of course outputs the line to add to System.csv in TradeDangerous.

Perfect. One more tool using the canonical format aka TOR. So far I did use RW's tool but I will give your tool a try when SB3 hits. As in if the Hauler has not been heavily upgraded in prince. Atm a hauler with I better FSD and 40K credits. Somehow aside from crowd sourcing stuff I haven't done much grinding/testing ;-( Hopefully Michael can supply us tomorrow with a new partial list so we don't end up doing to much duplicate work.

Note: Should there be an (incredible) wealthy commander out there who wants to test the private groups functionality (created tickets that it does not work correctly) with me, and part of the test being scooping gold. Please do NOT hesitate to send me a PM ;-)

 

[Harbinger]

Harbinger, could you provide a distance and coords download too?

Depends what you mean by download. Do you mean changing the header so that it downloads the new star json output instead of outputting it to the screen?

Or perhaps the above but a complete RedWizzard style systems.json with your newly found star appended to it?

EDIT: If it was the former, it now offers both display/download of the JSON output upon completion. If you have an old url you can just append &a=1 to the end of it eg:

http://coords.is-found.org/trilat.php?star=WregoeMK-Qb46-1_21-10-2014_20-03-35

becomes

http://coords.is-found.org/trilat.php?star=WregoeMK-Qb46-1_21-10-2014_20-03-35&a=1

It will download as new_system.json

Perfect - That's exactly how I was thinking it.

For the tools to do the "clever stuff", including poking the enduser to "try again".


*re "With 5 supplied distances to reference stars..."
But did you see this one?

Thing is, I can't see a way of systematically categorizing the various error readouts, so that we can accurately (with as close to 100% accuracy as to not make a difference) determine which candidates to keep and which distances to keep - and which not.

Much better, as you've done, to get a human touch to it.

And absolutely use the RMS method to try and guide the user - Every bit helps.
And in special cases like the first I showed - The RMS method accurately picks the wrong distance.
Just not always (as in the 2nd case) - Hence the human touch is needed.

Well my setup currently has the 9 reference stars I use hard-coded but it's certainly possible for me to code a variation to test your provided scenario. I believe RedWizzard's approach would be to mark the star as bad until further distances are gained.

In fact I would go as far as to say that any set of coordinates with too few distances should definitely be flagged as low confidence. Even 5 good distance measurements is not enough for a high confidence set of coordinates from my point of view.

 

[Athan]

Is TGC going to maintain attribution data as well? i.e. for input would we be looking at something like:

{
  "version":1,
  "submitter":{
    "commander":"Athanasius",
    "tool":{
      "name":"Ath's Great Star Tool",
      "version":"0.01"
    },
  },
  "data":{
    "target":"Some System Name",
    "distances":[
      "Some other system":123.456,
      "Some Other system":234.567,
      ...,
      ...,
      ...
    ],
    "co-ordinates":[
      23.125,
      -67.40625,
      8.84375
    ]
  }
}

The idea being to both give people kudos for inputting data, but also to know which tool they used (and version) so that if someone spots an issue with a given tool's data it can be acted upon (ban that version of the tool from further input, mark/purge all data from it, etc).

Note also the inclusion of co-ordinates. Even if TGC is going to trilaterate itself this is another check on the data.

And, of course, this version has, well, a version field. I'm suggesting this be a simple integer, incremented as and when the format changes (possibly on ALL changes, not just backwards incompatible ones).

It would be an error to:

1. Provide less than 5 distances.
2. Not provide the tool's idea of the resultant co-ordinates.
3. Not provide the submitter element, with commander, tool:name and tool:version all present.

Is there anything that people really feel isn't necessary, or that is missing ?

 

[JesusFreke]

I've added you to list1 on the OP. Just used SourceTree to clone your git repository. I'm getting an error when running it.

Python version: Python 3.4.1
Command: python edist.py "C:\Data\Games\Elite Dangerous\RW-3d coords git\systems.json"
Error:
File "edist.py", line 166
print "******************************"
^
SyntaxError: invalid syntax

Not sure what I'm doing wrong.

You need python 2.7, not python 3+

 

[CMDR Generic EventHandler]

C# calculations.

A challenge (I hope)


5 distances to known systems are submitted.
Unfortunately one of the distances has a typo (is wrong)

The challenge:
Can you determine p0
Can you determine which is the wrong distance

Data

	       x 	    y 	              z 	dist
p1	  -6.00000 	 36.28125 	-19.87500 	109.337
p2	 -51.87500 	 16.78125 	 -0.37500 	 67.447
p3	 -45.46875 	 18.56250 	 12.59375 	 79.204
p4	  -1.62500 	 16.81250 	  4.00000 	116.216
p5	 -20.12500 	 19.28125 	 19.00000 	104.498

Here is my results, from my c# implementation

Spoiler

D:\drive\sourcecode\Elite>elite -tricalc p0

Best Guess 2 : -113,25x, 16,78125y, -28,34375z
Confident guess 100.00 %, saved xyz

p0 [-113,25  16,78125  -28,34375]

 --Local Systems :

D:\drive\sourcecode\Elite>elite -xrange p0 p5

p0 => p5 : 104,499Ly

D:\drive\sourcecode\Elite>

I wrote it to only take the best guess, ie there are two combinations of the coordinates that match so it selected that.

My sourcecode is available to look at if you message me, I'm not releasing it until I've refactored it and put a nice UI on it, I really hate doing UI's.

 

[TornSoul]

I was *really really* hoping to have an alpha version of the TGC ready today - But right now I'm feeling how I got up waaaay too early today, so it'll be sometime tomorrow I'm afraid (I'm just not productive right now - dangerous time to code :S)


Idea for rollout:
Alpha version 0.1 :
- bare bones. No extra fields etc (as suggested above by Athan) - Just the very very basics. So we can give it a few test runs, and find if there's a bug or two without it being complicated by too much fluff.
-API URL only published here - and not meant for general consumption yet - Will run of a DB that will be purged later, so feel free to throw crap at it (ie. bogus stars, with reverse engineered distances etc)
-A quick run through on how to use (params etc)

Alpha 0.2: Bolting on some extra fields (easy to do) - Might happen for alpha 0.1, depending on time (So alpha 0.2 could simply roll into alpha 0.1 - we'll see)

Then some back and fro on formats (both input and output) I'm sure.

Once that's reasonable settled I'll make whatever changes and call it a Beta
Beta:
A bit more testing of new features bolted on and possible changed formats etc.
I'll get some API doc's written and published (probably on a temp URL) for people to look at.


Once we are reasonable happy with what we got - We can make it public
Gold:
Fresh DB - populated with whatever data has been gathered so far -and ready to go.

The above phases are probably going to be a bit fluid but just so you have an idea what to expect.

 

[JesusFreke]

Not a Python guy. You are probably right. I can't seem to find any reference by JesusFreke or the git repo about which version of Python is needed. Assumed 3.x. Not sure if I can install Python 2 and 3 alongside each other so I can test his tool. Google awaits....

It's right there in my post. See "Requirements"

- - - - - Additional Content Posted / Auto Merge - - - - -

Thing is, I can't see a way of systematically categorizing the various error readouts, so that we can accurately (with as close to 100% accuracy as to not make a difference) determine which candidates to keep and which distances to keep - and which not.

You would need to get more distances to determine which was bad in that case

 

[Snuble]

Depends what you mean by download.

Just want a dump of gathered coords, to make it easier for me to find empty places in the larger pill. Of course if tgc is up in a couple of days that is not as relevant anymore.

 

[Biteketkergetek]

You need python 2.7, not python 3+

Perhaps you could make it python 3 ready with just

from __future__ import print_function, true_division

at the top. At least that is what I usually do. Then replace / with // for integer division and print xyz with print(xyz) as needed.