ED Astrometrics: Maps and Visualizations

[Orvidius]

Ignore previous post, used Notepad++ to open it, however it appears I have either already found all the ones in my current search criteria, or they didn't make it through your filter, looking for systems with KOI **** (where the asterisks are numbers with either 2, 3 or 4 digits. It's not a huge set so I may coincidentally just found the last system with no main star.

Ah yes, I have it looking at proc-gen names only and not the catalog stars. I'll take off the restriction and regenerate it. It'll probably include a few false positives in cases where the main star wasn't easily discernible by name.

Is there something hanging at your sector viewer script?
For some time the last days shown were 2021-08-19 and 2021-08-20. Today It changed to 2021-08-19 and 2021-08-27, but the last two pictures are still labeled 2021-08-19 and 2021-08-20, and since I added a few hundred systems to the sector I'm in ( https://edastro.com/sector/view#Blia_Chria ) I can say for sure that the last picture isn't from 2021-08-27.

Hmm, yeah it's possible an update failed to run properly. I'll take a look.

 

[Orvidius]

I'm running a sector update again now. When I look though, the last one does appear to be labeled as 2021-08-27. This might be a caching issue in your browser. If you had an image from 2021-08-20 cached, it likely regenerated with the same filename and even though there's a new timestamp, your browser might be pulling it from the cache anyway. You can try holding down shift and hit the reload button (in most browsers) to force a fresh pull of all content on the page.

Basically the update runs on Friday evenings every week, and updates the most recent image with the current information. But since it's a 2-week interval in the saved images, it ends up using the same filename for two weeks in a row. The filename is generated based on the time interval, which in this case is fortnights.

I can probably do some URL fudging to avoid this in the future, but for now that's a good workaround.

EDIT: I've added some URL munging. Take a look again and let me know if it looks better.

 

[Eahlstan]

I also tried it with a browser that never had your site opened before I wrote that post to be sure that it isn't a caching issue (also I always force a reload on it before I report such things). Also I randomly opened a few other sectors and they were all the same. It's just that I definitely knew that this specific sector got additional systems.

On a side note: When Robby recoded the server feature of EDDiscovery we ran in a caching issue that didn't affect all user configurations too. We ended up tagging the images with

Cache-Control: no-store

so that browsers stop caching them at all. Maybe that is something you could do too?

