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

6.125 is itself a rounded value.

It could have been 6.1251 which should then be rounded to 6.13
or it could have been 6.1249 which should then be rounded to 6.12

There's no way to know from the value 6.125 itself
 
Last edited:
TGC is updated (with 2dp requirement) and likewise the API doc.

I've yet to delete the distance data.

I have a count of 2734 distances submitted - That I suspect are from you rw (includes both 2dp and 3dp distances).
I can't be 100% sure, as you've credited the original submitters - But they all fall in the same time span.

Could you confirm that count before I do anything please.

I'll confirm tonight (in about 12 hours). Though wouldn't it be safe to just delete the 3dp ones? It won't make any difference to me if only some of the distances are deleted.
 
I'm not deleting the systems - as that kinda gets complicated, as they might be referenced by other distances etc.
And it shouldn't affect your submissions anyhow as far as I can tell.
Simply run whatever routine you ran before - TGC will handle if systems are already in the DB (with or without coords) or not.

My code compares the systems in TGC to the systems in systems.json and submits any missing ones so running it again won't submit anything if the systems in question are still in TGC. I'm not currently checking to see if the distance data is the same. But I need to write that bit anyway and I have a log of what I submitted so I'll sort it out one way or the other.

Simply submit the distances that you have.
This achieves:
- The systems get stored in the DB
- The distances get stored in the DB

The amount of distances might not be enough to get coords - But over time other distances should naturally get added to rectify that.

I'm still waiting to see a tool that will "datamine" for systems just needing a couple more distances to be determined - and then post that list to users to go hunt for :D

I don't have any distances for those systems in systems.json - their locations were provided by FD so I didn't see any benefit to keeping the distances I checked. I can generate distances for them, but that feels a little like subverting the process. I'd prefer they were treated the same as the gamma references and loaded with coordinates but no distances. They're actually better references than the gamma references because I've checked them while the gamma references have proven to contain mistakes (at least in naming).

A tool like that is on my list of things to do. Not sure when I'll get to it though. I want to write some code to suggest useful distances first so that my system entry page can say something like "if you provide the distance to X we should be able to confirm the location for this system", i.e. analyse the data and figure out which distances would confirm or reject a candidate location. Once I have that then a system that can ask for specific distances from your current location to fill in the missing data would be pretty straight forward. I don't want to ask for distances that won't help so I need to do the above bit first.
 
I'll confirm tonight (in about 12 hours). Though wouldn't it be safe to just delete the 3dp ones? It won't make any difference to me if only some of the distances are deleted.
Sure - I'll delete just the 3dp ones then.
Won't be right now though - As I was just checking this before heading to bed.
But if you need to write/fix any code you can do so with the assumption that the 3dp distances will be removed.

(FYI) If any of those distances resulted in a new System being added to TGC (with or without coordinates) then that system stays in the DB

I don't have any distances for those systems in systems.json - their locations were provided by FD so I didn't see any benefit to keeping the distances I checked. I can generate distances for them, but that feels a little like subverting the process. I'd prefer they were treated the same as the gamma references and loaded with coordinates but no distances.
I'll need to do that manually then (well write a script to do it).
That however requires that I have that specific data.

Could you compile it into something that I can easily parse and create SQL statements from - and attach the file to a reply here?

Of to bed now.
 
Could you compile it into something that I can easily parse and create SQL statements from - and attach the file to a reply here?

Thanks, here's the data: View attachment 4638
It's a csv with name, x, y, z, contributor (always FD), and source (Beta1/2/3). Name, contributor, and source are surrounded with double-quotes. Should be easy to convert to sql. I put source in there just in case you want to use it to make it clear where these came from (e.g. by setting commandercreate to something like "FD Beta 1"). Probably not much point though.

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

The 622 3dp distances have been deleted.

Thanks. I'm just writing the code to compare differences now so should will get those distances resubmitted with 2dp shortly.
 
Last edited:
Confirmed

The other one is the one from MBs Gamma list (correct coords) - Don't know why I didn't check the coords before...

So yeah - There's a 12 Aquarii

at both [-57.0625, 57.03125, 68.8125] (MBs Gamma list )
and
"Duplicate" : [-295, -270, 303] (GM map)


Duplicate names are *very very very* bad......

Just for info, from the latest MB list I cleared all the stale data and only used the new data.

12 Aquarii isn't in the list.

Doing a search in my system gives.

Elite -lsys 12A



12 Andromedae [-123.46875 -49.625 -32.09375]

--Local Systems : Auakereks 9.71Ly, Dallenja 13.03Ly, Dazhbogati 17.19Ly, HIP 113076 16.33Ly, HIP 113535 16.87Ly, HIP 115277 6.81Ly, HIP 115473 19.5Ly, HIP 115610 13.08Ly, HIP 118251 18.93Ly, HR 8718 15.41Ly, HR 8977 11.63Ly, Keinjayano 15.63Ly, Kwiambojawa 15.88Ly, Lungundani 12.47Ly, Mindji 13.57Ly, Ngolite 16.1Ly, Nu Guang 10.8Ly, Nyalo 12.81Ly, Ongkarango 18.52Ly, Qi Yi 15.54Ly, Sivaci 14.99Ly, Snoqui 17.37Ly, Tamali 16.34Ly, Tvasu 15.28Ly

--==Press a key==--

So 12 Aqui isn't present in the MB list (the spreadsheet at the start of gamma).

GE.
 
