ED Astrometrics: Maps and Visualizations

Orvidius

Orvidius
OK, the good news is that the galactic records generator is pretty adaptable to having some custom column rules, because of the way I had it automatically build a column list from the table definitions. I just had to add a few exceptions. For the moment I'm regenerating it with decimal castings for eccentricity and inclination.

Everything else though? We'll see. :D I have about a hundred different scripts. Anything wanting precision from those float columns will have to be made aware. I might look at it on a case-by-case basis. But I can probably have some big wins with just a handful of them, including the dump generator. But getting the galactic records looking better will help a lot here.
 

Eahlstan

E
I just thought it might be easier to do that cast thing than to alter all your tables if it's just an output error.
Glad you found a way :)
 

Orvidius

Orvidius
Yeah, either way kinda sucks. Either spend a lot of time modifying tables, or a lot of time modifying scripts. ;) But I think you're right, modifying scripts is the easier path, when you consider that the database would probably spend the next week or two rebuilding tables.

I have some fixes in some of the scripts that do the heavier lifting for body spreadsheets, and the body dumps.

And I definitely learned something here. I thought I only had to deal with typical floating point precision. It never occurred to me that the database would do additional rounding, including all the way to an integer output, even when more precision is available in the stored value. Yick.
 

Eahlstan

E
Talking about errors...
You seem to have a replacement error, every body (and maybe other things too) that contain a ' got a " on your site.
E.g. Hi'iaka is Hi''iaka (Can be seen here.)
 

Orvidius

Orvidius
Yep, bad data has always been a problem. Garbage in, garbage out. Part of the problem is that EDSM has had bad data (or bad values have been submitted over EDDN), then EDSM may have subsequently fixed it manually, and those fixes never make it into the weekly dumps. For cases like that, the best I can do is just delete the value, probably. Or force an API pull from EDSM, depending on whether it's actually been corrected.

EDIT: But yeah, I'll nuke some of those obviously wrong values. In the case of 'Hegeia RX-O b33-0 3 a', it was originally scanned in 2017, and had an absurdly large number in the JSON from EDSM. It looks like EDSM has deleted the bodies in that system since then.

EDIT 2: It looks like data from back then had a lot that were listed in degrees instead of radians.

EDIT 3: And thankfully no stars are suffering from this problem. The planets table takes longer to scan though. ;)
 
Last edited:

Eahlstan

E
Orvidius said:
EDIT 2: It looks like data from back then had a lot that were listed in degrees instead of radians.
Click to expand...
That's strange, neither EDDN nor EDSM had converted them ever and the journal had them in radians since the very beginning.

€: Maybe some values were from some kind screenscraping or manual submissions.
 

Orvidius

Orvidius
Yeah, it's hard to say. The older EDSM data had that though. I have a dump from 2018 where many of the values were quite large (meaning they were outside the -pi to +pi range).

I ran a query against the planets and walked away from it last night, and I'm only now getting a chance to look. As it turns out, that one planet was the only one still broken in my database, so I think we're good. I manually nuked the number since I can't trust whether it was completely erroneous, or in degrees, or what.
 

Eahlstan

E
You named one of your sheets
Tidally Locked with unequal periods (50%+ difference, either direction)
Click to expand...
and put a percentage column in it.
But your percentage calculation doesn't take the lower value as base (100%), sometimes (all the time?) it's the larger value, therefore if you sort by the percentage column it starts with 33.33333% rather than with 50%.

(1 is 66.6666% of 1.5 - difference 33.3333%, but 1.5 is 150% of 1 - difference 50%. Sorry my english skills seem to lack the right words to describe it the right way.)
 

Orvidius

Orvidius
Ah, yeah that's a good point. It's looking for a 50%+ difference in either direction in the lookup (orbit/spin, or spin/orbit), but it's displaying it with only the orbital period being used as the base. I can fix that.
 

CDD_Juriy

CDD_Juriy
Hi there! First, thanks to Orvidius for the amazing EDastro project. Found it recently. This is great! And I immediately came across artifacts on an interactive map. What it is?! Hacker attack? Or a bad joke from FDev?
Hiiii.jpg
Hiii1.jpg
I wonder what value of the Y coordinate is this on? ;) Can this be determined?
PS) Sorry if this issue has already been discussed. At least I didn't find it in this thread.
 

CDD_Juriy

CDD_Juriy
Ahem, soon the galaxy will resemble the walls of a public toilet. And we will have to assemble an expedition to erase (clean, brush ...) individual "works of art".☹️
 
Last edited:

Orvidius

Orvidius
A lot of the circles are people trying to find the edges of permit-locked regions. But drawings like the snake are intentionally done by players. To some degree you can see their "altitude" by looking at the sector viewer. You can turn on the sector overlay in the interactive map to get a sector name to search for in the Sector Viewer. The snake is mostly in this one, for instance:

https://edastro.com/sector/view#Moijoe
 

CDD_Juriy

CDD_Juriy
Hi everyone. Dear Orvidius, I propose to consider the idea of layer-by-layer display of the galaxy. To some extent, this is implemented in sector-by-sector viewing. But the fact is that the sectors are often large, and the depth (along the Y axis) is greater than 1000LY. And this is brought in in 1 pixel. I think it's technically possible. When displaying a layer, it is necessary to filter systems by the Y coordinate. What are the advantages of this? You will be able to truly see uncharted areas. By the way, large areas. Closed sectors will be displayed more clearly (now they are overlapped by visited systems from the top and bottom). Probably something else. What are the cons? Volumes, volumes and volumes. Each layer will be the same size and the number will increase. After all, the number of pixels in each layer will not change.
M-Layer.jpg
Perhaps not now, not right away. But I would like to see it. Thanks.
 

Orvidius

Orvidius
I'll keep it in mind. Right now the maps all take hours to generate, and require lots of memory in order to create them in parallel so that the data only has to be pulled from the database and processed once. Anything I add has to to take these requirements into consideration, which is why they don't already exist. ;)
 

Deleted member 115407

D
Orvidius said:
---------------------
NOTE: All current maps are available here: --> https://edastro.com/ <--
---------------------


I know there are a variety of maps and graphs available through EDD, EDSM, etc, but for fun I thought I might try building a local copy of the EDSM data, and do some of my own. So far I have about 2/3 of the stars imported into MySQL (it's probably going to be a 24 hour load, from start to finish). But I managed to get my first map script working.

This is a logarithmic heat map of scanned stars (not visited star systems), including secondaries, colorized by stellar class (color temperature, basically).

I'm tempted to add a small HR-Diagram in the corner, some scale rulers, etc.

Thumbnail:

3Y9Dnlr.jpg


Click here for "low" resolution image (2320x2320, 1.5 MB)

In the above "low res" link, each pixel represents 50x50 lightyears. My hope is to generate this at 5x the linear resolution, with a 10 ly resolution, though that's taxing the system right now (server has only 12 GB RAM at the moment), so I'm testing at this much lower res.

I'm using a somewhat older server, and having to do some programming tricks to keep the memory footprint low, and deal with this enormous data set. It's turning out to be a fun little project. I haven't decided what else I want to do with it yet, but I thought I'd share.
Click to expand...
That's pretty cool, dude.
 

CDD_Juriy

CDD_Juriy
Hi, Dear Orvidius. Are small ideas for improvement accepted here? In a sector-by-sector view, it is good to have a display of coordinates, as on an interactive map. Something like this:
Sector.jpg
 
You must log in or register to reply here.
Back
Top Bottom