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

[CMDR Ibizan]

When I do my web interface to enter distances, I would like to have registered commanders identified, because I believe someone who cares to register and identify will put more care to distances than someone anonymous. And they will see what they submitted, and be able to change or delete their errors. This is what I am missing most at TGC.
In a second step I will do an API similar to TGC, so RedWizzard's and other applications may submit distances to my database, and every tool using TGC may get more correct data in the same way as from TGC.

Any thoughts on this?

Well, I can't profess to have the faintest idea of how you guys achieve this stuff, but I am impressed by your intended web interface and your reasons behind having registered Commanders. I have been using Tornsoul's EDSC since the early pages of this thread without ever knowing whether anything I had input ever did any good!

So so your idea of being able to see and amend errors will be excellent.

As I said, I don't know how you and others like Reddwizzard do this, but on behalf of the non-programmers out here, please keep doing it!

 

[RedWizzard]

I am testing my way to find coordinates with the Gauss elimination. It's too early to say if it will reveal some great secrets, but it looks promising. I'd like to compare it with other methods, but actually I don't know how RedWizzard and Tornsoul and others do this exactly. Any help? I mean, I can read the source code at RedWizzard's GIT repository, but I don't understand it, and I can't use it from PHP.

Here's a description of how my algorithm works, TornSoul's is pretty similar I believe. Just for completeness I'll mention some basic stuff you already know about the problem, maybe someone else will find it useful. I'll discuss the rest of your post in a separate post.

There are a number of special considerations about locating systems in ED:
1. The distances reported in ED are woefully imprecise: only 2 decimal places for the galaxy map and often less in the nav panel. Incidentally the nav panel is not a good source for data because the distances it reports don't always match what's reported in the galaxy map. I believe the nav panel measures the distances from the ship's location rather than from the primary star and these two measurements often differ by 0.01.
2. Luckily the systems are aligned on a 1/32 Ly grid (i.e. coordinates are always a multiple of 1/32 Ly). If it wasn't for this fact the results would be quite unsatisfying. We set Sol to be the origin and align the Z axis towards the center of the galaxy. From Sol looking towards the center of the galaxy, X increased to the right and Y increases in the up direction (i.e. left handed coordinate system). This matches the coordinates shown on the galaxy map though data supplied by FD suggests that internally they use a different origin.
3. Distance calculations in ED are performed using single precision IEEE floating point. This is important when checking distances as the result calculated using single precision doesn't always match the result calculated using double precision.
4. The algorithms we use are using manually entered data so we need to be able to cope with errors in the data and poor choice of reference systems. This is the major influence on my algorithm's development.