Just for info, from the latest MB list I cleared all the stale data and only used the new data.

12 Aquarii isn't in the list.

Doing a search in my system gives.

Elite -lsys 12A



12 Andromedae [-123.46875 -49.625 -32.09375]

--Local Systems : Auakereks 9.71Ly, Dallenja 13.03Ly, Dazhbogati 17.19Ly, HIP 113076 16.33Ly, HIP 113535 16.87Ly, HIP 115277 6.81Ly, HIP 115473 19.5Ly, HIP 115610 13.08Ly, HIP 118251 18.93Ly, HR 8718 15.41Ly, HR 8977 11.63Ly, Keinjayano 15.63Ly, Kwiambojawa 15.88Ly, Lungundani 12.47Ly, Mindji 13.57Ly, Ngolite 16.1Ly, Nu Guang 10.8Ly, Nyalo 12.81Ly, Ongkarango 18.52Ly, Qi Yi 15.54Ly, Sivaci 14.99Ly, Snoqui 17.37Ly, Tamali 16.34Ly, Tvasu 15.28Ly

--==Press a key==--

So 12 Aqui isn't present in the MB list (the spreadsheet at the start of gamma).

GE.

It's definitely in Michael's spreadsheet. Cell B4430. Post #1449 in this thread if you want to check.
 
Thanks, here's the data: View attachment 4638
It's a csv with name, x, y, z, contributor (always FD), and source (Beta1/2/3). Name, contributor, and source are surrounded with double-quotes. Should be easy to convert to sql. I put source in there just in case you want to use it to make it clear where these came from (e.g. by setting commandercreate to something like "FD Beta 1"). Probably not much point though.

The systems have been inserted.
With cr=5
And createdby/updatedby = FD
"source" is ignored.
 
Last edited:
It's definitely in Michael's spreadsheet. Cell B4430. Post #1449 in this thread if you want to check.
Yup - Definitely there.


Just for info, from the latest MB list I cleared all the stale data and only used the new data.

Stale data? How do you define that - and what "new" data?
MBs Gamma list *is* the new(est) data.

In MBs Gamma list there is a handful of test systems, and 7 duplicate names (which have since been renamed ingame)

But "stale" data???
 
Systems.json has been synced to TGC, including distances for existing systems. There are still a few cases to resolve (mostly duplicate systems in TGC - in these cases I haven't submitted any new data yet), will look at the later.

@TornSoul have you thought about doing a status page? It'd be quite nice to see some stats on how many systems we've got in TGC.

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

The systems have been inserted.
With cr=5
And createdby/updatedby = FD
"source" is ignored.

Great, thanks. Just headed to bed now, will talk to you tomorrow about the few data anomalies I found (I'm sure we don't want to get into manually fixing up data but it's probably worth talking about whether there is some way to automatically handle them).
 
Yup - Definitely there.




Stale data? How do you define that - and what "new" data?
MBs Gamma list *is* the new(est) data.

In MBs Gamma list there is a handful of test systems, and 7 duplicate names (which have since been renamed ingame)

But "stale" data???

The co-ords from beta, I started fresh with the spreadsheet. Just scanning trough the .csv that I used to import I don't have 12 Aquarii in there either.. I'll go back to the spreadsheet and re-import.

Thanks.
 
I've just found two duplicate names in the DB.
All stemming from (naturally...) the manual changes I've been doing.

If you're renaming that one then you should probably rename the one I mentioned a couple of days ago as well: Hydrae Sector IR-W b1-0 -> Crucis Sector ER-V b2-0. And also Crucis Sector IW-W b1-1 -> Paiphu.

Turns out Paiphu had already been "re-discovered" so was already in the system.
So as I did the renaming - I made a duplicate.
Lesson learned - always check if names already exist if manually renaming.

Distances have been updated to point to the correct Paiphu - and the other Paiphu has been deleted.


The systems have been inserted.
With cr=5
And createdby/updatedby = FD
"source" is ignored.
Gah - Another duplicate in this set "WISE 1647+5632"
Same story as above...
Thankfully no distances to this newly inserted (and wrong) "WISE 1647+5632" - Which have been deleted again.

Meh what a mess...

Not sure what this does to toolmakers out there - As there is no mechanism to discover deletions.... "as that was never supposed to happen" ("Oh - Hi Murphy" :D)
 
Great, thanks. Just headed to bed now, will talk to you tomorrow about the few data anomalies I found (I'm sure we don't want to get into manually fixing up data but it's probably worth talking about whether there is some way to automatically handle them).

FYI: I've found some more systems I had submitted earlier in gamma that now have a different name. I'll go through and try to get at least one or two more distances for all the stars I've submitted, and report any inconsistencies. 400 stars.. ugh!

(Edit: I mean 400 stars to check, not 400 incorrect stars :))
 
Last edited:
Gah - Another duplicate in this set "WISE 1647+5632"
Same story as above...
Thankfully no distances to this newly inserted (and wrong) "WISE 1647+5632" - Which have been deleted again.

You didn't accidentally delete both did you? I can't find it using a name or coordsphere jsfiddle. It was IDs 21086 and 21099 . I was trying to find which you kept so as to delete the other from my DB.
 
ID 21086 is still in the DB.

aaah - with CR 1 however....

I'll bump it to 5.

Done.


EDIT

You wouldn't happen to be querying the test DB? (I just did that myself :D)
The changes won't be in there until it replicates in 4-5 hours
 
Last edited:
Back
Top Bottom