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

wolverine2710

Tutorial & Guide Writer
Reread post up to two days back. Think I was wrong with the new coords. Someone was testing from his station to coords in the MB list. But I found this one. Its post #214. JesusFreke was testing his algorithm and it contains if I'm not mistaken new names/coords.

If you have been able to check all coords I think we have to put something online soon. Otherwise its getting out of hand as to many sources create coords. I'm following this thread (and one two others) like a hawk but I have to admit I'm having problems keeping an overview. Not funny to verify them all. Could be eased if we take the data in TD as a reference and if we could easily check that data in your program. Perhaps some kind of importer to convert the data in TradeDangerous.sql to your .json format.
 
Last edited:

wolverine2710

Tutorial & Guide Writer
Saturday I did a bit of crowd sourcing using codec's spreadsheet. Copied my numbers from his spreadsheet and the results are.

Dziban
Coordinates: (-62.15625, 38.46875, -14.3125)
RMS error: 0.000

nltt 44050
Coordinates: (-57.46875, 38.8125, -21.09375)
RMS error: 0.000

LHS 6354
Coordinates: (-65.28125, 27.34375, -16.125)
RMS error: 0.000

Raw data:
Current system Dziban
---------------------

Distances
System Distance Calculated Error
Sol 74.484 0.002 (ref)
Flousop 66.841 0.005 (ref)
Tring 77.272 0.016
Rahu 33.299 0.016 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-62.03125, 38.5625, -14.59375)
RMS error: 0.002

After entering Parcae RMS was 0.000

Distances
System Distance Calculated Error
Sol 74.486 0.000
Flousop 66.846 0.000 (ref)
Tring 77.256 0.000
Rahu 33.315 0.000 (ref)
Parcae 56.595 0.000 (ref)
Hepa 48.696 0.000
Poqomathi 69.166 0.000
Hyperion 32.942 0.000
Aulin 46.908 0.000
Calculated

Coordinates: (-62.15625, 38.46875, -14.3125)
RMS error: 0.000

Current system nltt 44050
-------------------------

Distances
System Distance Calculated Error
Sol 72.485 0.000 (ref)
Flousop 65.056 0.000
Tring 78.694 0.000 (ref)
Rahu 34.350 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-57.46875, 38.8125, -21.09375)
RMS error: 0.000

Distances
System Distance Calculated Error
Sol 72.485 0.000 (ref)
Flousop 65.056 0.000
Tring 78.694 0.000
Rahu 34.350 0.000 (ref)
Parcae 52.121 0.000
Hepa 51.201 0.000 (ref)
Poqomathi 66.934 0.000
Hyperion 32.235 0.000
Aulin 46.183 0.000
Calculated

Coordinates: (-57.46875, 38.8125, -21.09375)
RMS error: 0.000

Current system LHS 6354
-----------------------

Distances
System Distance Calculated Error
Sol 72.590 0.000 (ref)
Flousop 67.587 0.000
Tring 70.311 0.000 (ref)
Rahu 44.112 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-65.28125, 27.34375, -16.125)
RMS error: 0.000

Distances
System Distance Calculated Error
Sol 72.590 0.000 (ref)
Flousop 67.587 0.000
Tring 70.311 0.000
Rahu 44.112 0.000
Parcae 63.543 0.000 (ref)
Hepa 52.474 0.000
Poqomathi 64.559 0.000 (ref)
Hyperion 24.347 0.000
Aulin 50.429 0.000
Calculated

Coordinates: (-65.28125, 27.34375, -16.125)
RMS error: 0.000

Current system Wredguia xx-o B47-2
----------------------------------

Distances
System Distance Calculated Error
Sol 134.404 0.000 (ref)
Flousop 128.219 0.000
Tring 47.484 0.000 (ref)
Rahu 82.348 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-116.4375, 55.125, -38.3125)
RMS error: 0.000

Distances
System Distance Calculated Error
Sol 134.404 0.000
Flousop 128.219 0.000
Tring 47.484 0.000 (ref)
Rahu 82.348 0.000
Parcae 110.389 0.000
Hepa 107.596 0.000
Poqomathi 46.161 0.000 (ref)
Hyperion 83.618 0.000 (ref)
Aulin 108.251 0.000
Calculated

Coordinates: (-116.4375, 55.125, -38.3125)
RMS error: 0.000

One thing I noticed (see spoiler). I thought I had double checked the Dziban distances but when entering the first four distance I got an RMS error of 0.002. After entering the fifth it was 0.000. This stayed so when I entered all nine distances - had them measured already.

