Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
The previous one didn't work for me (with one of the coordinates that RedWizzard mentioned). This one doesn't work for at least:
Wredguia WH-Q B46-2 <-> keries
Recorded Distance from game: 131.337
Coords:
Wredguia WH-Q B46-2: -97.781250 56.875000 -49.750000
Keries: -18.90625 27.21875 12.59375
Actual calculated distance: 131.336496796
round 6: 131.336497
round 3: 131.336
Last edited:
For those coords I get a distance of 104.821286... :S
I've added a log to my ticket. It's pretty clear from the log that something has gone wrong on the server end and it has stopped responding.
I noticed the spelling that the log uses for these generated systems:
Wredguia LW-E d11-129
Wredguia XH-Q b46-4
I'm going to adopt that pattern in my lists.
Here are some test coordinates, that I've found in my random testing.
Currently my program does not catch these and reports a wrong p0 value (working on fixing that somehow - Lots still to try - So I'm hopeful)
Code:p0 -134.625 33.21875 -38.0625 0.000 p1 -101.09375 11 -24.09375 42.581 p2 -33.5625 33.125 13.46875 113.442 p3 -12.125 26 22.875 137.010 p4 -17.71875 19.125 19.59375 131.110 p5 -21.34375 22.375 16.25 126.096
My algorithm found the solution within 420000 "steps". Normal for a "well specified" star is under 1000, and I usually let it run for 60000 before giving up.
But it did eventually only find a single grid-aligned point within the candidate region, which matched the p0 coordinate you gave.
This is likely due to a very long, narrow, needle-like candidate region. Or possibly a very flat region. Basically, the region has a very large surface area, but very little actual volume, meaning it's spread out very thin in at least 1 dimension. Thin enough that it manages to squeeze between the grid points without encompassing them (except for the 1 true coordinate)
150000 steps for this one. But it still found the coordinate
Only 20000 steps for this one.
130000 steps for this one
240000 steps for this one
370000 steps for this one
110000 steps for this one.
So, I was able to find the correct coordinate in all cases if I let it run long enough, although in most cases I would have normally given up and just got more data for that star.
And when I say "steps", that is a measure of the number of grid-aligned points that my algorithm evaluated while trying to map out the candidate region. Basically, it's a measure of the size of the candidate region.
But it did eventually only find a single grid-aligned point within the candidate region, which matched the p0 coordinate you gave.
This is likely due to a very long, narrow, needle-like candidate region. Or possibly a very flat region. Basically, the region has a very large surface area, but very little actual volume, meaning it's spread out very thin in at least 1 dimension. Thin enough that it manages to squeeze between the grid points without encompassing them (except for the 1 true coordinate)
150000 steps for this one. But it still found the coordinate
Only 20000 steps for this one.
130000 steps for this one
240000 steps for this one
Only ~15000 steps for this one
370000 steps for this one
110000 steps for this one.
So, I was able to find the correct coordinate in all cases if I let it run long enough, although in most cases I would have normally given up and just got more data for that star.
And when I say "steps", that is a measure of the number of grid-aligned points that my algorithm evaluated while trying to map out the candidate region. Basically, it's a measure of the size of the candidate region.
Here are some test coordinates, that I've found in my random testing.
Currently my program does not catch these and reports a wrong p0 value (working on fixing that somehow - Lots still to try - So I'm hopeful
I would be interested in hearing if the rest of you catch these.
If not - It's some good test cases to tweak your program with.
If yes: Would be interested in hearing how you catch them
Let me know how it works out for you.
All caught: all of them produce p0 estimates which show significant errors.
There is something to consider here though. All of this data is good data that your tool would throw away. Three of those sets of distances are for the same star and while each set can't locate the star by itself it is very easy to locate the star using all 15 references. I only had to add one distance from the 2nd set to the first set to correctly locate it. I think it's worth considering whether discarding the data in these cases is the right option.
You must have a typo somewhere, it's definitely 131.336.
Impressive. My Sag A* search is basically the lazy man's version of your algorithm: I get a reasonable approximation via trilateration and then search nearby. Your search is much more efficient because it's only searching the true candidate area. Bet it was a lot harder to write though!
In the case of Sag A* the shape of the overlap of the shells is basically a plane in the xy axes. The z coordinate is quite constrained. Eye-balling it puts it at about (25.25, -21, 25900) so even the trilateration result (25.46875, -20.90625, 25899.96875) seems pretty close. But I can't find an exact match in 10x10x10 Ly cube around that point. So I suspect that the ED distance bug is occurring here too.
http://jsfiddle.net/8kom5mj4/
Sorta seems to fit what you are saying.
Although I'd think that p1(black) would minimize the area by a good bit, as that sphere should get close to orthogonally cut the spheres of p2(green) and p3 (orange).
Kinda hard to eyeball though
But it's interesting to see that the coords gave your algorithm a rather good workout
PS : The fiddle: It's easy to copy/paste more points in there (and change the axis etc) - I've had the whole pill in there - Just for the heck of it
You caught them - Super.
I'm approaching it from the viewpoint of a public facing app - that is *bound* to get some vandals at one time or another - or someone just monkey-typing away to see what happens.
From that point of view the distances are not to be trusted - unless they actually yield valid (and accurate) p0 coords.
Granted, someone could *still* do the math and enter a bunch of stars that don't even exist (by doing the reverse distance, just like we do to test).
That is however usually above the "effort threshold" of most vandals and the like.
But even in that event I'll be able to roll back (full log etc).
Code:
x: [-97.781250, 56.875000, -49.750000]
y: [-18.90625, 27.21875, 12.59375]x.subtract
.length() = 104.82128578263577The coords are copy pasted directly from the post so....
Dunno what coords the rest of you are using to get 131:S
I don't think that's possible. I've flown around a fair bit today and not found any. I'm only using the navigation panel to check and I know there are some systems which don't always show up on that list (WREDGUIA XH-Q B46-*, WREDGUIA LW-E D11-*), so I can believe we might be missing a few. But I can't believe we're missing 5%. I think Michael's misremembered and I'm fairly confident that 570 is actually correct and we've got them all.
Yeah, I tried letting my algorithm run for Sag A* for a while. It wasn't showing any signs of finishing any time soon
Your app doesn't provide feedback so it's relatively hard to find fake points, but with mine you can do a simple iterative refinement on your distances and no math is required. For example, it took me all of 30 seconds to generate this set:
Sol: 39.993
Wolf 497: 19.201
Huokang: 29.87
Demeter: 39.142
Clotti: 73.004
Someone could use mine to make that set and then enter it into yours and yours would accept it. And it think relying on the idea that generating fake points is too hard is unwise - someone will do it just to see if they can. So you can't use the validity of the trilateration to validate the input, which is why you require the star to be entered 5 times before really accepting it (though I could still get bad data in by simply generating more distances from the point I've found, it would take me another two or three minutes to generate 20 matching distances). The only fool-proof way to verify input is for someone trusted to check them in game.
Anyway that "independent confirmation" process (data entered 5 times) can easily be performed on individual distances too. So input validity isn't really a good reason to reject individual distances.
Incidentally, would it be possible to extend your API so we could fetch the input (distance) data? Fetching a list of stars is nice but it'd be much more useful if I could also fetch the distance data to confirm them.
Code:x: [-97.781250, 56.875000, -49.750000] y: [-18.90625, 27.21875, 12.59375]
x.subtract
The coords are copy pasted directly from the post so....
Dunno what coords the rest of you are using to get 131:S
Your first line of coordinates is for Wredguia UR-Q b46-2. The problem star is Wredguia WH-Q b46-2 at (-132.6875, 26.46875, -53).
You are absolutely correct, that anyone determined enough can easily mess things up - and there's not a thing I can do about it.
Except roll back.
Which is of course a pain in the back (and worse).
That's how I've chosen to roll though - I'll take my chances and see what happens.
If it turns out that someone has gotten mad enough at me for some reason, and constantly wrecks the DB with bad data - Then I'll have to change my policy, or go offline completely (not worth the effort etc).
But until that happens (and I'm totally not ruling out that it *could* happen), I'm crossing my fingers and hoping for the best
----
Distance data API - np.
The data is there, so it's pretty much a copy/paste job of the other API.
Will be tomorrow though - about to go to bed now (*way* overdue).
Except roll back.
Which is of course a pain in the back (and worse).
That's how I've chosen to roll though - I'll take my chances and see what happens.
If it turns out that someone has gotten mad enough at me for some reason, and constantly wrecks the DB with bad data - Then I'll have to change my policy, or go offline completely (not worth the effort etc).
But until that happens (and I'm totally not ruling out that it *could* happen), I'm crossing my fingers and hoping for the best
----
Distance data API - np.
The data is there, so it's pretty much a copy/paste job of the other API.
Will be tomorrow though - about to go to bed now (*way* overdue
).heh - well it was the coordinates listed next to the starname in the original post so that's what I went with
http://jsfiddle.net/8kom5mj4/
PS : The fiddle: It's easy to copy/paste more points in there (and change the axis etc) - I've had the whole pill in there - Just for the heck of it
That's very good! Visualisation is where I want to go next with this stuff and that looks like an interesting avenue to explore. Can you change the size of the dots? I'm looking for a quick way to visualise which parts of the pill I've searched so I'd like to load all the stars and then change the one's I've checked to 20 Ly radius so I can see which regions I've missed.
I can highly recommend HighCharts - It's and awesome library.
And it's so damn customizable.
Takes a bit of poking around in the documentation etc at times - But their website has ooooooodles of examples - and they are all linked directly to fiddle so you can play around right away.
I would be surprised if you couldn't change the dots to dogs if you wanted
But again, requires digging around in the docs a bit.
I wouldn't know off-hand how to do it.
Oh and keep in mind - HighCharts isnt really a 3d-viewing thingy. I've simply (mis)used their 3D-scatter plot is all
And it's so damn customizable.
Takes a bit of poking around in the documentation etc at times - But their website has ooooooodles of examples - and they are all linked directly to fiddle so you can play around right away.
I would be surprised if you couldn't change the dots to dogs if you wanted
But again, requires digging around in the docs a bit.
I wouldn't know off-hand how to do it.
Oh and keep in mind - HighCharts isnt really a 3d-viewing thingy. I've simply (mis)used their 3D-scatter plot is all
Last edited: