ED Astrometrics: Maps and Visualizations

[Orvidius]

And I've fixed a few more bugs, including cleaning up some erroneous lines to Sol, and gaps between separate journal files.

 

[Orvidius]

I've also added the ability to sort the ship data table.

 

[Orvidius]

I finally got around to adding a section for exobiology on the exploration tips page:

https://edastro.com/exploration/#exobio

Also added a spreadsheet of the top closest binary star orbits. There's not much variation here, so I might lengthen the list later, or change the metric. But for now it's looking at the "average" orbital separation by adding the two SemiMajor Axes. So this is a distance between their centers, not their surfaces. I might consider making a second list based on the surface distances (subtracting their radii).

https://edastro.com/mapcharts/files/tightest-binary-stars.csv

 

[Orvidius]

Now I've added the "surface-to-surface" version of the tightest-orbiting binary stars. This one is much more interesting, I think:

https://edastro.com/mapcharts/files/tightest-binary-stars-surface.csv

 

[Orvidius]

This is very much still a work in progress, and can break at any moment while I'm working on it. But I think it's far enough along to show it off a little bit.

I'm working on a real-time map of EDDN exploration activity. Opening it up in the web browser does an initial pull of the last half hour's worth of EDDN events, and maps them. As long as you leave it open in the browser, it will auto-update, downloading the deltas and redrawing the map dynamically (including if you change the pixel scale slider, or if you resize the window).

Activity spots on the map are colorized so that brighter is more recent, and the locations fade as they age away. This allows you to see some nice streaks on the map where someone is traveling at a fast pace.

A fun little "easter egg" that might be appreciated here-- the background nebula image on the page is the real-world NGC 7822. Because it's always NGC 7822.

https://edastro.com/eddn/

EDIT: The EDDN events are managed server-side, and what the client sees is a subset of events, limited to jumps and scans, and only looks at the coordinates. This keeps the data footprint small, and only the server needs to be subscribed to the EDDN feed.

 

[LifesAJourney]

Cool thing! WIll it be possible to add zooming in/out the map?

 

[Orvidius]

Probably not, with the way I have this set up, but I'll put some thought into how that might be doable. So, I'll say "maybe". Right now I have it designed to be as fast and lightweight as possible.

 

[Orvidius]

I've added a pop-up display for types of bodies scanned within the last hour. It'll continue to update (including this table) with the popup open.

The hourly commanders graph has these weird little "spikes" every 12 hours. It turns out that this is the interval in which EDDN expires the uploaderIDs, so presumably anyone actively transmitting through EDDN gets assigned a new ID and it looks like there's a sudden influx of "new" uploaders. I don't think I have a way to filter that out, so when looking at the graphs, we just have to ignore the spikes at the 12 hour intervals.

 

[Eahlstan]

Is there a way you could be more precise on orbital inclinations?

E.g. your records for class I giants says there are two bodies with an inclination of -180 (and so does your class I csv), but EDSM says one of them is actually -179.999756 and the other one is -179.999988.

 

[Orvidius]

Hmm. Eock Groa UW-L b40-1 BC 3 shows as -180 on EDSM when I look there. I store it as a "float", so I shouldn't be losing any precision.

EDIT: I'll still look into it. Just won't have much over the next few days.

EDIT 2: I do see a "-179.999756" for Eock Groa UW-L b40-1 BC 3 in the original JSONs, so not sure when that would have been overwritten. It's possible a later update came in with a rounded value or something. I may have to restore values from those archives or something.

 

[Eahlstan]

Hmm. Eock Groa UW-L b40-1 BC 3 shows as -180 on EDSM when I look there. I store it as a "float", so I shouldn't be losing any precision.

I used the EDSM API to look it up, as the site itself rounds most values.

{
      "id": 305235143,
      "id64": 540436017409020123,
      "bodyId": 15,
      "name": "Dryae Flyoae NY-H d10-118 A 8",
      "discovery": {
        "commander": "RecessiveHagis",
        "date": "2021-04-12 21:53:32"
      },
      "type": "Planet",
      "subType": "Class I gas giant",
      "parents": [
        {
          "Star": 1
        },
        {
          "Null": 0
        }
      ],
      "distanceToArrival": 3777,
      "isLandable": false,
      "gravity": 1.5135543025326548,
      "earthMasses": 17.174541,
      "radius": 21484.64,
      "surfaceTemperature": 135,
      "surfacePressure": 0,
      "volcanismType": "No volcanism",
      "atmosphereType": "No atmosphere",
      "atmosphereComposition": {
        "Hydrogen": 74.11,
        "Helium": 25.89
      },
      "solidComposition": null,
      "terraformingState": "Not terraformable",
      "orbitalPeriod": 5178.425943961805,
      "semiMajorAxis": 6.141892255339167,
      "orbitalEccentricity": 0.314723,
      "orbitalInclination": -179.999988,
      "argOfPeriapsis": 223.851824,
      "rotationalPeriod": 1.1571521667939815,
      "rotationalPeriodTidallyLocked": false,
      "axialTilt": -0.276266,
      "updateTime": "2021-04-12 21:53:32"
    }

 

[CMDR Von Abrahart]

Thats just excellent have a few stars ️. Thats excellent - sis you use Open GL to write the image? Excellent - I’m going to download and print it for my living room. Imagine this as a hologram on a concourse in a planet mapping room - have another ️

 

[Orvidius]

I used the EDSM API to look it up, as the site itself rounds most values.

Yeah, I figured that's probably what you were looking at when I was able to find it in the JSON dumps with the full number. It's very strange. I'm not doing any rounding, so I still don't know how it got in there that way. Maybe I used to have something that I've since removed, and can't remember. I'm restoring what I can from the JSONs. I'm doing so cautiously (trying not to change the number by more than +/- 1, just in case), so it might take more than one pass.

 

[Orvidius]

Thats just excellent have a few stars ️. Thats excellent - sis you use Open GL to write the image? Excellent - I’m going to download and print it for my living room. Imagine this as a hologram on a concourse in a planet mapping room - have another ️

All of the images are generated in Perl using ImageMagick/PerlMagick. Glad you're enjoying it!

 

[Kelster87]

A fun little "easter egg" that might be appreciated here-- the background nebula image on the page is the real-world NGC 7822. Because it's always NGC 7822.

Except for when it isn't NGC 7822..

 

[Orvidius]

OK, so after some digging, it looks like the loss of precision (rounding to -180 for those two inclinations) is actually on the database side. I didn't know this, but MySQL has some default "smarts" about this, rounding under certain circumstances. It can also lose some precision in floats, by storing it as an actual float (somewhere I had previously read that they were doing string or decimal storage to avoid this, which appears false). So every time I update these rows with the correct values, it comes back as -180.

-- facepalm --

So, it looks like I have to change the column types, using "decimal" (instead of "float") with a wide number of digits for precision. And of course, rebuilding a column is slow. And I might want to do this to most or all of the floats that I store. At least the ones where we care about 0.001 or smaller increments. Oof.

EDIT: For now I might fix inclination and eccentricity, since they both can deal with small, precise numbers.

I'll get this fixed eventually.

 

[Eahlstan]

Isn't it nice to gain more knowledge?

From a doc I found:

FLOAT stores 24 significant bits of data (equivalent to about 7 decimal digits; storage=4 bytes), with an exponent ranging over about 10 ** +/-38.

DOUBLE stores 53 bits (about 16 digits, 8 bytes) and has a huge range.

Personally and from my very limited experience I never ran into that problem as I always use decimal because I like that I can define how many digits before and after the decimal seperator are stored.

 

[Orvidius]

Yep, I'd have gotten further with a double, but it would suffer from some of the same issues (EDIT: The problem was twofold, one of which was float precision, the other was MySQL's automatic rounding of floats). Decimal stores exact digits, but you have to specify the maximum ranges in advance. So for the columns that store mostly small numbers (inclination and eccentricity, for instance), Decimal will probably be best. I might convert some of the others to doubles.

 

[Eahlstan]

Are you sure it's actually rounded by MySQL? I couldn't find a doc mentioning that (my search wasn't very long though) but some guys who say it's not a storage problem but an output problem and that you can see the actual stored value with

select cast(some_float_field as decimal(8, 3))

Of course modified with the decimal values you want to see and stored.

 

[Orvidius]

Yeah, I was seeing things on StackOverflow about how the value gets rounded on output. There are some column definitions that can be applied when creating the column that define the number of digits to round to, which are considered deprecated settings now. But yeah, I might be able to do a cast like that, but I was thinking that storing the precise Decimal digits could be better in this case since it won't lose any precision with very small numerical differences.

In the above example, the "decimal(8,3)" would display to three decimal places, rounding appropriately.

Here's what I get doing "decimal(9,6)" casting for those two "-180" planets:

MariaDB [elite]> select bodyId64,edsmID,name,orbitalInclination inclination,cast(orbitalInclination as decimal(9,6)) incdecimal from planets where name='Eock Groa UW-L b40-1 BC 3' or name='Dryae Flyoae NY-H d10-118 A 8';  
+--------------------+-----------+-------------------------------+-------------+-------------+
| bodyId64           | edsmID    | name                          | inclination | incdecimal  |
+--------------------+-----------+-------------------------------+-------------+-------------+
| 540436017409020123 | 305235143 | Dryae Flyoae NY-H d10-118 A 8 |        -180 | -179.999985 |
| 864693661545485657 |  22853615 | Eock Groa UW-L b40-1 BC 3     |        -180 | -179.999756 |
+--------------------+-----------+-------------------------------+-------------+-------------+
2 rows in set (0.002 sec)

That "-179.999756" actually does match the JSON. Hmm. Forcing a cast in some of the scripts is a bit annoying, but doable. I'll cancel the column conversion for now, since it's going to take a looooong time, and see how much work this might entail.