Question: The RMS 0.002 error. Is that always a human error (me) or something else?

Will try to do some more crowd sourcing. I WILL stop the moment I get an RMS error of zero. If I've interpreted your posts correctly, at that point I have enough correct distances. Your entry.html will safe me a LOT of time. Best case always 4 distances instead of 9.
 
Last edited:
If you have been able to check all coords I think we have to put something online soon. Otherwise its getting out of hand as to many sources create coords. I'm following this thread (and one two others) like a hawk but I have to admit I'm having problems keeping an overview. Not funny to verify them all. Could be eased if we take the data in TD as a reference and if we could easily check that data in your program. Perhaps some kind of importer to convert the data in TradeDangerous.sql to your .json format.

I've been thinking about this. The best way to check coordinates for a system is to have the original distance data - then I can just run my algorithm and/or Tunamage's and see if the results match the coordinates we've got. This is essentially the same process as what I've been doing with Michael's data to test the algorithms.

If we don't have the distance data, but only the coordinates calculated by someone else it's much harder to verify. The only thing I can think of is to give a volunteer some distances we calculate from the coordinates to other systems and ask them to check that ED has the same distances. I'll try to put a page together to do that later tonight.

I agree we should try to get something centralised online soon. I think the best option to start with would be a simple web service that records distance data and has an API so people can extract that data. I don't think it even needs a user interface initially: it could just accept json data so people could collect the data with whatever webpage or spreadsheet they like and submit it to the service. Then anyone interested could download the data and run whatever algorithm they like on it. Anyone up for developing something like that? I seem to remember someone offered hosting earlier in the thread. I guess even a spreadsheet on Google docs that we all agree to use would be a starting point.
 
Last edited:

wolverine2710

Tutorial & Guide Writer
IxForres had a web-api in the past. It was connected to Andreas EMDN but also had api-calls to get for example all stations, coordinates etc etc. After FD changed their data access policy he shutdown his service. Perhaps he had suboptimal feelings about it all. Iirc more commanders shut down their service, could be wrong. I certainly had very suboptimal feelings about the FD change. Water down the bridge.

I will write him a PM and ask him if he would be interested in starting his service again. He already has done all the hard work and he has lots of server space and bandwith.

Concerning distances.
  1. Codec has a spreadsheet with coords and distances and an input form. Don't believe he has rounded the results to 1/32 LY though.
  2. I've done some crowd sourcing, results in codec's spreadsheet and in what I posted here. It has distance data in the spoiler tags.
  3. Harbinger has done a lot of crowd sourcing and using his own program to calculate coords. Perhaps he has the distance lying around so we can use them. He also has a website where commanders can input data.
  4. JesusFreke has created his own program and is coords (1/32 LY) and his distance data can be found here.
  5. Don't have a perfect memory, so perhaps others have posted distances here as well. Please do post them.
  6. Thrudd has a trading tool and navigator and I read that he had made a form so users can input distances and/or coords. His web page. Perhaps data has been entered and he can distances.

So I think you have enough distance data to check the coords which now live in TD. What your program needs is a json file with distances which your program can use to check the validity of calculated coords.

And yes ShadowGar has made the offer he had webspace for webbased programs.

Don't have much time to code atm but will try to do what I did so far and write some PM's and trying to coordinate things a bit. WE NEED to get a webpage out there and some common json structure so all tools can use it. Will write more later.

Note: Its remarkable (and frustrating) that we have to jump through so many loops just to get some 3D-coordinates. Now that wtbw is not allowed to extract them and Michael Brookes could only supply us with partial coords. If only the coords were visible in the Galaxy map or whatever. Sorry had to blow off steam.
 
Last edited:
One thing I noticed (see spoiler). I thought I had double checked the Dziban distances but when entering the first four distance I got an RMS error of 0.002. After entering the fifth it was 0.000. This stayed so when I entered all nine distances - had them measured already.

Question: The RMS 0.002 error. Is that always a human error (me) or something else?

I think the problem is the choice of references, specifically Sol and Flousop. Flousop is the closest star in the pill to Sol so when you've only got four distances and two of them are Sol and Flousop you don't have a very good set of references. As soon as you add a fifth reference the algorithm is able to choose a better subset of 3 to generate the candidate coordinates. I'm actually planning to drop Sol down to the bottom of the list to reduce this issue.