For my algorithm, the basic trilateration algorithm is pretty much exactly as described on Wikipedia (http://en.wikipedia.org/wiki/Trilateration). That algorithm takes 3 reference points and 3 distances and produces two points that satisfy those constraints, if possible. It's a simple algebraic method that works provided the four reference points don't all lie in a plane, though due to the 1/32 Ly grid we can actually often handle even that case. Normally the fourth point and distance is only used to determine which of the two results was the correct one. But I want to handle bad distances and also want to take advantage of any extra distances so instead I do the trilateration on every combination of 3 distances. The resulting trilaterated points typically don't fall exactly on the 1/32 Ly grid so I evaluate a number of grid locations surrounding the trilaterated point. Typically I take the 8 grid locations nearest the trilaterated point (for very distant targets this is not enough and I need check 64 points or more but I'm not (yet) doing that automatically and obviously it slows things down considerably). So now I have a set of many candidate locations (I actually track the volumes to search rather than individual points and there is some optimisation involved in combining overlapping volumes of candidate points). For each candidate I calculate the distance to each reference system and compare that to the supplied distances. I then choose the candidate which matches the most supplied distances. Specifically I require a single candidate to either match all distances or to match at least two distances more than any other candidate. One way to measure the confidence we can have in the result is to consider how many extra distances are matched by the chosen location.

 

[RedWizzard]

I think I will make a way to mark these distances "suspicious" in my own database, and have a web frontend where you can enter the system name you're in, and you get a list of these suspicious distances, and enter the correct distances.
Maybe this is a good way to get rid of the multiple distances entered due to typos or having the wrong system name, 328 actually. Yes, I was involved there, too
We have 323 distances between systems with known coordinates, but the distance differs for 0.05 Ly or less.
We have 216 distances where the error is larger. And we have additionally 141 errors between systems with a CR of 5 or higher.
Leads me to another question: How to deal with errors and how to clean up. TGC considers a system to be verified after reaching CR=5. So I think it would be a good thing to offload all distances between systems with CR>=5 to a different place and not use them for "daily work", because we don't need them anymore.
If we have different distances submitted between the same systems, we need someone to visit one of the systems to verify. How many verification do we need to declare a distance as wrong, removing it from the table, or offloading it?

TGC gives a CR of 1 for a set of 5 distances leading to successful trilateration. And if someone enters a distance, it gets a CR of 1, too. I assume TornSoul considered the CRs for distances different than for coordinates, and I think this should be seen the same way.
So in a first step, when collecting TGC and RedWizzard's data, I took the coordinate CR multiplied by 100, and the distance CR multiplied by 20.
When I do my web interface to enter distances, I would like to have registered commanders identified, because I believe someone who cares to register and identify will put more care to distances than someone anonymous. And they will see what they submitted, and be able to change or delete their errors. This is what I am missing most at TGC.
In a second step I will do an API similar to TGC, so RedWizzard's and other applications may submit distances to my database, and every tool using TGC may get more correct data in the same way as from TGC.

Any thoughts on this?

I think the expectation when TGC was set up was that we'd get multiple people entering the same system quite often. In practice that doesn't seem to happen much (and personally I don't bother because I'd rather spend my time entering new systems). I believe the idea was that the system CR would increase each time a new person entered distances that confirmed a system's location. But that doesn't seem to be how it actually works. What happens AFAICT is that a system with no location gets CR = 1, a system with a calculated location gets CR = 2, and FD supplied systems get CR = 5 (the system(s) with CR = 6 are bugs, they should be 5). For distances I think the CR just increases each time someone enters the same data.

In terms of offloading distances between CR >= 5 systems, the problem right now is that the vast majority of CR 5 system actually haven't been confirmed. If I was setting it up now I'd actually treat the FD supplied systems as less reliable than the one's we've trilaterated.

There are several causes for bad distances in TGC that I can distinguish from the data:
1. Simple typo, e.g. 143.15 instead of 134.15.
2. Distances obtained from the nav panel which are out by 0.01: 9.15 instead of 9.14.
3. Distances obtained from the nav panel that are lower precision: 14.2 instead of 14.16. My fixup process recognises this case and ignores it.
4. Distances which have been recorded for the wrong system. This often results in differences to the same references and usually means there several incorrect distances. The main problem with this one is that it could mean that the chosen location is for the wrong set of distances.
5. FD can move a system. This should be rare and I've only noticed one case since release.

Personally I don't think it's worth spending effort to weed out the first three cases. The idea of having perfectly clean data is very attractive but it's also essentially impossible in any large data set. And really the distance data has no value other than for calculating coordinates so provided we have enough data to get locations the bad distances have no consequence. For these reasons my fixup process doesn't even report systems with one or two bad distances - I just assume they're typos. The cases I'm interested in are the 4th and 5th cases. I haven't come up with a good plan to handle those other than to carefully manually sort it out.

I've been thinking a bit about a TGC replacement and have come to the conclusion that retaining all data is probably the way to go in order to deal with the possibility of FD moving systems and the possibility of malicious data. Basically I'd want a history for all distances and some functionality for reporting bad distances/systems. Generally I'd also want users to be able to say "this system doesn't exist", "this system is in the right place but has the wrong name", and "this system is in the wrong place" without entering new distance data. Not sure exactly how that would be reported (probably though a system status value).

For each pair of systems with a distance I'd report the accepted distance, the date that distance was last entered, a "CR" value, and the status: "new" for distances that have only been added once, "confirmed" for distances that have been entered multiple times, "contested" if a distance had been changed when it was most recently entered (and if the same different distance was entered again it'd become "confirmed" on the new value), and "deleted" for distances that had been removed by an admin (probably wouldn't even report these by default). E.g. for some particular pair of systems:
User A enters 10.34: distance = 10.34, status = "new", CR = 1
User B enters 10.34: distance = 10.34, status ="confirmed", CR = 2
more users enter 10.34: CR increases
User C enters 15.2: distance = 10.34, status = "contested", CR unchanged (maybe should decrease by 1)
if User D enters 10.34: distance = 10.34, status = "confirmed", CR increases
if User D enters 15.2: distance = 15.2, status = "confirmed", CR = 2

For systems I'd make the CR equal to the number of good distances less the number of bad distances. I'm not quite decided on when to mark a system "contested", perhaps if just one distance changed, or perhaps I'd need several to change. Might also want a status to indicate that a user has flagged the system as bad.

 

[MagmaiKH]

Here's a description of how my algorithm works, TornSoul's is pretty similar I believe. Just for completeness I'll mention some basic stuff you already know about the problem, maybe someone else will find it useful. I'll discuss the rest of your post in a separate post.

There are a number of special considerations about locating systems in ED:
1. The distances reported in ED are woefully imprecise: only 2 decimal places for the galaxy map and often less in the nav panel. Incidentally the nav panel is not a good source for data because the distances it reports don't always match what's reported in the galaxy map. I believe the nav panel measures the distances from the ship's location rather than from the primary star and these two measurements often differ by 0.01.
2. Luckily the systems are aligned on a 1/32 Ly grid (i.e. coordinates are always a multiple of 1/32 Ly). If it wasn't for this fact the results would be quite unsatisfying. We set Sol to be the origin and align the Z axis towards the center of the galaxy.
<snip>

For my algorithm, the basic trilateration algorithm is pretty much exactly as described on Wikipedia (http://en.wikipedia.org/wiki/Trilateration).

This part is opinion but I think the z-axis should point up and out of the galaxy so that the galaxy mostly lies in the X-Y plane as most of the time we will "look down" at it and want to see it from the "top" not the "edge".

Trilateration is insufficient - it only works with perfect measurements and the algorithm is used to explain the basics of the idea.
You have to use a multilateration algorithm and calculate the bounding volume and its center created by the data - including error! If the accuracy of the measures are +/- 0.01 then you have to incorporate that into the bounding volume.
Once you have enough data that only one of 1/32Ly grid points are inside the volume you have found it.

 

[RedWizzard]

This part is opinion but I think the z-axis should point up and out of the galaxy so that the galaxy mostly lies in the X-Y plane as most of the time we will "look down" at it and want to see it from the "top" not the "edge".

Trilateration is insufficient - it only works with perfect measurements and the algorithm is used to explain the basics of the idea.
You have to use a multilateration algorithm and calculate the bounding volume and its center created by the data - including error! If the accuracy of the measures are +/- 0.01 then you have to incorporate that into the bounding volume.
Once you have enough data that only one of 1/32Ly grid points are inside the volume you have found it.

Yes, it would make some sense to have the Z axis be the axis that the galaxy rotates around. It would make even more sense to use a cylindrical coordinate system. But the coordinate system is irrelevant if we don't use the one that is shown in the galaxy map so that's what we're stuck with.

As you say, trilateration alone is insufficient. That's why I test all grid locations in a set volume around each result from trilaterating all combinations of distances in the data. This is effectively an approximation of the bounding volumes as calculating them accurately is not that easy. JesusFreke was doing that in his implementation but there are very few cases where that works but my approach doesn't.

 

[Inhumierer]

I read the Wiki article about trilateration, and basically this is the same as what I do, at least it' very similar. It leads to the same results as RedWizzard's JS does.
I take 4 distances, leading to 4 equations, eliminating the unknown, and voila - one location drops out of the formula. 1 distance is a sphere around the first reference star, cut with the second sphere remains a cirlce between both stars, 3rd distance cuts with a third sphere, 2 points remaining, and 4th distance removes 1 of them, here we are.
Due to the precision of the distances to 2 decimal places I take the next grid position and check all given distances. If I find one without error, I check all neighbour positions - this is the same as RedWizzard does with checking the set volume, basically. I only accept these coordinates if every given distance matches the calculated distances, and no neighbour position does.

I tested many systems, CMDR Ibizan is very helpful here, thanks to him. And it looked very good, entering new systems works like a charme, and even crunching old systems where TGC can't trilaterate works good, we had some direct hits.
One problem remains: My PHP script (in some cases) shows very clearly if there are errors in the reference distances, it even tells the correct distances. In 2 cases I visited the system to verify, and had success. The distances my script predicted were exactly what GM shows. But the wrong distances are in TGC, no way to get them out.

And to make it even worse, at one point where I tried to re-submit some distances, I took the wrong variable name and transmitted some distances without decimal point... Shame on me.

I'm looking for a few volunteers to test my frontend, anyone willing to register and help testing, shooting down errors and find new coordinates, shout up or send me PM.

 

[Smacker]

I'm looking for a few volunteers to test my frontend, anyone willing to register and help testing, shooting down errors and find new coordinates, shout up or send me PM.

PM sent a while ago now .....

 

[Inhumierer]

Yes, and you got an answer. You registered at my site, and after hunting down some errors I think my first version of the site sould be ready for take off.

I just copied the dev tree to the user tree and will test this tonight some more to see where it needs some tweaking. You may try it now. There will probably be some fine tuning tonight, but don't worry.

Always remember: this is far from production, it is a QnD site to enter & verify or falsify distances. Errors I found so far will be posted separately FYI, and as a PM to RedWizzard & Themroc so they don't miss it.

Anyone wanting to help, register at http://the-temple.de and set your commander name from the settings so I may merge your TGC distances to your account here. At the start or main page give the system name you are in:

Main things to do now:

"Systems where we need more distances to increase the confidence"
is a list of -you guessed it - systems where the location is known but should get more distances to assure the position. What you can do: Go to the galaxy map and copy paste the system names to the search field under the navigation tab. GM should jump to the location and show you a distance. If the distance is the exact same as shown in the table at the website, check the "OK?" box. If not, please click the magnifier glass beside the system's name and enter the correct distance. AND drop me or here a note, this is a rare case. I checked 100+ distances and found only one error.

"3796 systems where we need more distances to calculate the coordinates"
Yep - similar as above, but no calculated distance given to compare. You have to check at GM and enter by hand.

You don't need to check or enter all of the distances. The tables are limited to 39 sytems each, in fat there are several 1000s. Just do a few of them, as many as you like, and click "Submit". Distances will be saved in the database and (mostly) transferred to TGC. You will see some debugging stuff and some more useless information, just ignore it. Will probably disappear soon.

But right now I'd like to have some commanders enter and check some of the distances and tell me where to improve the page, add or remove some stuff etc.
If you can't find a system in the ED galaxy map, please let me know.

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

Hi, maybe some old hats, maybe some new things. Thanks.
Found problems so far:

Hydrae Secoter UJ-R B4-1 is a typo, correct is Hydrae Sector UJ-R B4-1
HIP 61062 system does not exist
17 Draconis coords mismatch: (-305.75/272.21875/49.5) vs EDDB (-310/272/50) - EDDB is wrong
ICZ IR-V b2-5 coords mismatch: (78.96875/-120.375/27.90625) vs EDDB (76.03125/-122.78125/29.40625) - EDDB is wrong, coords would match ICZ IR-V b2-2 at a glance
Taurus Dark Region GW-W d1-53 coords mismatch: (-32.5625/-74.28125/-401.53125) vs EDDB (-32.59375/-74.25/-401.53125) - EDDB seems to be wrong
Argetlámh, Nantóac, Mantóac and Lífthruti are in database twice, probably some problem with the accent
Correct spelling is probably Argetlamh, Nantoac, Mantoac and Lifthruti - at least MySQL and ED Client find them with these spellings
Buma is a typo, correct name is Bamu

Systems with identical coordinates:

I can't find a sys named Flechs. Can you?

PUPPIS SECTOR EG-X B1-1 A is probably a star in system PUPPIS SECTOR EG-X B1-1
Alrai Sector JC-V B2-6 A same as above...
Omagate is a typo, correct is Omagatae.
Hyades: the rest of the name was omitted, correct is Hyades Sector HC-T B4-4
Herculis Sector ZE-A B86 does not exist, correct is HERCULIS SECTOR ZE-A D86
OI-T B3-9 misses "Alrai Sector" at the beginning
Core Sys Sector EB-0 A6-0 is wrong, correct is Core Sys Sector EB-O A6-0
Col 285 Sector BW-1 B24-7 is wrong, correct is Col 285 Sector BW-I b24-7
Core Sys HH-M A7-3 is wrong (although ED Client finds it in GM), correct is CORE SYS SECTOR HH-M A7-3
IDZ DL-X B1-1 is wrong, correct is ICZ DL-X b1-1
LFT 16653 is wrong, correct is LFT 1653
LP 634-18 is a double space between which gets eaten up from the forum
LP 937-98 is wrong, correct is LP 937-95
Pleiades Sector SZ-0 B6-3 & B6-4: the number 0 is wrong, the letter O is correct
Praea Euq SX-U s2-18 is wrong, correct is Praea Euq SX-U d2-18
Praea Euq GR-O b13-0 is wrong, correct is Praea Euq GR-D b13-0
Praea Euq GV-W c is wrong, correct is Praea Euq GV-W c15-7
LP 649-73 is wrong, correct is LP 469-73
Synuefai FL-V d3-7 is wrong, correct is Synuefue FL-V d3-7
Synuefai NM- is wrong, correct is Synuefai NM-N c9-0
Synuefue d2-26 is wrong, correct is Synuefue XJ-X d2-26
Coordinates for Synuefai FG-R c7-4 are in fact for Synuefue FG-R c7-4. Synuefai FG-R c7-4 is at a different location.
Coordinates for Synuefai LM-I b15-0 are in fact for Synuefue OH-I b15-1. Synuefai LM-I b15-0 is at a different location.
Coordinates for Synuefai VN-G b16-0 are in fact for Synuefue VN-G b16-0. Synuefai VN-G b16-0 is at a different location.
Are these twin systems like HIP 24020/HIP 24019? ED Client shows both at same location in GM.
LHS 1393 | GJ 1047
LP 932-12 | LP 932-13

 

[Inhumierer]

Oh I forgot - If you don't want to register, send me a message, and you'll get username & password. But you will not be able to retreive a new password if you forget it ;-)
And if it gets buried: If you come over a system in the table which you can't find ingame, please tell us.

 

[esraven]

When I have done input in edstarcoordinator.com for a star with unknown coordinates, where do I see the calculated coordinates? I am now outside the bulb on a exploring tour and I intend to do a trilateration every 200 LY int the x-direction I am heading.

 

[CMDR Ibizan]

When I have done input in edstarcoordinator.com for a star with unknown coordinates, where do I see the calculated coordinates? I am now outside the bulb on a exploring tour and I intend to do a trilateration every 200 LY int the x-direction I am heading.

If I remember correctly, after you have input your five distances to different stars, you either get a "Trilateration Successful" message showing you the newly calculated coordinates or a "Unsuccessful Trilateration" message which then suggests that you input more distances. (Not at the PC at the moment!)

 

[Finwen]

I use a cloned version of Redwizzards page to enter new systems.

http://robert.astronet.se/Elite/ed-systems/entry.html

It is much easier and gives feedback if it wants more reference stars. It also suggest stars to get distance from and shows if you misstype a distance.

 

[esraven]

Hi Finwen,

I am now exploring outside the bulb and intent to calculated about every 100 to 200 LY the XYZ of a star system

You are also the developer of EDDiscovery. Nice program, I run it while exploring.
Last day I calculated by the webapp
http://robert.astronet.se/Elite/ed-systems/entry.html
succesfully the coordinates of a star with unknown coordinates (Col 285 Sector OA-D c13-5) . On the page I transmitted it to TCS.

Aferwards I checked EDDiscovery and there the system was still with unknown coordinates.

Are systems with coordinates calculated by the webapp transmitted to the lists checked by EDDiscovery and if so how
- does it happen, automaticallly or after manual actions,
- what is the delay between transmission to TCS and known by EDDiscovery

Greetz

 

[Finwen]

Right now EDDiscovery needs to be restarted to handle new stars correctly. Every time it starts it checks for new stars. In the future i will change it so you can refresh star data insode EDDiscovery.

TGC wants a few more stars sometimes. And it always wants atleast 5 stars. Col 285 Sector OA-D c13-5) only has 4 stars in TGC.
You can fix this by adding distance to it next time you calculate a position for a star. I can add a distance tonight to.

To get stars to solve in TGC's trillatation. Enter atleast 5. And you should have "Better than next candidate(s) by 2 distances" if i am far out i usually affs 1 or 2 more stars to be sure that TGC solves the coordinate.


Have you checked the simple star map in EDDiscovery? Press button map test. I recreated it with OpenGL yesterday for more performance. Navigation is almost impossible now. But i will improve it soon.
Right now white stars are stars with coordinates. And red stars are visited by you. You can zoom in and out with the scrool wheel on the mouse.

 

[esraven]

Hij Finwen, thanks for the answer.
I check this evening the map test button and will give at least 6 distances in the future.

 

[esraven]

The coordinates I have put in were for system Col 285 Sector TP-O d6-91 and not for Col 285 Sector OA-D c13-5
I did a wrong copy/paste from EDDiscovery, I noticed now.

So please delete the added system Col 285 Sector OA-D c13-5 or change the name in Col 285 Sector TP-O d6-91

I copied the name from "distance from..." in stead of above "system"

Sorry for the mistake

 

[Smacker]

Alpha Cygni - EDDB coords correct. I had the same in systems.json but some of the reference stars were deleted between beta3 and gamma and it can't be trilaterated right now. I'll get a few more references.

Connla, HIP 113905, HIP 114769, Ot Serpentis, Wolf 654 - these are all beta3 reference systems that FD didn't provide in the reference list for gamma (presumably they no longer have stations). I've verified the coordinates ages ago but hadn't got around to giving TornSoul a list to load into TGC before he vanished. I'll add these to my copy of the data.

