ED Astrometrics: Maps and Visualizations

Regarding the sector viewer there seems to be a little issue regarding the weekly updates.
Like last week I could see the results till 2021-10-08, but at the weekend that was replaced by a result for 2021-10-14, and then added another shot for 2021-10-15. The one for 2021-10-08 is gone, can't get it by editing the file name either.
 
Yep, it stores a 2-week snapshot (fortnightly images). On the in-between weekend, it creates a current image that will get replaced on the final weekend for that fortnight.

So you can think of it like this, on the odd weeks it shows intervals that end in week lengths 2-2-2-1, and on the even weeks it ends with length intervals 2-2-2-2. I set it up that way so that each week the final image would be pretty current (never more than a week old), even though it's doing fortnightly time slices.
 
Okay, yeah that makes sense and is perfectly fine.
There is just another minor diddely-littely thing then - I don't think we really need the 2021-10-15 this week, the 2021-10-14 would be current enough until we get the 2021-10-21 (I guess, which another week later will be replaced by 2021-10-28).
 
Yeah, I'm not sure why it made them on back-to-back days like that. Probably worth investigating at some point. But yep, that latter one is the one that will get replaced.
 
Oh also, I'm still considering putting it back to weekly snapshots at some point. It's just a question of how far back in time it'll be able to go, and how much storage space on the server is needed. It's a lot of image data. :D
 
I've managed to add some space and move things around, so I'm going to try setting the sector viewer to 1-week snapshot intervals. It'll still be able to look back about half a year too. Fingers crossed that this works correctly. ;)
 
OK, the update finished, and everything looks OK. Sector viewer now will show about 6 months of weekly snapshots. The latest image is from the 19th, since I ran it yesterday. I've changed the schedule to run on thursdays, since the math was placing the week transition there (rather than changing the math to coincide with Fridays). This last part should resolve the 1-day step at the end on some weeks.
 
We're almost at 100% for id64 data. I only have 11 systems left that don't have an associated id64. Some of these are due to EDSM not understanding cases of duplicate system names existing in-game, but most are still individual systems. An example of a duplicate name is the first one in the list below (Yeliseyev.1), for which I have the id64 from one of the systems, but not the other (I haven't verified for sure that it exists twice in-game, but that's usually been the case for examples like this that I've looked at). I could really use some fresh visits/scans at these locations. I may visit them myself at some point if no one else beats me to it, but it'll be a while before I look into that.

Code:
> select name,coord_x,coord_y,coord_z from systems where (id64 is null or id64=0) and deletionState=0;         
+-------------------------+----------+----------+----------+
| name                    | coord_x  | coord_y  | coord_z  |
+-------------------------+----------+----------+----------+
| Yeliseyev.1             |  601.438 | -437.188 | -1081.19 |
| NGC 2168 SB 126         |   288.75 |  96.4375 |    -2565 |
| NGC 2168 BSB 5587       |  326.781 |      110 | -2873.41 |
| NGC 2168 BSB 6371       |  318.344 |  105.844 | -2756.69 |
| NGC 2168 BSB 6311       |  307.156 |  105.125 | -2636.09 |
| NGC 2168 SB 1131        |  288.719 |  102.625 | -2482.16 |
| NGC 2168 BSB 5720       |  292.375 |  98.4688 | -2521.22 |
| HIP 108048              | -2470.16 | -168.344 |     -263 |
| 2MASS J17463650+0616484 | -568.625 |  341.312 |    939.5 |
| HD 165417               | -3288.97 |  1458.09 |  3609.56 |
| HD 208203               | -1799.12 | -1335.44 |  752.312 |
+-------------------------+----------+----------+----------+
11 rows in set (0.001 sec)
 
All systems visited, scanned, and uploaded to EDSM.

Side note: HIP 108048 has ~40 bodies that are largely unmapped, fair number of bio/geo signals ... if you fancy flying 475K ls.

Additional note: EDSM shows three results for NGC 2168 SB 126, none of which record my visit, but EDD confirms I visited, scanned, and uploaded to EDDN/EDSM.
 
Last edited:
Awesome, thanks! I can confirm that in my data, those have filled in their ID64s. The only exception is "Yeliseyev.1" which appears to exist twice, with different coordinates. The one at 601.438 / -437.188 / -1081.19 is still an unknown ID64. It's entirely possible that it just might not have updated correctly, even if it came through. I have all sorts of circuitous rules about how to handle updates where id64 is missing, and there are multiple rows of the same name. ;)
 
Is this the data you need? Looks like the coordinates don't match.

{ "timestamp":"2021-10-23T18:08:46Z", "event":"FSDJump", "StarSystem":"Yeliseyev.1", "SystemAddress":22654742963137, "StarPos":[-484.68750,-486.40625,-1218.90625], "SystemAllegiance":"", "SystemEconomy":"$economy_None;", "SystemEconomy_Localised":"None", "SystemSecondEconomy":"$economy_None;", "SystemSecondEconomy_Localised":"None", "SystemGovernment":"$government_None;", "SystemGovernment_Localised":"None", "SystemSecurity":"$GAlAXY_MAP_INFO_state_anarchy;", "SystemSecurity_Localised":"Anarchy", "Population":0, "Body":"Yeliseyev.1 A", "BodyID":1, "BodyType":"Star", "JumpDist":17.829, "FuelUsed":0.230394, "FuelLevel":31.769606 }
{ "timestamp":"2021-10-23T18:08:52Z", "event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":2, "NonBodyCount":0, "SystemName":"Yeliseyev.1", "SystemAddress":22654742963137 }
{ "timestamp":"2021-10-23T18:08:52Z", "event":"Scan", "ScanType":"AutoScan", "BodyName":"Yeliseyev.1 A", "BodyID":1, "Parents":[ {"Null":0} ], "StarSystem":"Yeliseyev.1", "SystemAddress":22654742963137, "DistanceFromArrivalLS":0.000000, "StarType":"M", "Subclass":4, "StellarMass":0.292969, "Radius":322407360.000000, "AbsoluteMagnitude":9.757492, "Age_MY":9248, "SurfaceTemperature":2728.000000, "Luminosity":"V", "SemiMajorAxis":2548740565776.825195, "Eccentricity":0.184807, "OrbitalInclination":-38.271713, "Periapsis":348.742899, "OrbitalPeriod":23644140958.786011, "RotationPeriod":158674.615011, "AxialTilt":0.000000, "WasDiscovered":true, "WasMapped":false }
 
Found the one you are referencing. It is called "Yeliseyev.2" in the game, a search for the prefix finds Yeliseyev.1 but searching again does not jump to the .2. I'm a ways away from it now but I may get to it soonish.
 
Ah, with the name "Yeliseyev.2", I do indeed have that in the data. It appears that's the correct one, so this other "Yeliseyev.1" with those coordinates is just a bad entry then. I'll mark that one as deleted, so there's no need to visit it now. Thanks!
 
OK, it's back in working order. If any particular sector still looks broken to you, try clearing the browser cache (perhaps just today's cache data).

