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

[wolverine2710]

RedWizzard (two z's this time). I know its probably evening there were you live but would it be possible for you BEFORE you go to sleep to update your "confirmed list" (which I think is at this point is best used as THE reference file) with all the new data found today. For example, change1 , added sytems1 and I believe where others today. Its becoming increasing clear that syncing the lot is at this point THE challenge to beat.

 

[RedWizzard]

How about Federation of Free Traders?

Umm...wait...

I remember that game. They tried to do a dynamic economy where your trading would affect the market. When you bought some goods the price would go up and you could then sell for a profit. You could make as much money as you wanted just sitting in the one place.

 

[wolverine2710]

"Reference list" convertor to a TD sytems.csv

To make testing easier (using TD) I think it would be great to have a convertor which spits out a systems.csv file which can be used to replace the system.csv file as long as NOT everything is stable and NOT all coords are found.

It would mean a temp solution as the <added name> in the generated system.csv file would be what you now use in the systems.json file - "FD beta2". I however DO like what is currently in the system.csv file -the <addname> being the name of the commander. Great for finding back the cmdr for a certain entry in case of issues and crediting. So I hope that in the end for example Smacker can change the <addedname> back into the correct one.

I don't if you perhaps have such a script/program. If so, please do share it. If not AND you do not have time for it ("confirming" takes a lot of time) perhaps another commander could do that Just my 2 euro cent on how to ease testing. Any one has another, most likely better idea?

 

[RedWizzard]

RedWizzard (two z's this time). I know its probably evening there were you live but would it be possible for you BEFORE you go to sleep to update your "confirmed list" (which I think is at this point is best used as THE reference file) with all the new data found today. For example, change1 , added sytems1 and I believe where others today. Its becoming increasing clear that syncing the lot is at this point THE challenge to beat.

Will do. I haven't caught up on today's posts yet. Right now my list is almost unchanged. I found two dupes:
WREDGUIA ZS-0 B47-2
WREDGUIA BT-0 B47-3
And added two new systems whose names I found in JesusFreke's data:
Ross 868
LHS 465
So I'm still at 551.

 

[wolverine2710]

I've found and mapped another 22 systems:

Spoiler

• Wredguia DJ-O B47-1 (-116.8125, 5.71875, -41.59375).
• Wredguia ZC-Q B46-1 (-118.84375, 7, -57.46875).
• Wredguia AZ-H C23-29 (-111.96875, 8.59375, -59).
• Wredguia ZC-Q B46-5 (-114.34375, 11.25, -59.65625).
• Wredguia ZC-Q B46-4 (-114.21875, 15.4375, -62.875).
• Wredguia VW-R B45-0 (-106.1875, 14.1875, -63.9375).
• Wredguia UB-S B45-1 (-102.90625, 18.15625, -68.09375).
• Wredguia UB-S B45-2 (-100.34375, 22.21875, -67.0625).
• Gliese 3050 (-99.71875, 28.09375, -64.15625).
• Wredguia UB-S B45-4 (-98.78125, 32.71875, -66.75).
• Wredguia AD-Q B46-4 (-97.5, 21.9375, -57.21875).
• Wredguia AD-Q B46-3 (-93.4375, 19.59375, -58.53125).
• Wredguia AZ-H C23-25 (-105.71875, 14.6875, -51.28125).
• Wredguia AZ-H C23-6 (-109.625, 12.875, -52.5625).
• Wredguia ZH-Q B46-2 (-80.53125, 22.875, -57.84375).
• Wredguia EJ-O B47-4 (-95.4375, 11.4375, -44.625).
• Wredguia EJ-O B47-1 (-99.09375, 4.5625, -38.875).
• Wredguia EJ-O B47-5 (-90.09375, 6.875, -37.875).
• Wredguia EJ-O B47-3 (-89.4375, 8.5, -33.28125).
• Wredguia BZ-H C23-24 (-82.59375, 8.75, -31.5).
• Ross 676 (-83.1875, 4.84375, -40.8125).
• Trua (-87.46875, 12.9375, -38.3125).

'Wredguia DJ-O B47-1',-116.8125,5.71875,-41.59375,'Test-Harbinger','2014-10-19 05:28:26'
'Wredguia ZC-Q B46-1',-118.84375,7,-57.46875,'Test-Harbinger','2014-10-19 05:40:00'
'Wredguia AZ-H C23-29',-111.96875,8.59375,-59,'Test-Harbinger','2014-10-19 05:47:33'
'Wredguia ZC-Q B46-5',-114.34375,11.25,-59.65625,'Test-Harbinger','2014-10-19 05:52:49'
'Wredguia ZC-Q B46-4',-114.21875,15.4375,-62.875,'Test-Harbinger','2014-10-19 05:58:49'
'Wredguia VW-R B45-0',-106.1875,14.1875,-63.9375,'Test-Harbinger','2014-10-19 06:07:58'
'Wredguia UB-S B45-1',-102.90625,18.15625,-68.09375,'Test-Harbinger','2014-10-19 06:13:28'
'Wredguia UB-S B45-2',-100.34375,22.21875,-67.0625,'Test-Harbinger','2014-10-19 06:18:07'
'Gliese 3050',-99.71875,28.09375,-64.15625,'Test-Harbinger','2014-10-19 06:24:31'
'Wredguia UB-S B45-4',-98.78125,32.71875,-66.75,'Test-Harbinger','2014-10-19 06:35:35'
'Wredguia AD-Q B46-4',-97.5,21.9375,-57.21875,'Test-Harbinger','2014-10-19 06:54:26'
'Wredguia AD-Q B46-3',-93.4375,19.59375,-58.53125,'Test-Harbinger','2014-10-19 07:03:14'
'Wredguia AZ-H C23-25',-105.71875,14.6875,-51.28125,'Test-Harbinger','2014-10-19 07:50:37'
'Wredguia AZ-H C23-6',-109.625,12.875,-52.5625,'Test-Harbinger','2014-10-19 07:54:41'
'Wredguia ZH-Q B46-2',-80.53125,22.875,-57.84375,'Test-Harbinger','2014-10-19 08:34:49'
'Wredguia EJ-O B47-4',-95.4375,11.4375,-44.625,'Test-Harbinger','2014-10-19 09:00:46'
'Wredguia EJ-O B47-1',-99.09375,4.5625,-38.875,'Test-Harbinger','2014-10-19 09:05:36'
'Wredguia EJ-O B47-5',-90.09375,6.875,-37.875,'Test-Harbinger','2014-10-19 09:10:35'
'Wredguia EJ-O B47-3',-89.4375,8.5,-33.28125,'Test-Harbinger','2014-10-19 09:15:03'
'Wredguia BZ-H C23-24',-82.59375,8.75,-31.5,'Test-Harbinger','2014-10-19 09:21:22'
'Ross 676',-83.1875,4.84375,-40.8125,'Test-Harbinger','2014-10-19 09:26:00'
'Trua',-87.46875,12.9375,-38.3125,'Test-Harbinger','2014-10-19 09:30:40'

And found another set of bad coordinates:

'BD+74 938',-106.5625,33.78125,-43.03125,'Test-JesusFreke','2014-10-13 23:00:00'

Should be:

'BD+74 938',-106.59375,33.78125,-43.09375,'Test-Harbinger','2014-10-19 04:44:12'

Verification

Great another 22 systems. If I'm not mistaken we atm have 551-12 (outside pill as described by Smacker) = 539 sytems. 539+22=561 systems. It looks as if this leaves us with approx 9 more. RW estimated 579 - 570+ 9 systems outside the pill. Now where are those 9 systems in our galactic Haystack!?!?

 

[wolverine2710]

Will do. I haven't caught up on today's posts yet. Right now my list is almost unchanged. I found two dupes:
WREDGUIA ZS-0 B47-2
WREDGUIA BT-0 B47-3
And added two new systems whose names I found in JesusFreke's data:
Ross 868
LHS 465
So I'm still at 551.

Perfect.

I hope you all don't mind that much I keep pestering/spamming you all (here and in the TD thread) but atm can't contribute aside from some posts in which I try to coordinate things. The couple (my guests) will wake up soon and then i have to go into 'social mode' again - no forum, no ED. Just trying to achieve that every one can do his/her speciality and focus on that - not wasting time with other non interesting stuff.

 

[RedWizzard]

This post shares some of my observations.
...
TL;DR: Give me 4 digits precision or 5 reference systems

I've got a few comments on this. Apologies if any of this sounds rough, it's not intentional but there is a lot of material so I'm going to speak plainly. As it is it's taken me well over an hour to write this.

Firstly, you seem to have taken the approach of looking for an algorithm that will work in all cases. I think that is the wrong approach. 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.

We don't need 4 decimal places of precision. We've got a lot of empirical data that 3 dp is enough. If fact from JesusFreke's work it seems likely that we could get away with 2 dp or even possibly 1 dp.

I do agree that 5 reference systems are needed, but purely to detect mistakes in data entry. TunaMage was able to get perfect results (by that I mean results that matched everyone else's) with just four well chosen reference systems, but if you made a mistake entering the data there was no way to tell.

Also, one bit of pedantry: Trilateration relies on three distances to generate two sets of candidate coordinates. The fourth distance is only used to pick between the candidates. That's why it's called trilateration and not quadralateration.

Initially I used just 4 reference systems for the trilateration process, and made the 20 possible permutations, to see how they stacked up against each other (doing 1 million tests on random systems)

To verify the accuracy I would pick a random system "p0" from the canonical data coordinates - and then calculate the (exact) distance to 4 other (p1-p4)randomly picked systems (4 being the minimum needed for trilateration to work)
Those distances would be rounded to 3 decimals, before being used for trilateration equations - simulating the accuracy we can get from the Galaxy Map.

The trilaterating process would then spit out some coordinates for p0 that I could then compare to the true coordinates - To verify the accuracy.

The 20 permutations would as a rule not all return the same result, and some would fail to find the coordinates at all (null result) - So which data to use as the "canonical data"?

I assume you mean 24 permutations. You don't need to check them all: the order of the three references that generate the two candidate points should be irrelevant at the precision we require (1/32 Ly). I.e. if we are going to use p1, p2, p3 to generate the two coordinates and p4 to select the final answer then the order of p1, p2, and p3 should not make a difference (once the output is rounded to 1/32 Ly). If it does then you have a mistake in your trilateration algorithm. So with 4 reference stars you have 4 choices for the final verification star and therefore only 4 different combinations to check.

I wanted to double check that the order of the first three references was not important. So I randomly selected 3 references from the FD supplied stars and used them to calculate coordinates for the remaining FD supplied stars in all six combinations. I did this 3300 times for a total of just over 1 million tests (6 million combinations). In about 0.3% of cases the trilateration returns either zero or one coordinate instead of the expected two (degenerate reference star arrangement). I never get more than 2 coordinates (which would indicate that the order was significant).

The really shocking discovery was however that even when *all* 20 permutations returned the exact same coordinates (no null results) - Then these coordinates could *still* be wrong (as compared to the p0 coordinates from the DB).

That shouldn't be shocking. Our trilateration implementations are essentially calculating the intersection between three spheres. But the reality is that the distances are not precise so we should really be intersecting three spherical shells. 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.

So next up was trying with 5 reference systems (distances) and 120 permutations of these - 4 being input to the trilateration process in each of the 120 trilateration runs for that particular p0.

Accuracy back to 3 digits.

This went a lot better - No longer would there be any wrong coordinates.
Again with the demand that all 120 permutations would have to agree (and no null results) to accept the coordinates as "true".

I don't understand why you're using this test. What you're doing is requiring all the combinations of your reference stars produce the right result, so each combination must be a "good" set of references for the target star in their own right. But that doesn't make sense: to get the right result you only need one good set of references. The trick is figuring out which permutation is the good set.

And again, you don't need to check all the permutations as the order of the 3 references used to generate the candidate points is not important. You only need to test C(5, 3) * C(2, 1) = 20 cases (pick 3 stars from 5 to generate the candidate points and then pick 1 star from the remaining 2 to choose the candidate).

It also went a lot worse - As the rejection percentage was now 24%...
But I decided this was a trade-off that would have to be suffered, in order to get correct data.
And in quickly replacing one reference system with another you'll then usually (76%...) get the "true" coordinates - So it's doable.

The reason your rejection percentage has gone up is because the constraints on the arrangement of the reference stars is tougher. But the more restricted arrangement isn't actually telling you anything new.

As mentioned, the trilateration process can return a different result depending on the order in which one plugs in the system distances.
The reason for this being that those are rounded numbers, and some are rounded more than others, and they are put into the calculations at different stages, and thus the result varies.

No, if you're seeing variance in the rounded output based on order of inputs then you have a bug.

For 120 permutations you will sometimes (76% of the time) get the same coordinates spit out 120 times.

Which means the references stars are suitably arranged.

Sometimes you'll get null results however...

Which means the reference stars are degenerate in some way, e.g. they all lie in a plane.

Trilateration really is bad - When we only got 3 digits precision on the distances...

No. Again, you're testing the wrong thing: you're testing for what percentage of random sets of reference stars are suitable for trilateration but that's not relevant because you only need one good set to produce the right results.

I've seen at least 4 different implementations (well 3 implementations produced from the wikipedia article and TunaMage's independent derivation which I'm pretty sure reduces to the same math). We all use different techniques for incorporating additional stars and verifying the output, and still everyone has produced the same results once input typos have been corrected. I really recommend you look at the implementations we've done. If you can find any mistakes in the results (or the implementations) we'd be grateful.

I spend about 2.5 days trying to figure out how to find a measurement for how accurate (trustworthy) a trilateration calculation would be.

In my opinion the best measure of accuracy is how well the distances derived from the calculated coordinates match the input distances. I.e. your input is five distances d1 .. d5 to references p1 .. p5 and your output is p0. 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).

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.

 

[RedWizzard]

Perfect.

I hope you all don't mind that much I keep pestering/spamming you all (here and in the TD thread) but atm can't contribute aside from some posts in which I try to coordinate things. The couple (my guests) will wake up soon and then i have to go into 'social mode' again - no forum, no ED. Just trying to achieve that every one can do his/her speciality and focus on that - not wasting time with other non interesting stuff.

No problem, I'm not feeling pestered

I'm about to add Harbinger's latest set so should have an update in an hour or so.

 

[Smacker]

Old data again My current coordinate matches yours.

I have been through your new data and updated what I can on my TradeDangerous fork. There were a few I couldn't reconcile:

'LP 274-8',-29.71875,45,20.28125,'JesusFreke2','2014-10-18 00:00:00'
'LP 274-8',-29.75,44.9375,20.3125,'Harbinger','2014-10-15 00:00:00'

'Wredguia AT-O B47-0',-103.125,41.9375,-43.25,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA AT-O B47-0',-103.125,41.96875,-43.21875,'Combined','2014-10-13 23:00:00'

'Wredguia PC-D D12-74',-116.46875,35.96875,-19.3125,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA PC-D D12-74',-116.5,35.96875,-19.28125,'Combined','2014-10-13 23:00:00'

'Wredguia XH-Q B46-4',-109.90625,30.6875,-58.65625,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA XH-Q B46-4',-109.9375,30.6875,-58.65625,'Combined','2014-10-13 23:00:00'

'WREDGUIA YD-I C23-11',-128.53125,15.75,-26.65625,'Combined','2014-10-13 23:00:00'
'Wredguia YD-I C23-11',-128.53125,15.84375,-26.46875,'JesusFreke2','2014-10-18 00:00:00'

'WREDGUIA YD-I C23-12',-109.96875,46.75,-45.59375,'Combined','2014-10-13 23:00:00'
'Wredguia YD-I C23-12',-110.03125,46.71875,-45.625,'JesusFreke2','2014-10-18 00:00:00'

'Wredguia ZS-O B47-1',-111.53125,40.3125,-25.21875,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA ZS-O B47-1',-111.53125,40.375,-25.1875,'Combined','2014-10-13 23:00:00'

 

[RedWizzard]

In any case, the 3 suspects are:

LFT 668 <-> Loga. My recorded distance is 64.243, but the closest coord I can find gives a distance of 64.2435019209, just enough that it should round up to 64.244 instead.

HIP 91906 <-> Wredguia UR-Q B46-2. My recorded distance is 19.170, but actual distance using best matching coord is 19.1694999038

Keries <-> Wredguia WH-Q B46-2 131.337 vs 131.336496796

I think we need to resolve these. I'll look into them too.

 

[RedWizzard]

I have been through your new data and updated what I can on my TradeDangerous fork. There were a few I couldn't reconcile:

'LP 274-8',-29.71875,45,20.28125,'JesusFreke2','2014-10-18 00:00:00'
'LP 274-8',-29.75,44.9375,20.3125,'Harbinger','2014-10-15 00:00:00'

'Wredguia AT-O B47-0',-103.125,41.9375,-43.25,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA AT-O B47-0',-103.125,41.96875,-43.21875,'Combined','2014-10-13 23:00:00'

'Wredguia PC-D D12-74',-116.46875,35.96875,-19.3125,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA PC-D D12-74',-116.5,35.96875,-19.28125,'Combined','2014-10-13 23:00:00'

'Wredguia XH-Q B46-4',-109.90625,30.6875,-58.65625,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA XH-Q B46-4',-109.9375,30.6875,-58.65625,'Combined','2014-10-13 23:00:00'

'WREDGUIA YD-I C23-11',-128.53125,15.75,-26.65625,'Combined','2014-10-13 23:00:00'
'Wredguia YD-I C23-11',-128.53125,15.84375,-26.46875,'JesusFreke2','2014-10-18 00:00:00'

'WREDGUIA YD-I C23-12',-109.96875,46.75,-45.59375,'Combined','2014-10-13 23:00:00'
'Wredguia YD-I C23-12',-110.03125,46.71875,-45.625,'JesusFreke2','2014-10-18 00:00:00'

'Wredguia ZS-O B47-1',-111.53125,40.3125,-25.21875,'JesusFreke2','2014-10-18 00:00:00'
'WREDGUIA ZS-O B47-1',-111.53125,40.375,-25.1875,'Combined','2014-10-13 23:00:00'

My calculations give the same coordinates as JesusFreke's. What are your ("combined") coordinates based on? I suspect you have some bad data.

 

[Smacker]

[/spoiler]

Great another 22 systems. If I'm not mistaken we atm have 551-12 (outside pill as described by Smacker) = 539 sytems. 539+22=561 systems. It looks as if this leaves us with approx 9 more. RW estimated 579 - 570+ 9 systems outside the pill. Now where are those 9 systems in our galactic Haystack!?!?

Ok I have those 22 new systems. My count is 561 systems in the Pill

The following 12 are outside:

	Line 23: 'Achenar',67.5,-119.46875,24.84375,'Not Present','2014-10-16 13:51:23'
	Line 35: 'Alpha Cygni',-1405.0,46.09375,132.5,'Not Present','2014-10-16 13:51:23'
	Line 36: 'Alphard',138.84375,88.46875,-73.5,'Not Present','2014-10-16 13:51:23'
	Line 111: 'Enif',-536.59375,-363.03125,236.1875,'Not Present','2014-10-16 13:51:23'
	Line 118: 'Etamin',-132.46875,74.875,25.53125,'Not Present','2014-10-16 13:51:23'
	Line 267: 'LHS 369',9.71875,26.34375,22.15625,'Not Present','2014-10-18 17:17:49'
	Line 354: 'Mirphak',-274.96875,-47.625,-422.65625,'Not Present','2014-10-16 13:51:23'
	Line 395: 'Polaris',-322.6875,194.59375,-212.4375,'Not Present','2014-10-17 10:13:20'
	Line 403: 'Rigel',385.78125,-360.40625,-682.53125,'Not Present','2014-10-16 13:51:23'
	Line 424: 'SDSS J1416+1348',-0.6875,27.15625,12.0,'Not Present','2014-10-17 10:13:20'
	Line 427: 'Sol',0,0,0,'Not Present','2014-10-05 17:49:18'
	Line 438: 'Taran',-42.5,45.46875,-3.0,'Not Present','2014-10-16 13:51:23'

 

[Smacker]

My calculations give the same coordinates as JesusFreke's. What are your ("combined") coordinates based on? I suspect you have some bad data.

I am losing track! I will change those now.

 

[RedWizzard]

I am losing track! I will change those now.

There were some typos in JesusFreke's distance data and I think I recognise some of those names

 

[RedWizzard]

Ok I have those 22 new systems. My count is 561 systems in the Pill

The following 12 are outside:

Line 424: 'SDSS J1416+1348',-0.6875,27.15625,12.0,'Not Present','2014-10-17 10:13:20'
Line 438: 'Taran',-42.5,45.46875,-3.0,'Not Present','2014-10-16 13:51:23'

These two are in the Pill. My numbers match yours: 573 overall. 10 out of the Pill makes 563. Maybe just 7 to go!

 

[RedWizzard]

@Smacker
Can you check your branch of TD has the following corrections. I'm not sure whose branch I grabbed systems.csv from but it looks like kfsone still has the bad data.

Spoiler

Wredguia AT-0 B47-1 should be Wredguia AT-O B47-1
Wredguia AT-0 B47-2 should be Wredguia AT-O B47-2
Wredguia AT-0 B47-3 should be Wredguia AT-O B47-3
Wredguia XH-C23-12 should be Wredguia XI-I C23-12
Wredguia ZS-0 B47-2 should be Wredguia ZS-O B47-2
Wredguia **-Q B46-2 should be Wredguia Y<remove this>H-Q B46-2
Wredguia **-Q B46-3 should be Wredguia Y<remove this>H-Q B46-3
Wredguia BT-0 B47-0 should be Wredguia BT-O B47-0
Wredguia BT-0 B47-3 should be Wredguia BT-O B47-3

59 Draconis should be at (-76.4375, 38.21875, -25.0625)
BD+74 938 should be at (-106.59375, 33.78125, -43.09375)
DX 799 should be at (-22.96875, 12.3125, -17.90625)
HIP 105557 should be at (-113.53125, 41.21875, -45.6875)
HIP 115777 should be at (-107.125, 32.28125, -57.53125)
LHS 3343 should be at (-38.9375, 21.5625, 11.4375)
LP 103-294 should be at (-37.1875, 19, -0.1875)
Nanauatzin should be at (-3.40625, 51.65625, 3.78125)
Ross 1019 should be at (-15, 55.03125, 4.28125)
Wredguia AT-O B47-0 should be at (-103.125, 41.9375, -43.25)
Wredguia PC-D D12-74 should be at (-116.46875, 35.96875, -19.3125)
Wredguia XH-Q B46-4 should be at (-109.90625, 30.6875, -58.65625)
Wredguia YD-I C23-11 should be at (-128.53125, 15.84375, -26.46875)
Wredguia YD-I C23-12 should be at (-110.03125, 46.71875, -45.625)
Wredguia ZS-O B47-0 should be at (-120.40625, 41.46875, -37.90625)
Wredguia ZS-O B47-1 should be at (-111.53125, 40.3125, -25.21875)
Yinfu should be at (-39.9375, 16.1875, -10.6875)
LP 274-8 should be at (-29.71875, 45, 20.28125)

The "<remove this>" bits in there to stop the stupid forum censor from replacing Y H.

Also, if it's not too much hassle, "RedWizzard" has two "z"s.

Thanks!

 

[TornSoul]

I tried your url but I'm getting the following message: "This is not the page you are looking for!". Curious about what is going on.

Fixed.

Very odd... IIS had somehow removed/reverted the changes to "default pages" I had set up....

Hope that doesn't happen again...

 

[TornSoul]

I'd like to take this opportunity to refer back to an idea I had a while back https://forums.frontier.co.uk/showthread.php?p=871846#post871846


Basically: Ask the user to enter their current system, and then give them the name of a system that needs more data. They enter that name into the galaxy map in the game, and then enter the distance into the web app. And then you prompt them with another system name.

This way the user only has to type 2 things per piece of data (not counting the "initial system") - they type the star name into the game, and the distance into the web app. The fewer things someone has to type in, the less of a chance there is to typo something.

I have my own local script to do exactly that for my own data entry, and it works quite well.

The problem with that, as you describe in the linked post, is how to figure out "which systems need more data".

Your solution of having yet another form for simply entering star names I'm not so sure will take off.

If people are interested enough in this kind of thing to start entering star names, I'm sure they'd be interested enough to also enter the distances?

I don't know - To me, it just seems to "muddle the waters" a bit.

Besides - The way EDSC works, there is never any system that will "need more data", as I'm ruthless about rejecting possible bad data.
There won't ever be any systems in the DB that need "fine tuning" of the coordinates (by getting more distances).

 

[TornSoul]

I'm personally calculating the distances back to the source stars with the found set of coordinates to check for input errors now. It's pretty easy to check.

Yeah, that's how I check for errors as well.

I actually have 3 recorded distances that are just *slightly* off with the calculated coordinates. I haven't double-checked the recorded distances yet, but they are extremely close - close enough that it's feasible that it might be a rounding error somewhere, likely due to floating point calculations.

I'm curious, if you've tested if this extra check ever catches anything?
If it does, I'd be interested in the coordinates - To see how my method holds up (I'm suspecting I'd reject it first hand - But would be good to test)

The reason for mentioning this - Is that my tests (with just 4 reference systems) have shown that it's possible to come up with the exact same result for all 20 permutations of the 4 systems - and YET this result is wrong.

 

[Smacker]

@Smacker
Can you check your branch of TD has the following corrections. I'm not sure whose branch I grabbed systems.csv from but it looks like kfsone still has the bad data.

Spoiler

Wredguia AT-0 B47-1 should be Wredguia AT-O B47-1
Wredguia AT-0 B47-2 should be Wredguia AT-O B47-2
Wredguia AT-0 B47-3 should be Wredguia AT-O B47-3
Wredguia XH-C23-12 should be Wredguia XI-I C23-12
Wredguia ZS-0 B47-2 should be Wredguia ZS-O B47-2
Wredguia **-Q B46-2 should be Wredguia Y<remove this>H-Q B46-2
Wredguia **-Q B46-3 should be Wredguia Y<remove this>H-Q B46-3
Wredguia BT-0 B47-0 should be Wredguia BT-O B47-0
Wredguia BT-0 B47-3 should be Wredguia BT-O B47-3

59 Draconis should be at (-76.4375, 38.21875, -25.0625)
BD+74 938 should be at (-106.59375, 33.78125, -43.09375)
DX 799 should be at (-22.96875, 12.3125, -17.90625)
HIP 105557 should be at (-113.53125, 41.21875, -45.6875)
HIP 115777 should be at (-107.125, 32.28125, -57.53125)
LHS 3343 should be at (-38.9375, 21.5625, 11.4375)
LP 103-294 should be at (-37.1875, 19, -0.1875)
Nanauatzin should be at (-3.40625, 51.65625, 3.78125)
Ross 1019 should be at (-15, 55.03125, 4.28125)
Wredguia AT-O B47-0 should be at (-103.125, 41.9375, -43.25)
Wredguia PC-D D12-74 should be at (-116.46875, 35.96875, -19.3125)
Wredguia XH-Q B46-4 should be at (-109.90625, 30.6875, -58.65625)
Wredguia YD-I C23-11 should be at (-128.53125, 15.84375, -26.46875)
Wredguia YD-I C23-12 should be at (-110.03125, 46.71875, -45.625)
Wredguia ZS-O B47-0 should be at (-120.40625, 41.46875, -37.90625)
Wredguia ZS-O B47-1 should be at (-111.53125, 40.3125, -25.21875)
Yinfu should be at (-39.9375, 16.1875, -10.6875)
LP 274-8 should be at (-29.71875, 45, 20.28125)

The "<remove this>" bits in there to stop the stupid forum censor from replacing Y H.

Also, if it's not too much hassle, "RedWizzard" has two "z"s.

Thanks!

OK all checked. The only difference was I had:

'WREDGUIA ZS-O B47-0',-120.40625,41.40625,-37.90625,'Combined','2014-10-13 23:00:00'

Also I corrected your name a while ago. It may take time for the changes to get back