Sagittarius A* - can't be trilaterated with the algorithm I'm using now for the references TGC has though I was able to do it back in beta2 (or was it beta1?) when we still had 3 decimal places for distances in the galaxy map. Coordinates in EDDB are correct. My personal challenge is to try to find the right references and/or tweaks to the algorithm so that I can trilaterate Sag A*.

Ditibi (old location) - Ditibi changed location after release. At one point I was keeping the old location in the database as "Ditibi (old location)" to preserve the distances recorded (which were valid distances to the old coordinates), but I've found that none of the old distances are necessary so I've deleted it now.

HIP 24019 · HIP 24020 - I've keep these are separate systems in my data. They have the same coordinates in the galaxy map.

Synuefe HF-I b57-6 - I get the same coordinates trilaterating with the 3 distances that are in TGC. That's not enough distances for any real confidence though so I've been leaving the coordinates null.

ICZ IR-V b2-5 - coordinates in EDDB are for ICZ IR-V b2-2. This is an issue I fixed fairly recently.

Oevaxy OA-A D0 - eyeballing the coordinates on the galaxy map shows that EDDB has it wrong. The second coordinate should be about -23, not -230.

The rest are either not in not in TGC or don't have enough distances to trilaterate.

If few more differences to check

System positions differ RedWizzard vs Starchart
Bei Dou Sector JV-C b2-2 [-62.21875,58.875,-2.3125] But clashes with Bei Dou Sector JC-V b2-0 - "Bei Dou Sector JC-V b2-0", "Bei Dou Sector JV-C b2-2"
HIP 623536 [27.3125,118.9375,17.65625] But clashes with HIP 62536 - "HIP 62536", "HIP 623536"
Minimar [14.9375,-20.4375,8.5625] But clashes with Minmar - "Minmar", "Minimar"
MV URSAE MAJORIS [-31.28125,87.65625,-31.71875] But clashes with MZ Ursae Majoris - "MZ Ursae Majoris", "MV URSAE MAJORIS"

