Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
I dont think it will stop. There might be system names old etc etc. I dont think you should start over, but you need a way for users (or tools) to say that "This name is wrong", or "This system is cr 5, but coords is wrong", stuff like that. Then someone need to go over that error list at times and give priority to one solution or the other.
Hmm - Clearing the cache implies changes, why else clear it...
So there are changes to the stellar data with G2.04?....
My guess would be:
"Fix an issue with planet classification which should fix the issue with missing stations" from the 2.04 patch notes
Today I've investigated Snuble's screenshot method to gather coordinates from the galaxy map.
It's very easy to extract the vertical (Y) component of the coordinate from a screenshot programmatically, so I focused on XZ instead. Since it is possible to completely eliminate the perspective distortion with GIMP, it is clear that we could just do it, if the grid coordinates could be found automatically.
This is where I am at right now: View attachment 4456 The red dots (zoom in to see them) are where my algorithm thinks there is a grid intersection. They are calculated with subpixel precision. There are some misses and false positives, but there are many 1x1 Ly squares to start work with.
My app is not yet optimized, so it took 5 seconds to process the image using one thread.
Is there any interest in doing preliminary mapping using this technique?
It's very easy to extract the vertical (Y) component of the coordinate from a screenshot programmatically, so I focused on XZ instead. Since it is possible to completely eliminate the perspective distortion with GIMP, it is clear that we could just do it, if the grid coordinates could be found automatically.
This is where I am at right now: View attachment 4456 The red dots (zoom in to see them) are where my algorithm thinks there is a grid intersection. They are calculated with subpixel precision. There are some misses and false positives, but there are many 1x1 Ly squares to start work with.
My app is not yet optimized, so it took 5 seconds to process the image using one thread.
Is there any interest in doing preliminary mapping using this technique?
I assume you have to enter the nearest grid coordinates or something? It seems like that would be the most unreliable part of the process. So it probably makes sense to get the distance to the current system and use that to verify the coordinate that you calculate via the screenshot(s).
This unreliability could be eliminated almost completely using a third screenshot of the star which includes a grid coordinate (so it's top-down view zoomed out, in practice would be taken first). Then the interactive part of an app would ask to click where the coordinates are, zoom in on the coordinate, and ask for the string.
Last edited:
I am not sure it makes sense to work on anymore after getting some sleep either. But it was fun so far.
Entering distances are almost as efficient anyway.You mentioned your DB, and you know the coordinates of the cube, do you use your own app or just use the EDSC interface?
Last edited:
my own database, that connects to EDSC. I practical use I work on 20LY cubes, and get known stars in the 60LY cube around it. Then just make sure I visit all the systems in the 20LY cube. I'm still working on getting a Type 6 with 20LY jumprange tough for real exploring, so only have 2 cubes covered. Exploring so har have been looking for good trades.
I've completed the first part of syncing my systems.json to TGC: I've just submitted 240 systems to TGC. Of those 66 failed to generate coordinates most of which I think are due to having old 3 dp data. @TornSouls, what do you do with 3dp distances? Do you round them to 2dp? Examples:
Code:
Trilateration for LFT 19: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LFT 679: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LFT 747: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LHS 534: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LHS 2211: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LHS 3297: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LP 9-231: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for LP 62-147: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for SZ Ursae Majoris: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for Youdu: 402 Trilateration un-succesful - Found zero candidates.
Trilateration for 36 Draconis: 402 Trilateration un-succesful - Found zero candidates.Ah yes - Did read that, but didn't connect the dots.
I don't round the submitted distances - Which then means the Reverse Distance Check will fail - As the calculated distance *is* rounded to 2dp.
Ie. it will compare say 1.234 to 1.23.
--
Which raises the question: Should I round it to 2dp?
One could argue that a distance with more than 2dp could be a typo - So probably best just to fail...
Then again the API doc actually makes no mention of the precision required (except by example) - I ought to fix that.
The EDSC part does mention 2dp though. But ofc makes no mention of what happens with 3dp or more values.
But what I should fix it to depends on what you guys would prefer with regards to rounding or not?
---
Just checked the DB.
It now has 622 distances with 3dp accuracy.
I'll probably need to clean that up... or?
---
EDIT
Thinking about it a bit.
I'm actually leaning towards rejecting (as an error) distances having more than 2dp (ie. no rounding)
It's definitely inconsistent to have varying levels of accuracy in the distance data in the DB.
And it should be whatever tools responsibility to adhere to the "standard" 2dp, which allows for immediate feedback to the user of the tool - Who can then fix as needed (ie. typos).
Opinions?
Last edited:
Yup, use and enforce 2dp in TGC, and clearly state that tools using the API need to pre-round to that (which actually should never be an issue as they should now only be submitting distances from the in-game galaxy map, RedWizzard's sync up is a special case that he needs to handle his end).
You can't just round them because you can't know if a distance ending in 5 should be rounded up or down. E.g. 6.125 may have been rounded from 6.12499999 (which would be 6.12 with 2 dp) or from 6.1250001 (which would be 6.13 with 2 dp).
I handle it by doing the distance checks with 3dp if the input distance is 3dp (and using 2dp otherwise). Typos are caught anyway because the 3dp distance will almost certainly be wrong if it's a typo. This technique could be extended to checking 1dp distances at that precision (so that nav panel distances could be used), though I haven't tried that. I expect it would simply require more distances to be confident of the solution as more candidate locations would satisfy those reduced-precision distances.
Keep in mind that this data is valid, the fact that we can't re-measure it to the same precision doesn't diminish their accuracy. And I have rechecked all those stars using new reference systems in gamma 1 and they definitely do exist in the same locations as before. Despite that I agree that it's probably easiest to reject anything over 2dp. So I suggest you delete those 3dp distances and I'll resubmit them with 2dp.
Edit: it would actually be easier for me if you delete those systems entirely.
Last edited:
I've got another question on submitting some of the data I have in systems.json to TGC. I've got about 30 systems that were provided by FD prior to gamma (i.e. they were beta reference systems) that I've verified as existing in gamma and checked the coordinates using two new distances. How do you want to handle them? I can submit them using calculated distances (I'm not going to collect distances for them as that'd be a waste of time), or give you a list to load as references, or we can just drop them (though that seems wasteful), or... ?
I'll delete the distances. (*)
And add the 2dp check and corresponding error message to TGC.
And update the API doc to reflect the 2dp only requirement.
(I'll post when I'm done)
(*)
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.
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
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'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.
Last edited:
How could 6.125 be rounded to 6.12499999? Are you referring to the fact many decimal fractions can't be represented as a finite floating point number (such as 0.4 for example?)