Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Something a little different'ish
Take a look at http://jsfiddle.net/ptkvypns/
This pulls all the distances for "Hydrae Sector AA-A D104"
Notice how the result is not nicely grouped into just one group of distances for "Hydrae Sector AA-A D104", but several groups of distances.
As it happens "Hydrae Sector AA-A D104" has 6 distances to it recorded.
As it also happens, those distance are not all stored with "Hydrae Sector AA-A D104" as p0, hence the multiple groups.
To make it a bit easier to see (the fiddle is rather verbose) I'll list the involved distances here (the actual value of the distance is irrelevant for this discussion)
Example 1
"Hydrae Sector IR-W B1-5" - "Hydrae Sector AA-A D104"
"Hydrae Sector AA-A D104" - "Core Sys Sector PN-T B3-3"
"Hydrae Sector AA-A D104" - "Puppis Sector OI-T B3-6"
"Hydrae Sector AA-A D104" - "Tawhaki"
"Puppis Sector RD-T B3-7" - "Hydrae Sector AA-A D104"
"Puppis Sector TO-R B4-3" - "Hydrae Sector AA-A D104"
(where each unique name on the left corresponds to a grouping of distances in the fiddle - ie. 4 groups in total)
Sometimes "Hydrae Sector AA-A D104" is on the left and sometimes on the right - which is how the distance is stored in the DB.
Now obviously when you request distances for just one star it would be much nicer if the output was in just one group aka
Example 2
"Hydrae Sector AA-A D104" - "Hydrae Sector IR-W B1-5"
"Hydrae Sector AA-A D104" - "Core Sys Sector PN-T B3-3"
"Hydrae Sector AA-A D104" - "Puppis Sector OI-T B3-6"
"Hydrae Sector AA-A D104" - "Tawhaki"
"Hydrae Sector AA-A D104" - "Puppis Sector RD-T B3-7"
"Hydrae Sector AA-A D104" - "Puppis Sector TO-R B4-3"
(just one group)
Here's the catch however
Distances can be requested in many ways (depending on the filter)
So it's not always for just a single star.
Which then means I can't always make just one grouping like above.
On the other hand it would be very nice to have all distances for a given star in it's own distance array (like Example 2 tries to illustrate)
But to do that, it would require to have each distance twice in the output.
So Example 1 would end up looking like
Example 3
"Hydrae Sector IR-W B1-5" - "Hydrae Sector AA-A D104"
"Core Sys Sector PN-T B3-3" - "Hydrae Sector AA-A D104"
"Puppis Sector OI-T B3-6" - "Hydrae Sector AA-A D104"
"Tawhaki" - "Hydrae Sector AA-A D104"
"Hydrae Sector AA-A D104" - "Core Sys Sector PN-T B3-3"
"Hydrae Sector AA-A D104" - "Puppis Sector OI-T B3-6"
"Hydrae Sector AA-A D104" - "Tawhaki"
"Hydrae Sector AA-A D104" - "Hydrae Sector IR-W B1-5"
"Hydrae Sector AA-A D104" - "Puppis Sector RD-T B3-7"
"Hydrae Sector AA-A D104" - "Puppis Sector TO-R B4-3"
"Puppis Sector RD-T B3-7" - "Hydrae Sector AA-A D104"
"Puppis Sector TO-R B4-3" - "Hydrae Sector AA-A D104"
Notice how each distance is there twice now.
It does accomplish not having to find all the distances for "Hydrae Sector AA-A D104" by going through all the individual groups - But at the cost of doubling the output (duplicating each distance)
Personally I hate redundant data like this (duplicates values) - It usually ends up being more trouble than it's worth.
And if you are storing distances locally, having to filter out the duplicates to just save a distance once (locally) would be annoying having to do.
But I suppose a case could be made for it in this particular situation (as someone has done - which is why I'm bringing it up)
So what would you prefer:
Double the distances/data, or keep it as it is (as the fiddle shows it)
EDIT: Oh and this would be a breaking change btw. So needs good arguments for doing it.
Tool makers out there would need to change their code if they are using the current distances output.
Take a look at http://jsfiddle.net/ptkvypns/
This pulls all the distances for "Hydrae Sector AA-A D104"
Notice how the result is not nicely grouped into just one group of distances for "Hydrae Sector AA-A D104", but several groups of distances.
As it happens "Hydrae Sector AA-A D104" has 6 distances to it recorded.
As it also happens, those distance are not all stored with "Hydrae Sector AA-A D104" as p0, hence the multiple groups.
To make it a bit easier to see (the fiddle is rather verbose) I'll list the involved distances here (the actual value of the distance is irrelevant for this discussion)
Example 1
"Hydrae Sector IR-W B1-5" - "Hydrae Sector AA-A D104"
"Hydrae Sector AA-A D104" - "Core Sys Sector PN-T B3-3"
"Hydrae Sector AA-A D104" - "Puppis Sector OI-T B3-6"
"Hydrae Sector AA-A D104" - "Tawhaki"
"Puppis Sector RD-T B3-7" - "Hydrae Sector AA-A D104"
"Puppis Sector TO-R B4-3" - "Hydrae Sector AA-A D104"
(where each unique name on the left corresponds to a grouping of distances in the fiddle - ie. 4 groups in total)
Sometimes "Hydrae Sector AA-A D104" is on the left and sometimes on the right - which is how the distance is stored in the DB.
Now obviously when you request distances for just one star it would be much nicer if the output was in just one group aka
Example 2
"Hydrae Sector AA-A D104" - "Hydrae Sector IR-W B1-5"
"Hydrae Sector AA-A D104" - "Core Sys Sector PN-T B3-3"
"Hydrae Sector AA-A D104" - "Puppis Sector OI-T B3-6"
"Hydrae Sector AA-A D104" - "Tawhaki"
"Hydrae Sector AA-A D104" - "Puppis Sector RD-T B3-7"
"Hydrae Sector AA-A D104" - "Puppis Sector TO-R B4-3"
(just one group)
Here's the catch however
Distances can be requested in many ways (depending on the filter)
So it's not always for just a single star.
Which then means I can't always make just one grouping like above.
On the other hand it would be very nice to have all distances for a given star in it's own distance array (like Example 2 tries to illustrate)
But to do that, it would require to have each distance twice in the output.
So Example 1 would end up looking like
Example 3
"Hydrae Sector IR-W B1-5" - "Hydrae Sector AA-A D104"
"Core Sys Sector PN-T B3-3" - "Hydrae Sector AA-A D104"
"Puppis Sector OI-T B3-6" - "Hydrae Sector AA-A D104"
"Tawhaki" - "Hydrae Sector AA-A D104"
"Hydrae Sector AA-A D104" - "Core Sys Sector PN-T B3-3"
"Hydrae Sector AA-A D104" - "Puppis Sector OI-T B3-6"
"Hydrae Sector AA-A D104" - "Tawhaki"
"Hydrae Sector AA-A D104" - "Hydrae Sector IR-W B1-5"
"Hydrae Sector AA-A D104" - "Puppis Sector RD-T B3-7"
"Hydrae Sector AA-A D104" - "Puppis Sector TO-R B4-3"
"Puppis Sector RD-T B3-7" - "Hydrae Sector AA-A D104"
"Puppis Sector TO-R B4-3" - "Hydrae Sector AA-A D104"
Notice how each distance is there twice now.
It does accomplish not having to find all the distances for "Hydrae Sector AA-A D104" by going through all the individual groups - But at the cost of doubling the output (duplicating each distance)
Personally I hate redundant data like this (duplicates values) - It usually ends up being more trouble than it's worth.
And if you are storing distances locally, having to filter out the duplicates to just save a distance once (locally) would be annoying having to do.
But I suppose a case could be made for it in this particular situation (as someone has done - which is why I'm bringing it up)
So what would you prefer:
Double the distances/data, or keep it as it is (as the fiddle shows it)
EDIT: Oh and this would be a breaking change btw. So needs good arguments for doing it.
Tool makers out there would need to change their code if they are using the current distances output.
Last edited:
Values submited to EDSC was nav panel distance. Those two where the ones I noticed beeing off by 0.01 was it not? So that means we have to target system open map, escape, target next open map etc etc. It sounds like a lot of work, but it is actually pretty okayish. Already have to do that on distances above 10LY as FD only give 1 dp precision on those in nav panel.
Tornsoul, could you take a look at why EDSC is unable to calculate a good set of coordinates for LP 211-12? Is it because of the two nav-panel vs galaxy map differences? Could you in that case try to alter the G 146 and LP 211-12 distance and see if that changes anything? Its very annoying when you get 10+ good distributed distances and can't get an answer.
Okay, is there any way you can detect such flawed distances? I think that number of distances submited should be enough to at least give a cr:1 rating for a coord.
And everyone should get their distances from the galaxy map in the future. I still hope for coords on galaxy map in the future, but I have a gut feeling we'll see the 1dp accuracy spread into that panel as well.
Working on it.
I think leave it as is. It's easy enough to generate the reverse distances in the client if necessary.
- - - - - Additional Content Posted / Auto Merge - - - - -
Just jumping in here, but if I mention NoSQL for storing the JSON (like Mongoose), am I beating a dead horse?
That sort of implementation detail is really up to the implementor. I probably would use either CouchDB or Redis myself but I'm not doing it
Maybe you need to be at the gravity center of a multistar system to get the same distance in the nav-panel as the galaxy map.
That sort of implementation detail is really up to the implementor. I probably would use either CouchDB or Redis myself but I'm not doing it
In the long run only databases that support 3D spatial indexes will work. I believe all of sqlite, mysql and postgresql support those.
That sort of implementation detail is really up to the implementor. I probably would use either CouchDB or Redis myself but I'm not doing it
Cool. Another question that has probably already been discussed, but did anyone get a download of the NOMAD (or other) database, and use it to map as-of-yet unidentified systems?
Presumably this is all stuff FD can fix Server side, all ticketed I hope
I've ticketed the issue with "extraction" showing twice. And also re-ticketed the fact that the search function still doesn't accept '.' which makes it impossible to search for some systems. I'm not sure the others are necessarily bugs but feel free to ticket them!
Presumably you mean this ? If so, I've tried using some real star data to find ED stars, but I've had no luck figuring out the exact transform FD have used. See https://forums.frontier.co.uk/showthread.php?t=6707&page=39&p=588316#post588316
I'm hoping to get my pathfinding going in the next few days...
What do people recommend? Dijkstra's algorithm? Or A*? I am acquainted with a few people who have made A* pathfinding projects for navmeshes, and they suggested Dijkstra's algorithm siting that A* was overkill... but I'm reading that several people have used A* to do path finding.
Either way, I'll need to grok a C# implementation of one of these two methods, but before I went around the village square trying to figure both our, I thought I'd ask for advice.
Anyone have hints or suggestions?
What do people recommend? Dijkstra's algorithm? Or A*? I am acquainted with a few people who have made A* pathfinding projects for navmeshes, and they suggested Dijkstra's algorithm siting that A* was overkill... but I'm reading that several people have used A* to do path finding.
Either way, I'll need to grok a C# implementation of one of these two methods, but before I went around the village square trying to figure both our, I thought I'd ask for advice.
Anyone have hints or suggestions?
Oh wow, nice work! Yeah that's what I meant. I know NOMAD is an aggregate database and has different representations. I haven't explored this, but just in case you haven't seen it, I believe this to be a repository of the NOMAD reference component data:
ftp://cdsarc.u-strasbg.fr/pub/cats/I/
The upper directory level has a horde of other representations. See the ReadMe for formats.
I've changed the encoding of systems.json from simple ascii to utf8 as there are four gamma reference systems that should have diacritics in their names: Argetlámh, Lífthruti, Mantóac, and Nantóac. Hopefully this doesn't cause any problems for any of you using systems.json.
This has caused me to open yet another ticket as I can't seem to enter those characters in the galaxy map search which makes those system impossible to find.
This has caused me to open yet another ticket as I can't seem to enter those characters in the galaxy map search which makes those system impossible to find.
Use Dijkstra. There should be several implementations ready in the sources for different ED tools.
It would still be a manual process. You could use the hipp/gliese/whatever and search in game, but the use for it is limited.
The best you can do is get your FSD upgraded so you can get that nav panel list of systems around you. The shorter range drives are usefull too, but you will miss systems while your cruise around.
I find EDSC js fiddle pretty convenient to get a list of systems in a cube around you. This would allow you to use pen&paper (or spreadsheet) to search and visit systems in a methodical way without using a home brewed system for tracking where you've been. EDSC also have a pretty decent tool for adding anything new you find and visit in that cube. (http://edstarcoordinator.com/) Once it get better at spotting the "right" distances, you might even get coords back every time. But that is of less consequence is all you want to do is add new systems to EDSC.
Just used it on my internal stuff and seems OK. Thanks for your hard work
EDIT: And alt codes don,t seem to work in the galmap (i.e. ALT + 0225)
Last edited: