Celestial bodies would be nice, but for most purposes I can think (trading or bulletin board missions) of only the stations are necessary, so I wonder if anyone would spend the time to provide the data (unless there is an API of course). The systems.json format upon which my own one is based (or likely both formats influenced each other really) lists station names, distances and services. A single distance value for the station seems to be sufficient, its the magnitude of the value that seems to be relevant anyway. I use the same format for backup, storage on bitbucket and in the communication between the server and the web pages.
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Celestial bodies would be nice, but for most purposes I can think (trading or bulletin board missions) of only the stations are necessary, so I wonder if anyone would spend the time to provide the data (unless there is an API of course). The systems.json format upon which my own one is based (or likely both formats influenced each other really) lists station names, distances and services. A single distance value for the station seems to be sufficient, its the magnitude of the value that seems to be relevant anyway. I use the same format for backup, storage on bitbucket and in the communication between the server and the web pages.
Put in a cubefilter - and pull only a bit of the data at a time (50 LY cube or whatever works)
The data is only going to grow - So everyone will need to do so sooner or later
Feature request..
Something like a daily export of all the data, as a static json file?
See the first post in this thread, the "List of tools and programs created for the crowd source project" section which lists TornSoul's EDSC, which has an API for pulling the data.
But if you put them on an axis, then you will have a 1d image.
In addition to EDSC could to try maddavo's market share with a CSV file with systems and coordinates, or the systems.json from RedWizzard. I find this latter the best source, because #1 I need to process the data locally for my map and #2 it is more complete than EDSC in that it has everything I need. Only it has not been updated for Gamma yet.
I believe you mean distance of stations from the star, not each other, isn't it? I don't understand why the data should be limited to just the distance; having the type, economy and services available would also be useful.
Distance to star we already have. With multiple markets in system the distance between each station in a system is becoming very important for trade calculations too.
The problem is that those distances can change wildly depending on where the parent planet is in its orbit for each station in the system.
You can't save these. You would need a formula to calculate the distance at a given date/time if the stations orbits different planets which could also orbit different stars in the system.
How about just logging the distance of the nearest body orbiting the Star. That way, the distance from the Star to the station will only vary by [SUP]the orbit of the station around the planet[/SUP] a little.
It will take some additional work for someone logging this (and doing it correctly), but it will be accurate enough. I think what everyone wants to know is we have to fly 10, 100, 1000, 10.000, 100.000 to the station.
It will take some additional work for someone logging this (and doing it correctly), but it will be accurate enough. I think what everyone wants to know is we have to fly 10, 100, 1000, 10.000, 100.000 to the station.
Last edited:
To quote a famous Geordie,"I'm not expert but" does that not depend on if the body orbiting the star has an equidistant orbit path around the said star?
sorry for my lack of accurate terminology...
I've seen some very odd looking orbits when systems have multiple stars and multiple gas giants.
However, if you take the nav point and a distance to the station you are interested in, it's not going to change very much for many years. Everything looks realistic in times of orbit, some of those pesky low orbit stations are zipping around faster than the safe SC off speed. You can follow them around the planet. (these also tend to be the buggy ones btw.)
That's where orbital mechanics work out nicely. For those where the orbital position would change quickly you'd also have a very small radius orbit, and thus it doesn't actually matter that it's changing position rapidly. And indeed for those where there's potential for large changes it will take a long time.
I do think that distance from the jump-in point is going to be sufficient for most use cases. If you're already in the system for a trip between two stations in it then you can simply check the nav pane before taking a mission.
Systems.json has been updated for gamma. It's now a bit over 4MB and contains 20171 systems of which 339 need to be verified. I've left both HIP 24019 and HIP 24020 (which have identical coordinates) in the file as the galaxy map seems to oscillate between the two names.
I haven't touched the economy/station data. I think someone needs to check a few so we can decide if it's better to start from scratch or if a decent amount of it is unchanged.
Last edited:
Unless your Magnus Carlsen you will need the help of a computer to spot those high credit/hour opportunities. And give the promise of dynamic price changes, you would want to know about them as soon as you update the market.
Is the EDStarCoordinator API broken?
Im trying to get the jsfiddle examples running:
http://jsfiddle.net/5grjpe57/
But the response object ist always empty. Am I doing something wrong?
Im trying to get the jsfiddle examples running:
http://jsfiddle.net/5grjpe57/
But the response object ist always empty. Am I doing something wrong?
Ya - I just checked my tool and discovered I'm getting 'null' data when I poll the EDSC...
0.0!
0.0!