I think HIP 623536, Minimar and MV URSAE MAJORIS are all typos
Also SADR should be Sadr

 

[Finwen]

I was interested in how far out we have mapped stars. With a sql query from my database i sorted on it from longest away from Sol. I only show the top result here...

The first 2 are RED wizzards test on trillatation i guess. And then we have a big cluster of stars from NGC 78222 / Shapeless 171 nebula

Plaa Ain DT-Q c18-17	9999.59
Blu Euq HI-V b43-5	5000.65
S171 6	                2835.03
S171 11	                2835.01
S171 8	                2835.01
NGC 7822 Sector AQ-Y d5	2830.46
S171 32	                2830.03
S171 44	                2830.03
S171 27                	2830.02
S171 24                	2830.02
NGC 7822 Sector FW-W c1-5	2825.30
S171 2	                2825.03
S171 16	                2825.02
S171 39	                2825.01
S171 20	                2825.01

 

[RedWizzard]

I was interested in how far out we have mapped stars. With a sql query from my database i sorted on it from longest away from Sol. I only show the top result here...

The first 2 are RED wizzards test on trillatation i guess. And then we have a big cluster of stars from NGC 78222 / Shapeless 171 nebula

Plaa Ain DT-Q c18-17 9999.59
Blu Euq HI-V b43-5 5000.65