I'd recommend entering 5 distances as a minimum. Four distances will always give a pretty low error because the solution is based on those 4 distances (in fact the only reason there is any error is because of the rounding to 1/32 Ly grid). But if the four reference systems are not good choices (as above with Sol, Flousop, Tring, and Rahu) then it might not be the right solution.

I'll extract the contents of that spreadsheet and run them as a batch, so you don't need to do those ones manually if you don't want to. Probably better to put your effort into getting more distances.
 

wolverine2710

Tutorial & Guide Writer
I think the problem is the choice of references, specifically Sol and Flousop. Flousop is the closest star in the pill to Sol so when you've only got four distances and two of them are Sol and Flousop you don't have a very good set of references. As soon as you add a fifth reference the algorithm is able to choose a better subset of 3 to generate the candidate coordinates. I'm actually planning to drop Sol down to the bottom of the list to reduce this issue.

I'd recommend entering 5 distances as a minimum. Four distances will always give a pretty low error because the solution is based on those 4 distances (in fact the only reason there is any error is because of the rounding to 1/32 Ly grid). But if the four reference systems are not good choices (as above with Sol, Flousop, Tring, and Rahu) then it might not be the right solution.

I'll extract the contents of that spreadsheet and run them as a batch, so you don't need to do those ones manually if you don't want to. Probably better to put your effort into getting more distances.

I think I'm to blame here. I've reread Chromatix post about good reference points and he he said, Sol (or Flousop) and then the rest. The 9 CM ref points did sometimes give Harbingers/Snubles routine a fit. He has created his own ref points. See post #259 for details. They are slightly more difficult to input - for me.

Suggestion: Lets use his ref points. That way data submitted can also used by his routine. I will change the points in your .html files I downloaded. Perhaps you can double check his ref points and if you agree you those in a/the next version of your tool. What do you think.
 

wolverine2710

Tutorial & Guide Writer
Some more coords from wredguia.

wredguia ZS-0 B47-2
Coordinates: (-107.78125, 45.84375, -24.90625)
RMS error: 0.000

wredguia EZ-M B48-3
Coordinates: (-98.90625, 39, -12.5)
RMS error: 0.000

wredguia AT-0 B47-3
Coordinates: (-97.1875, 56.75, -26.625)
RMS error: 0.000

wredguia AT-0 B47-2
Coordinates: (-97.96875, 58.46875, -28.65625)
RMS error: 0.000


wredguia AT-0 B47-1
Coordinates: (-96.71875, 52.75, -32.1875)
RMS error: 0.000

wredguia XH-C23-12
Coordinates: (-92.875, 58.15625, -34.25)
RMS error: 0.000


wredguia UR-Q B46-2
Coordinates: (-97.78125, 56.875, -49.75)
RMS error: 0.000

Raw data with distances:
current system: wredguia ZS-0 B47-2

Distances
System Distance Calculated Error
Sol 119.745 0.000
Flousop 113.787 0.000
Tring 46.500 0.000 (ref)
Rahu 70.564 0.000 (ref)
Parcae 100.396 0.000 (ref)
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-107.78125, 45.84375, -24.90625)
RMS error: 0.000

current system: wredguia EZ-M B48-3

Distances
System Distance Calculated Error
Sol 107.050 0.000 (ref)
Flousop 101.134 0.000
Tring 53.187 0.000 (ref)
Rahu 61.140 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-98.90625, 39, -12.5)
RMS error: 0.000

current system: wredguia AT-0 B47-3

Distances
System Distance Calculated Error
Sol 115.650 0.000 (ref)
Flousop 108.005 0.000
Tring 59.014 0.000 (ref)
Rahu 59.835 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-97.1875, 56.75, -26.625)
RMS error: 0.000

current system: wredguia AT-0 B47-2

Distances
System Distance Calculated Error
Sol 117.634 0.000
Flousop 109.926 0.000
Tring 59.347 0.000 (ref)
Rahu 61.310 0.000 (ref)
Parcae 90.660 0.000 (ref)
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-97.96875, 58.46875, -28.65625)
RMS error: 0.000

current system: wredguia AT-0 B47-1

Distances
System Distance Calculated Error
Sol 114.774 0.000 (ref)
Flousop 107.907 0.000
Tring 54.229 0.000 (ref)
Rahu 62.580 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-96.71875, 52.75, -32.1875)
RMS error: 0.000

current system: wredguia XH-C23-12

Distances
System Distance Calculated Error
Sol 114.808 0.000 (ref)
Flousop 107.233 0.000
Tring 60.099 0.000 (ref)
Rahu 59.871 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-92.875, 58.15625, -34.25)
RMS error: 0.000