EDIT: It looks like there's still some broken data for some sectors. I'm running a more proper update now.

EDIT 2: I think we're looking good.
 
Last edited:
Some minor updates. I've updated the ship templates to include the double-engineered FSD stats for all ships that will have it available.

Also some tweaks to the DSSA map to include a little more real-time info. It'll now indicate when a carrier is detected as being "off station" (away from designated system). It's still not actually real time since it only updates about once every 4 hours, but this will also show where a carrier is when it's on the way toward deployment, etc. EDIT: This part relies on EDDN data, primarily the docking events. So the carriers may not actually be located at the "last seen" locations, depending on whether anyone has been docking at the carrier and sending data.

The DSSA map has a nice shorter URL now too.

https://edastro.com/galmap/DSSA

That basically just starts up the interactive map with some DSSA default settings.
 
Hi there, I've a data request for you. Do you have, or can you make, a list of planets with the shortest rotational periods (ideally including whether landable)? That doesn't seem to be a variable that any of the existing sites let you use as a search term. Spansh at least allows sorting by rot period, but the existence of both positive and negative values makes that notably less useful for finding values close to zero. Thanks!
 
Hi there, I've a data request for you. Do you have, or can you make, a list of planets with the shortest rotational periods (ideally including whether landable)? That doesn't seem to be a variable that any of the existing sites let you use as a search term. Spansh at least allows sorting by rot period, but the existence of both positive and negative values makes that notably less useful for finding values close to zero. Thanks!
Funny you should ask about that, I've been trying to do the exact same thing. I went out to Dryio Flyuae GS-K d8-40 1, which has a rotational period of 0.00013194444 days according to the records page for landable bodies, only to find that the actual rotational period is 11.4 days. I downloaded the galaxy data dump from Spansh, and will be looking into making a list of the fastest spinning landable planets soon.
 
Yeah, I think I can pull some data on that (building an index first). I might also have to consider making the records system also look at absolute value for that.
 
Last edited:
Back
Top Bottom