Yes, I was testing how far away I could successfully trilaterate (by visiting the reference systems to get distances to the target) and also testing the suggestion function. Blu Euq HI-V b43-5 wasn't too hard, the largest distance between any of the reference systems I used was about 1650 Ly. Plaa Ain DT-Q c18-17 required a trip out to the S171 systems, the largest distance between references was about 3850 Ly.

The S171 systems are all very bright type O blue-white supergiants. It's quite pretty with the bright stars and the nebula and a lot of the systems have black holes so they're worth visiting if you're an explorer.

 

[RedWizzard]

If few more differences to check

System positions differ RedWizzard vs Starchart
Bei Dou Sector JV-C b2-2 [-62.21875,58.875,-2.3125] But clashes with Bei Dou Sector JC-V b2-0 - "Bei Dou Sector JC-V b2-0", "Bei Dou Sector JV-C b2-2"
HIP 623536 [27.3125,118.9375,17.65625] But clashes with HIP 62536 - "HIP 62536", "HIP 623536"
Minimar [14.9375,-20.4375,8.5625] But clashes with Minmar - "Minmar", "Minimar"
MV URSAE MAJORIS [-31.28125,87.65625,-31.71875] But clashes with MZ Ursae Majoris - "MZ Ursae Majoris", "MV URSAE MAJORIS"

I think HIP 623536, Minimar and MV URSAE MAJORIS are all typos
Also SADR should be Sadr

Thanks, I've included these corrections. Unfortunately it seems that I can't fetch the full set of distance data from EDSC/TGC anymore: it takes too long so I suspect something is failing on the server due to the size.
I'll have to rework my process to fetch the data incrementally before I can upload a corrected file.