ED Astrometrics: Maps and Visualizations
- Thread starter Orvidius
- Start date
It's not an especially simple proof, but fortunately it's a solved problem with a formula you can use to estimate this. I posted the solution to this problem a few pages ago: https://forums.frontier.co.uk/threads/ed-astrometrics-maps-and-visualizations.400488/post-8451398
Yep, I remember. 
That would work for number sequences inside boxels, but it would also have to take into account unrepresented boxels. That latter part would probably need a galaxy-wide analysis to see what boxels tend to not be populated in varying density regions, etc. And I don't think we have any sectors sufficiently complete to figure that out, except maybe in the bubble, which is a special case. But that's speculating beyond what's needed here.
Luckily none of this is really needed for the map.
EDIT: That is to say, it would be additional complexity for the same result. Right now if the max number is 100, and 0-100 are all there, we can say with high confidence that it's a highly explored boxel. If the max is 100, and only 10 of them are accounted for, we can still say with high confidence that it's lightly explored. No statistics needed. So I was only pointing out that to date I haven't had a need to go down that rabbit hole.
That would work for number sequences inside boxels, but it would also have to take into account unrepresented boxels. That latter part would probably need a galaxy-wide analysis to see what boxels tend to not be populated in varying density regions, etc. And I don't think we have any sectors sufficiently complete to figure that out, except maybe in the bubble, which is a special case. But that's speculating beyond what's needed here.Luckily none of this is really needed for the map.
EDIT: That is to say, it would be additional complexity for the same result. Right now if the max number is 100, and 0-100 are all there, we can say with high confidence that it's a highly explored boxel. If the max is 100, and only 10 of them are accounted for, we can still say with high confidence that it's lightly explored. No statistics needed. So I was only pointing out that to date I haven't had a need to go down that rabbit hole.
Last edited:
Well, well, well... EDDN is here! I finally have a listener-script updating my database via EDDN. The EDSM dumps will still be used as before, mainly sanity-checking and filling in anything that got missed for some reason. But now the data on my side will be more real-time. This doesn't change much for purposes of generating maps and spreadsheets, except that I can have higher confidence that I won't lose data if one update mechanism fails.
It's taken some real effort to get here. I've been working on it in chunks over the last month or so. Some of it waited on getting the new database server hardware in place, as I didn't want to make large changes to tables while the database was still competing with the scripts for system resources on the same server.
I treated it as though I was overhauling a production system, without requiring outages. As we say in the IT world, working on a production system is like trying to fix a car's engine while it's driving on the highway. Things like adding temporary columns, and allowing for two different ID numbering systems to be used simultaneously, and making sure all of the scripts understand this. There were a few hiccups, but I usually spotted them quickly and could regenerate whichever file had the problem.
And now it's done. I think we're running smoothly again now. Whew.
It's taken some real effort to get here. I've been working on it in chunks over the last month or so. Some of it waited on getting the new database server hardware in place, as I didn't want to make large changes to tables while the database was still competing with the scripts for system resources on the same server.
I treated it as though I was overhauling a production system, without requiring outages. As we say in the IT world, working on a production system is like trying to fix a car's engine while it's driving on the highway. Things like adding temporary columns, and allowing for two different ID numbering systems to be used simultaneously, and making sure all of the scripts understand this. There were a few hiccups, but I usually spotted them quickly and could regenerate whichever file had the problem.
And now it's done. I think we're running smoothly again now. Whew.
Are these changes also in CSV file? Because estimated coordinates are still a bit off. Example:
Code:
7835630869352,2003064,"Aaeyoea BW-N a102-0",10,22990,-1290,24550,33658.68I'll have to take a look. I think that script was doing things a bit differently, so it probably needs a correction as well.
Yep, this needed the same kinds of corrections added. I've copied the changes over, and re-generated the file. Now it's here:
22990, -30, 25630
I think that does exactly what I'm doing.
I've made some small updates to the interactive galmap. Since the POI markers can sometimes be super close together, I figured it was time to split out the categories a bit more. Also, I've added an additional zoom level. The previous maximum zoom would double the size of the pixels, so this zoom level quadruples them, for when you want to get up close and personal to see where those POI markers are relative to each other.
I hate to keep bothering you but seems like your 'systems with missing coordinates' file is a bit not up to date with EDSM.
If you compare today's dumps you'd find that it has ~231k systems less. It also contains systems that do not exist in game (such as "Boewnst KJ-D d7-4871" or "Fine Ring Sector JH-V c2", they were removed/hidden from EDSM database as errors) or already have coordinates for a while now.
If you compare today's dumps you'd find that it has ~231k systems less. It also contains systems that do not exist in game (such as "Boewnst KJ-D d7-4871" or "Fine Ring Sector JH-V c2", they were removed/hidden from EDSM database as errors) or already have coordinates for a while now.
Right, I don't have any good way of handling deletions or updates on EDSM's side that aren't pushed out again as revisions in their dumps. Once or twice a year I try to pull the large dumps and do a comparison to see if anything's been deleted, but that's the only way I can find out. So when they do manual corrections on their side, I usually have no way of knowing, and so my list drifts apart from theirs gradually. It's a known limitation.
Having said that, it's probably a good time to run a comparison again, since it's been a while.
Having said that, it's probably a good time to run a comparison again, since it's been a while.
I've been making more tweaks to the algorithm for the saturation map. I stretched out the intermediate colors a little bit, to extract some more visible detail. And I was also able to get rid of some of the sector name override artifacts by switching it to parse the ID64 only, and not parse the system names. Between these two things, the map has gotten a lot smoother in key places, such as around the bubble, and more of the popular travel routes have started to become more visible, including the Colonia road.
No need to make too much of a hassle out of it, but have you considered to make a sector-wise sliced layer view from the top to bottom? To see how much the focus is on racing along the center plane vs above/below. I guess it would just multiply the uncertainty of estimating the total stars per sector vs the discovered ones...
Last edited:
Sorry, there is a set of maps with spacelife. And in particular the one with different objects, which cmdr. Marx calls "statics", i.e. three type of crystals and several types of mineral life. I guess, "mineral spheres" include both types solid and lattice? And there also is one more type of mineral life -- calcite plates, are they also included?
It looks like no one has. Here are the entries we have for those:
2019-02-26T23:52:34.000Z,0,-,L-Type Anomalies,Byoomao MI-S e4-5423,23292901575084,
2015-01-01T146640,21195,codex_ent_l_phn_part_clus_009 ,L05-Type Anomaly,Byoomao MI-S e4-5423,1005763,
2020-06-14T22:00:35Z,24020013,codex_ent_l_phn_part_clus_013,L09-Type Anomaly,Cyuefoo LC-D d12-0,3414165867,
2019-03-03T22:22:46.000Z,0,-,L-Type Anomalies,Juenae OX-U e2-8852 B,0,
2015-01-01T146636,21191,codex_ent_l_phn_part_clus_003 ,L01-Type Anomaly,Juenae OX-U e2-8852,13125198,
2019-01-24T23:33:43.000Z,0,-,L-Type Anomalies,Stuemeae FG-Y d7561,259804475954059,
2015-01-01T146637,21194,codex_ent_l_phn_part_clus_008 ,L04-Type Anomaly,Stuemeae FG-Y d7561,39180,
2019-02-26T18:17:29.000Z,0,-,L-Type Anomalies,Stuemeae KM-W c1-2236,614710919571218,
2015-01-01T146639,21194,codex_ent_l_phn_part_clus_008 ,L04-Type Anomaly,Stuemeae KM-W c1-2236,476543,
2015-01-01T146638,21194,codex_ent_l_phn_part_clus_008 ,L04-Type Anomaly,Stuemeae KM-W c1-6174,39193,
2019-03-09T18:24:46.000Z,0,-,L-Type Anomalies,Thaile HW-V e2-7,31639717276,
2020-02-02T10:31:24Z,24020010,codex_ent_l_phn_part_clus_010,L06-Type Anomaly,Thaile HW-V e2-7,31639717276,