Whops - I intended to have that there.
Thanks for pointing out it's missing.
Noted.
I'll remove maxpad - and just leave the station type there.
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
Whops - I intended to have that there.
Thanks for pointing out it's missing.
Noted.
I'll remove maxpad - and just leave the station type there.
Do EDSC have support for a post of JSON data?
Typically I will update my own database with my personal tool, it would be convenient if I in the same script could POST that data to EDSC. This could be a new system, but it could also be a data update like coordinates, economy etc. Normally I will add new systems with a NULL coordinates. It would be usefull to add that system with null values to EDSC. I will then get coordinates (I do not use distances, I will use my screenshot method), these coordinates will be usefull for everyone to have. The third phase will be for me to actually visit that system. However this can be in weeks depending on what sector I decide to go for next. Then stuff like stations, distances, economy when system unknown etc.
Typically I will update my own database with my personal tool, it would be convenient if I in the same script could POST that data to EDSC. This could be a new system, but it could also be a data update like coordinates, economy etc. Normally I will add new systems with a NULL coordinates. It would be usefull to add that system with null values to EDSC. I will then get coordinates (I do not use distances, I will use my screenshot method), these coordinates will be usefull for everyone to have. The third phase will be for me to actually visit that system. However this can be in weeks depending on what sector I decide to go for next. Then stuff like stations, distances, economy when system unknown etc.
@TornSoul: A quick question about "known status".
I think I understand this, but I hate to feel like I'm assuming / guessing...
Known has been submitted with distances that check out
Unknown is a system name that someone has submitted with no distances / no verification?
So unknown would return:
Noting the empty coordinates?
Currently a test in fiddle returns no systems (which is probably a good thing), but as I'm now trying to connect my tool to your database, I thought I'd check.
I think I understand this, but I hate to feel like I'm assuming / guessing...
Known has been submitted with distances that check out
Unknown is a system name that someone has submitted with no distances / no verification?
So unknown would return:
Code:
{
id: 254,
name: "10 Ursae Majoris",
coord: [],
cr: 5,
commandercreate: "",
createdate: "2014-11-07 13:38:07",
commanderupdate: "",
updatedate: "2014-11-07 13:38:07"
},Noting the empty coordinates?
Currently a test in fiddle returns no systems (which is probably a good thing), but as I'm now trying to connect my tool to your database, I thought I'd check.
Yay! I've successfully sent a POST to EDSC and pulled the star data from the test server:
So, that's something!
I'll experiment with pushing "new" stars next.
So, that's something!
I'll experiment with pushing "new" stars next.
EDSC/TGC does not accept POST'ing coordinates - Only distances.
Once enough distances are available (TGC checks all this automatically) coordinates will be calculated (if possible).
This so we as close to possible can guarantee only valid coordinates are in the DB (if anyone could submit coordinates well...)
I've taken a few days off (reading some good books) from TGC (was getting a bit stressed out), but will probably start on version 2.1 tomorrow sunday.
That version will have the endpoint for POSTing static system details like economy, industry etc. And also station details.
Last edited:
Correct.
Known system: Coordinates are in the DB (either from FD data dump, or calculated based on submitted distances)
Unknown: No coordinates in DB, as not enough distances are (yet) submitted to do the math.
Make sure to include the "date" filter (I mention this as I've forgotten a couple of times myself), as without, you'll only get any changes made to the DB within the last 24 hours (which currently most of the time will be an empty list - as not much data is being submitted yet)
The general idea is that you make one full pull of all data, then cache that locally, and then with regular intervals ask for any changes since your last request (using the date filter).
Currently there's not *that* much data, but in a couple of years it could be quite a bit, so your app could end up pretty unresponsive if you pull all data each time (ie. if you don't use a local cache)
Last edited:
Not burning out is good
.When you're back at it you might want to review the 'About' blurb and edit for the current situation. For one thing it mentions not using the 2dp figures from the Nav Pane, obviously that's now the 1dp figures and people should be using the 2dp figures from the galaxy map.
Take your time and don't stress!
For me that means letting my script calculate the distances I get from coordinates that I calculate from my screenshots.
The only exception to that would be if I actually get the script to read that "1" hud and at least manage to pull the distances. That is however the future. How much easier it would be if some Andreas had a jump-to-system-list pulled from memory as it is displayed in game...
If I do manage that, it will be easier to just submit distances to other systems, instead of using the coordinates I get and reverse calculate distance to reference systems.
The only exception to that would be if I actually get the script to read that "1" hud and at least manage to pull the distances. That is however the future. How much easier it would be if some Andreas had a jump-to-system-list pulled from memory as it is displayed in game...
If I do manage that, it will be easier to just submit distances to other systems, instead of using the coordinates I get and reverse calculate distance to reference systems.
I was assuming we could push data with a POST as well, using the EDSC API.
I can understand wanting to have control over the data integrity, and requiring that the position calculations be done internally to EDSC is part of that.
What I would like to be able to push, in the very least, is: name, distances, system details (star type, station count, economy, security, etc.)...
Now, if I could incorporate or access a triangulator within my tool, I'd love to create a position for a new star, even one with a low CR, as quickly as possible, so if a user found a star and used the available distances, they could at least use the star "temporarily" within the tool for navigation.
If we could push this value, even with a CR of 0 to later be verified by additional data, it would at least be available data.
small update:
As i couldn't find any working route finder with a decent speed, i've reactivated https://cmdr.club,
and spend the last two weekends optimizing the route finder.
Right now I'm using RedWizzards json as a basis for my data (thanks for taking care of that file btw).
The route finder, with the current known data is quite fast, but probably i will have to put more work in it once we reach 100k systems.
I've linked to EDSC in case people want to help out with the sourcing of coordinates, but looking at the API itself, I'd like mention that a date for getting all changed since last request is sub optimal, as it requires to actually pull a bit overlapping to the last real request to prevent the possibility of skipped data. Also using post to get data, and more specific posting the query for the data, rather than using the query string for that seems odd to me.
As i couldn't find any working route finder with a decent speed, i've reactivated https://cmdr.club,
and spend the last two weekends optimizing the route finder.
Right now I'm using RedWizzards json as a basis for my data (thanks for taking care of that file btw).
The route finder, with the current known data is quite fast, but probably i will have to put more work in it once we reach 100k systems.
I've linked to EDSC in case people want to help out with the sourcing of coordinates, but looking at the API itself, I'd like mention that a date for getting all changed since last request is sub optimal, as it requires to actually pull a bit overlapping to the last real request to prevent the possibility of skipped data. Also using post to get data, and more specific posting the query for the data, rather than using the query string for that seems odd to me.
There is this Starchart that does route finding.
I'm working on one that has a viewable galactic map:
[video=youtube;HG7Pzxl243U]https://www.youtube.com/watch?v=HG7Pzxl243U[/video]
I'm now able to grab the database from EDSC and build that into the map, so the systems will always be the most current possible.
Routes are now only one jump at a time (not very helpful), but I'm now working of pathing from a starting system to a destination system, and showing that on the screen.
Next will be searching for a system name for both the starting and destination systems.
I'm looking forward to pulling system details from the EDSC when it's available.
Eventually, I'd like to be able to push newly discovered data to the EDSC.
Last edited:
I've not been able to figure out how i get this to give me a route from for example Aulin to 68 Draconis, for once it seems only to alow routes within the displayed systems, and i couldn't figure out how to get those systems all to show, and on the other hand, i really really prefer i can just enter start and destination over clicking wildly though a map.
- - - - - Additional Content Posted / Auto Merge - - - - -
damn this looks nice, but then again - for the simple job of finding how to get from a to be, i prefer a list of systems over a map.
having an map display the route additionally would be a nice feature though.
- - - - - Additional Content Posted / Auto Merge - - - - -
as a pointer for both of you - with the current amount of stars a simple a* star is good enough for finding the routes. thats basically what i'm using atm. once there will be more systems that will get slow fast though, hence, after optimizing my routefinder the most i could without going for a more complex way of finding the routes,
I'm now looking into other options, i have a few ideas, and I'm confident I'll be able to handle much larger amounts of data once its implemented.
That said, I've already build a route-finding-api for my pathfinder, which is used in the site i linked. Right now I'm unsure if i want other sites / apps to hammer that api, as i dont have enough data on the traffic that i'd have to look upon - and it shares the same servers (1 web + 3db) with quite a few of my other websites / projects.
But I'm not totally against maybe allowing others to use that API as well,
so if you are interested, let me know, and I'll put looking into making a decision on that a bit higher on my priority list.
Last edited:
It does
Go to the map
Click in the top left Box
Enter Aulin and select it from the dropdown
Click the target to make it the current location
Click the top left box again
Enter 68 D and select 68 Draconis
Route is shown on left hand side
hum, now it does.. i could have sworn it had just selected 68 draconis when i tried earlier
nice, but still maybe two text boxes make life easier
Thanks for the feedback!
I plan to also have a "list view" of the route, as, ultimately, in-game, that's all you need. Dahan > Eranin > I Bootis > Styx > Opala
But I like to visualize where I am, and the in-game map is such a steaming pile of carpfish.
When it comes to pathing, I assumed I would use some sort of A*, but yes, I can imagine an unlimited search of all the stars might be an issue.
hum, now it does.. i could have sworn it had just selected 68 draconis when i tried earlier
nice, but still maybe two text boxes make life easier
Exactly my thoughts
I am honestly jealous of TradeDangerous, kfsone's project can get away with being a command line tool, but I need to spend 90% of my time on UI related code.