current system: wredguia UR-Q B46-2

Distances
System Distance Calculated Error
Sol 123.576 0.000 (ref)
Flousop 117.218 0.000
Tring 54.854 0.000 (ref)
Rahu 73.466 0.000 (ref)
Parcae
Hepa
Poqomathi
Hyperion
Aulin
Calculated

Coordinates: (-97.78125, 56.875, -49.75)
RMS error: 0.000

I think thats it for today. Getting tired and making mistakes. To much copy/paste. Looking forward to your next version, especially the entry.html one. Hopefully less copy paste for me.....
 
If we don't have the distance data, but only the coordinates calculated by someone else it's much harder to verify. The only thing I can think of is to give a volunteer some distances we calculate from the coordinates to other systems and ask them to check that ED has the same distances.
I have added a command to TradeDangerous to do this (currently being merged back). You can add the coordinates to the SQL list and get TD to output the distances to compare them directly to EDs navigation list. I have been doing this for JesusFreke's data (see above)

Output looks like this:

Code:
Local systems to HERMITAGE within 12.0 ly.
------------------------------------------
 4.29 LHS 3281
 5.09 WOLF 654
 7.20 LP 275-68
 7.71 TILIAN
 9.48 LHS 3262
 9.77 ZETA HERCULIS
 9.92 LHS 6309
10.21 LHS 457
10.31 G 181-6
10.32 KERIES
10.36 AUSTERN
10.36 DN DRACONIS
10.81 OPALA
10.88 LHS 3343
10.98 CONNLA
11.08 OVID
11.48 CAER BRAN
 

Harbinger

Volunteer Moderator
I should have really logged my input/output so that my results could be independently verified. Sorry about that.

I only have the details from the last system I tested currently if someone wants to error test that:

LP 378-541 input:
  • SOL = 20.885
  • WOLF 497 = 22.898
  • HUOKANG = 34.053
  • DEMETER = 60.223
  • CLOTTI = 93.45
  • FU HAITING = 88.01
  • SAN GUARALARU = 142.056
  • HARAS = 122.429
  • ARABHA = 126.489

Script output

I'll log all the input/output from here on out and provide a link for a json output so that others can easily import the data into their own tools.
 
Last edited:
Some more coords from wredguia.

wredguia ZS-0 B47-2
Coordinates: (-107.78125, 45.84375, -24.90625)
RMS error: 0.000

wredguia EZ-M B48-3
Coordinates: (-98.90625, 39, -12.5)
RMS error: 0.000

wredguia AT-0 B47-3
Coordinates: (-97.1875, 56.75, -26.625)
RMS error: 0.000

wredguia AT-0 B47-2
Coordinates: (-97.96875, 58.46875, -28.65625)
RMS error: 0.000


wredguia AT-0 B47-1
Coordinates: (-96.71875, 52.75, -32.1875)
RMS error: 0.000

wredguia XH-C23-12
Coordinates: (-92.875, 58.15625, -34.25)
RMS error: 0.000


wredguia UR-Q B46-2
Coordinates: (-97.78125, 56.875, -49.75)
RMS error: 0.000


I think thats it for today. Getting tired and making mistakes. To much copy/paste. Looking forward to your next version, especially the entry.html one. Hopefully less copy paste for me.....
Thanks I have snagged those for TradeDangerous as well.
 

wolverine2710

Tutorial & Guide Writer
I have added a command to TradeDangerous to do this (currently being merged back). You can add the coordinates to the SQL list and get TD to output the distances to compare them directly to EDs navigation list. I have been doing this for JesusFreke's data (see above)

Output looks like this:

Code:
Local systems to HERMITAGE within 12.0 ly.
------------------------------------------
 4.29 LHS 3281
 5.09 WOLF 654
 7.20 LP 275-68
 7.71 TILIAN
 9.48 LHS 3262
 9.77 ZETA HERCULIS
 9.92 LHS 6309
10.21 LHS 457
10.31 G 181-6
10.32 KERIES
10.36 AUSTERN
10.36 DN DRACONIS
10.81 OPALA
10.88 LHS 3343
10.98 CONNLA
11.08 OVID
11.48 CAER BRAN

I saw your pull request in the TD repository. Wondered where it could be used for. Now I know. It basically is the same output as the navigation menu. The accuracy there is 2 decimals. It allows for very fast verification for 3D coordinates for which we don't have distances for. Hence can't be independently proved by other tools.

As the 3D coordinates from wtbw and Michael Brookes are 5 decimals you round it to two decimals. Would it be possible for you to add a flag which allows one to specify the number of decimals. Just in case some one want to use the galaxy map for verification - which has 3 decimals.

Does this mean you have checked all data by JesusFreke and its considered accurate.
As I wrote in his spreadsheet he has distances so for example RW CAN verify its validity.
 

wolverine2710

Tutorial & Guide Writer
Thanks I have snagged those for TradeDangerous as well.

ShadowGar wote kfsone has given him write access to the TD repository - for updating the TradeDangerous file. Questions:
  1. Is the sql already been updated?
  2. If not do you have an idea when that could be done?
 
New version of my stuff is up with changes to the entry.html page (here).

I changed the default reference systems. You can also add additional reference systems.
The "Calculated" section includes a table of the 5 systems from Michael's list that are closest to the calculated coordinates. This can be used to quickly verify the coordinates are right via the HUD.
The input distances and calculated coordinates can be displayed as a JSON block so you can quickly copy what you've entered and transfer it to a file. The JSON data persists until you reload the page so you can keep adding systems to it. Basically the workflow is this:
1. Enter the system name and distances
2. (optional) If you've screwed it up completely you can hit "Cancel" to reset the form
3. Once you're happy with the data hit the "Done" button to transfer it to the JSON output (which is hidden by default). The "Done" button will reset the form so you can add another system
4. Repeat 1 and 2 until you've had enough
5. Hit the "Show JSON" button, click anywhere in the JSON data to select it all, then copy and paste it to a file

The "Done" button will only be enabled if you've entered at least 4 distances and the system name.
 

wolverine2710

Tutorial & Guide Writer
I should have really logged my input/output so that my results could be independently verified. Sorry about that.

I only have the details from the last system I tested currently if someone wants to error test that:

LP 378-541 input:
  • SOL = 20.885
  • WOLF 497 = 22.898
  • HUOKANG = 34.053
  • DEMETER = 60.223
  • CLOTTI = 93.45
  • FU HAITING = 88.01
  • SAN GUARALARU = 142.056
  • HARAS = 122.429
  • ARABHA = 126.489

Script output

I'll log all the input/output from here on out and provide a link for a json output so that others can easily import the data into their own tools.

As requested I've checked it with RW's tool. It had a zero error after 4 distances. Supplied all 9 distances. Output of RW's tool with 4 and 9 distances:
Distances
System Distance Calculated Error
Sol 20.885 0.000 (ref)
Wolf 497 22.898 0.000
Huokang 34.053 0.000 (ref)
Demeter 60.223 0.000 (ref)
Clotti
Fu Haiting
San Guaralaru
Haras
Arabha
Calculated

Coordinates: (1.1875, 20.71875, 2.34375)
RMS error: 0.000


Distances
System Distance Calculated Error
Sol 20.885 0.000 (ref)
Wolf 497 22.898 0.000
Huokang 34.053 0.000
Demeter 60.223 0.000
Clotti 93.450 0.000
Fu Haiting 88.010 0.000 (ref)
San Guaralaru 142.056 0.000 (ref)
Haras 122.429 0.000
Arabha 126.489 0.000
Calculated

Coordinates: (1.1875, 20.71875, 2.34375)
RMS error: 0.000

Outputs:
HB: LP 378-541: 1.187879, 20.719592, 2.343413.
HB 1/32 : LP 378-541: 1,18750 20,71875 2,34375
RW 1/32 : LP 378-541 1.1875, 20.71875, 2.34375

Changed your 6 decimals NOT 1/32 grid output to 5 decimals 1/32 grid output.
As expected a 100% match. Great ;-)

Two questions:
  1. At least for this example your output is 6 decimals. May I ask why?
  2. Your output is not 1/32 LY grid rounded. May I ask why?
 
Last edited:
I saw your pull request in the TD repository. Wondered where it could be used for. Now I know. It basically is the same output as the navigation menu. The accuracy there is 2 decimals. It allows for very fast verification for 3D coordinates for which we don't have distances for. Hence can't be independently proved by other tools.

As the 3D coordinates from wtbw and Michael Brookes are 5 decimals you round it to two decimals. Would it be possible for you to add a flag which allows one to specify the number of decimals. Just in case some one want to use the galaxy map for verification - which has 3 decimals.