( Line 121 here: https://github.com/EDDiscovery/EDDiscovery/blob/master/EDDiscovery/WebServer/EDDWebScanDisplay.cs )

€dit:

EDIT: I've added some URL munging. Take a look again and let me know if it looks better.

It does load the new imagine now.

 

[varonica]

Ah yes, I have it looking at proc-gen names only and not the catalog stars. I'll take off the restriction and regenerate it. It'll probably include a few false positives in cases where the main star wasn't easily discernible by name.

Ah ok, I tested a few other catalogue star names and also found nothing so I figured it was something like that, look forward to the new file!

A few false positives are fine, just means I fly around a bit more, never had a problem with that!

 

[Orvidius]

It does load the new imagine now.

Yeah, I figured you probably did some good testing, but you never know. Glad it's loading the right one now. I added the date to the URL, so if the date changes on the same filename, the browser will see it as a fresh new URL in any case.

Ah ok, I tested a few other catalogue star names and also found nothing so I figured it was something like that, look forward to the new file!

A few false positives are fine, just means I fly around a bit more, never had a problem with that!

OK, the new file should be up.

 

[varonica]

OK, the new file should be up.

Excellent work, more than I expected, 533 systems, but not as bad as it could have been I suppose, now to add that to my "to be visited" list

 

[varonica]

Oh yes was poking through the records section and found this entry;

Radius Planets	Highest:​		90,000​	: Sharur B 1	​
Lowest:​		16.13375​	: Grea Priae KZ-R b24-0 6 a	​
Average:​		8,874.8257​
Count: 236,259,414	Standard Deviation:​		17,543.0250​

Table didn't work well but you can see you have a radius of 16.13375 for Grea Priae KZ-R b24-0 6 a whereas it's actually 3,116 (and various decimal points I am sure). The lowest possible radius should be around the 170km+ range. Just a heads up that there may be an issue with the way your records are being pulled from the data.

Ok another thing, rather strange, list of systems without main stars still does not appear to be complete, for instance this systems;

EDSM - Elite Dangerous Star Map

The Galactic Positioning System of Elite: Dangerous at your service.

www.edsm.net

Has no bodies listed, but it apparantly didn't make it into the list, rather strange!

 

[Orvidius]

Yeah, there has definitely been some bad data at times, particularly with some radius information on older entries. I had to re-scan old EDSM dumps to pull out the decimal numbers again recently, and so some of the previously cleaned up bad data probably stealthily found its way back in. Looks like some more cleanup is in order. Yay.

For "KOI 2976", I actually do have the star in the data (G-class, and discovered late in 2017), but apparently EDSM doesn't. Wow, that's a rare case. That usually means I probably either got it from EDDN (not in this case, because of the date) or from a Spansh dump, and somehow EDSM never got it. Either that or it was data that EDSM purged and then the system was re-added without an additional star scan somehow.

 

[varonica]

Yeah, there has definitely been some bad data at times, particularly with some radius information on older entries. I had to re-scan old EDSM dumps to pull out the decimal numbers again recently, and so some of the previously cleaned up bad data probably stealthily found its way back in. Looks like some more cleanup is in order. Yay.

For "KOI 2976", I actually do have the star in the data (G-class, and discovered late in 2017), but apparently EDSM doesn't. Wow, that's a rare case. That usually means I probably either got it from EDDN (not in this case, because of the date) or from a Spansh dump, and somehow EDSM never got it. Either that or it was data that EDSM purged and then the system was re-added without an additional star scan somehow.

Yeah, bizarre, I will just have to work with what we have I suppose. That was the second one I found, the first was KOI 833, that was empty and in EDSM but not in the table. I suspect it may be the really old entries, maybe they were removed from EDSM during a data cleanup as bad data. Once I've scanned and recorded as much as I can I will have to look through the data and try and find everything I miss, oh well.

 

[Orvidius]

Whew, it looks like the radius data isn't too bad. I have some zeroes from older data (to be expected, and are ignored in the records calculations), and only that one Icy body with a ridiculous radius. I'll try to see if I can sync that one and the zeroes too back from EDSM's current data again.

Unfortunately for some of the older data, EDSM may or may not have it. To save on space, EDSM started deleting data that was visited only once, and that commander hadn't logged into EDSM for at least a year. I think they've stopped deleting now, but unfortunately some data was lost on their side when they were hitting the server hosting limits.

 

[Eahlstan]

You might find those data in Bravada's dumps though: https://edgalaxydata.space/EDSM/

The lowest possible radius should be around the 170km+ range.

Most likely the lowest possible radius for planets is around 137 km. Quite a few metal-rich bodies close to that value have been found.

 

[Orvidius]

Yeah, I think the overall minimum possible radius is 137. It looks like the smallest proc-gen icy body currently on record is about 393.32140625. The icy bodies that are smaller than that appear to be the hand-crafted ones in Sol.

 

[varonica]

You might find those data in Bravada's dumps though: https://edgalaxydata.space/EDSM/


Most likely the lowest possible radius for planets is around 137 km. Quite a few metal-rich bodies close to that value have been found.

Of course that's right, I was making a mistake, 137klm is the correct number for minimum radius. I should have known better, I made a point of visiting as many planets/moons of that size as I could a long time ago, but they were all pretty boring at the time, they've changed for the better in Odyssey!

 

[varonica]

Whew, it looks like the radius data isn't too bad. I have some zeroes from older data (to be expected, and are ignored in the records calculations), and only that one Icy body with a ridiculous radius. I'll try to see if I can sync that one and the zeroes too back from EDSM's current data again.

Unfortunately for some of the older data, EDSM may or may not have it. To save on space, EDSM started deleting data that was visited only once, and that commander hadn't logged into EDSM for at least a year. I think they've stopped deleting now, but unfortunately some data was lost on their side when they were hitting the server hosting limits.

Ok I think I have it, there's a difference between the ones that made it in and the ones that didn't. The systems that made it into the list have first visited tags attached, the systems that didn't make it into the list don't have first visited names. For instance KOI 94 has Spacemutant14 listed as the first visitor to the system but no star or planets. KOI 856, which I am heading for now has no star or planets listed, but also no first visitor listed.

I've done some random picking out of numbers from the list and they all seem to have first visited tags, so something is happening there that separates the ones with a first visitor tag and the ones with no first visitor tag when doing the filtering!

 

[Orvidius]

So yeah, looking at "KOI 856", I have all of the body data from 2017 as well. It must be another case of EDSM purging it, then. I show an F-star discovered in December of 2017, and 12 planets.

For "KOI 94", I have no body data in the database.

I'm also re-generating the galactic records after fixing those icy body radii. It'll take several hours (and has already been running for a few).

EDIT: Definitely feel free to report strange numbers in the records here. I sometimes feel like I'm doing the "whack-a-mole" thing with it, but for the records to be useful, the broken edge cases have to either be corrected or have the values deleted if there's no better data.

 

[Eahlstan]

Well, if you insist
(I always fear that you start hating me for reporting too many things.)

Elite:Dangerous Astrometrics

edastro.com

Class I gas giant Lowest: 0.000219
Class I gas giant (as moon) Lowest: 0.734365
Class I gas giant (as planet) Lowest: 0.001237

Same for highest, same for Class II, Class III, ... Guess it's a thing that affects all bodies where you go for overall - moon - planet.
It also affects other stats e.g. gravity, radius, ...

Also their numbers don't add up. E.g. it's 10,695,990 class I overall and 50,790 as moons, which should be 10,645,200 as planets, but there are only 10,596,030.

 

[varonica]

So yeah, looking at "KOI 856", I have all of the body data from 2017 as well. It must be another case of EDSM purging it, then. I show an F-star discovered in December of 2017, and 12 planets.

So it was visited and reported with data like the main star, then later purged from EDSM after you downloaded your data? I wonder what criteria EDSM uses to purge data, did that happen when they moved everything to the new servers I wonder, because there was a bit of hold up there, would have been a huge task at the time and they might have been trying to minimise the amount of data they were moving around.

 

[varonica]

Unfortunately for some of the older data, EDSM may or may not have it. To save on space, EDSM started deleting data that was visited only once, and that commander hadn't logged into EDSM for at least a year. I think they've stopped deleting now, but unfortunately some data was lost on their side when they were hitting the server hosting limits.

Interestingly, now you mention that, a lot of the systems I am visiting with no data and no first visited tag in EDSM can be attritbuted to a particular CMDR, as I find more it's becoming clearer that the data for this CMDR may have been deleted from EDSM, a CMDR RAIGEK1228 (not certain if that's the number 1 or an I) seems to have visited and completely scanned (but not mapped) a lot of these systems. Probably before the FSS since there were couple of ELW and they weren't mapped.

 

[varonica]

Ok done, a carrier jump with a CMDR on board will record the stars and asteroid belts and a first visited tag to EDSM, so systems with no data can't be attributed to FC's, an empty FC won't report any data, and a CMDR on board will record at least the main star and a first visited tag!

 

[Orvidius]

Also their numbers don't add up. E.g. it's 10,695,990 class I overall and 50,790 as moons, which should be 10,645,200 as planets, but there are only 10,596,030.

I'm not worried about that part. All it means is that there are some cases in which it couldn't tell which category it belonged in, so it counts toward the total but not the categories.