Does this mean you have checked all data by JesusFreke and its considered accurate.
As I wrote in his spreadsheet he has distances so for example RW CAN verify its validity.
Yes, I can add a decimal places option quite easily. I have only tested 3 of JesusFreke's systems so far (see above) they are not bad, but not spot-on (max error was 0.4 ly). I will try to do more tonight.
 
Note: Its remarkable (and frustrating) that we have to jump through so many loops just to get some 3D-coordinates. Now that wtbw is not allowed to extract them and Michael Brookes could only supply us with partial coords. If only the coords were visible in the Galaxy map or whatever. Sorry had to blow off steam.

Well, I would like to say thanks Wolverine for all the effort you are putting into pulling this all together.

I'm not sure if I speak for the others in this thread, but I'm finding the challenge of working through the difficulty of getting the coords reliably together quite fun. It definitely adds a new dimension to the game for me, and ED wouldn't be ED without a bit of a challenge :D
 

Harbinger

Volunteer Moderator
Two questions:
  1. At least for this example your output is 6 decimals. May I ask why?
  2. Your output is not 1/32 LY grid rounded. May I ask why?

I believe the result that comes back from Snuble's trilateration function is rounded to 5 decimal places.

To be honest I'm not sure why I used 6 decimal places on the averaged value. ;)

I can't say I really understand all this 1/32 talk. Are you saying it would be better to use 3 decimal places from both the trilateration function and the final averaged output?

EDIT: By the way I've been doing some work on the script I've been using. It now stores the info and allows users to view the data in either formatted array or JSON format for easy import into other tools:

LP 378-541 Test (Formatted Array)
LP 378-541 Test (JSON output)
 
Last edited:

wolverine2710

Tutorial & Guide Writer
New version of my stuff is up with changes to the entry.html page (here).

I changed the default reference systems. You can also add additional reference systems.
The "Calculated" section includes a table of the 5 systems from Michael's list that are closest to the calculated coordinates. This can be used to quickly verify the coordinates are right via the HUD.
The input distances and calculated coordinates can be displayed as a JSON block so you can quickly copy what you've entered and transfer it to a file. The JSON data persists until you reload the page so you can keep adding systems to it. Basically the workflow is this:
1. Enter the system name and distances
2. (optional) If you've screwed it up completely you can hit "Cancel" to reset the form
3. Once you're happy with the data hit the "Done" button to transfer it to the JSON output (which is hidden by default). The "Done" button will reset the form so you can add another system
4. Repeat 1 and 2 until you've had enough
5. Hit the "Show JSON" button, click anywhere in the JSON data to select it all, then copy and paste it to a file

The "Done" button will only be enabled if you've entered at least 4 distances and the system name.

Darn you are fast. You seem to have read my mind: clear form and JSON output. Tested it a bit. Here a my results.

  1. Additional sytems: I have an other field where I can put in a new reference point. I can't add multiple new reference points.
  2. JSON output. Had to RTFM before it worked. Had to press DONE first.
  3. DONE. Clears form and enables JSON output. When experimenting (with JSON outpu) I personally don't like it be cleared and like to get JSON output without pressing DONE - when name and 4 distances are entered. But that just me, can work/live with it.

Made some change in checkall.html.
  1. Put systems systems.json in my dropbox account. Changed $.getJSON('systems.json') into $.getJSON(',<dropbox url of systems.json>'). Works. Great for when system.json file is for example stored (and updated) on webpage of for example Harbinger.
  2. Added LP 378-541 coords to systems.json - multiplied calculated coords by 32. In real and calculated colums my entered data was shown with an error of 0. After that changed X coordinate so it was totally wrong. Again real and calc colums showed my input and error zero. CURIOUS about this. Could you elaborate?

I like the JSON output. Suggestion: Atm the coords in TD have to manually inserted with insert statement like: INSERT INTO "System" VALUES(61,'Nyon T''ao Wujin',-81.71875,58.8125,-35.28125,'2014-10-02 14:21:15');. Its Nyon T'ao Wujin (1 ' character) but double '' here for escaping. It would be nice to have an optional output like that also for easy entering. BUT it could of course be done by a separate program, not created by you.

Your tool is ready for crowd sourcing imho. We are ALMOST there to get the lot automized with a central list and web-api for uploading. This will another post. Have to get bandaid to stop my fingers from bleeding all over the keyboard now ;-)
 

Harbinger

Volunteer Moderator
Could someone elaborate on the 1/32 rule?

Do you just need to multiply the inputted distances by 32 and then divide the coordinates by 32?
 
Back
Top Bottom