ED Astrometrics: Maps and Visualizations

Oh this is a delightful development! I don't have strong opinions about the time cadence, although it's certainly interesting to be able to see the changes. However, this is the closest I've yet seen to a good way to visualize the 3D structure of this data! Fascinating to click around the center for example, and note how most of the overlapping routes that make the area look well-explored in the full stack view, are actually narrow corridors that don't extend vertically beyond a single sector.
 
More time steps have finished rendering, and I have another batch running. This will bring it up to 14 fortnights into the past. At about 11 past steps, the disk footprint of the images was a little over 4 GB, which is manageable. So I think adding a few more will be OK.

I've also inserted the text-search form into the bottom of each page.
 
That already looks damn sweet :)

I assembled a quick & dirty GIF for the Sector I'm in :
Myrierph_Sector_EDastro.gif

Huh, doesn't look like it's embedding properly. I only see the filename.
 

Deleted member 38366

D
Hehe, very nice! :)

This gives me another fancy idea....
I wonder if the underlying Data (known Systems per Sector) would allow to determine i.e. "most Developing Sector of the month" or something.

If the percentage change of known Systems per Sector is used as a metric, that could produce a ranking (most dynamic 3 Sectors of the month).
I guess total amount of Systems known would show the Sectors containing the most busy traffic, while the Sectors with the highest percentage changes the ones "most developing" in a sense.

Just doing fun stuff with numbers and getting something interesting out of it, like "what were the 'hottest' 3 Sectors in {month/year}.
(otherwise, it could produce a Galaxy Map with "most busy" and "most developing" Sector overlay... showing where the most Exploration activity took place in the Galaxy)
 
Last edited by a moderator:
Huh, could be interesting. :)

Here's a top-10 for this month so far:

Code:
MariaDB [elite]> select sectors.name,count(*) from systems,sectors where sectors.ID=sectorID and date_added>='2021-03-01 00:00:00' group by sectorID order by count(*) desc limit 10;
+-------------+----------+
| name        | count(*) |
+-------------+----------+
| Eol Prou    |     4940 |
| Hypoe Bluae |     3624 |
| Blua Eaec   |     3285 |
| Clooku      |     3203 |
| Eoch Flyuae |     3114 |
| Stuemeae    |     2971 |
| Nyeajaae    |     2781 |
| Skaude      |     2667 |
| Pru Euq     |     2424 |
| Prua Phoe   |     2421 |
+-------------+----------+
10 rows in set (1.534 sec)
 

Deleted member 38366

D
Interesting...

Inner Scutum-Centaur Arm and Ryker's Hope are hotspots in terms of total Systems. Colonia effect I guess.

Any data on the Percentage increases per Sector in comparison? Wondering if some remote Sectors with tiny numbers might skew such a table, unsure about that.
 

Deleted member 38366

D
Two minor Details I noticed :

When entering some Sector Names such as "Col xxx" or "Mel 111", nothing shows up in the search lists. Same for any IC xxxx or NGC xxxx or Mxx Sectors.
If these are sub-sectors incorporated into parent Sectors, a search hit and then a redirect to the bigger parent Sector might be useful to avoid confusion ("Why is my Sector not in the Search Table, can't find it").

When using the UI to scroll in any direction, it refreshes and re-renders the entire screen (I have to scroll the Page a little but each time if I i.e. want to click Down or South on a standard FullHD Screen.
Would be neat if the Screen only updated the relevant parts, so the UI/Display remains stable on-screen if that's doable. Just a minor usability thingy.

But regardless : excellent work, I tip my hat !
Browsing the explored Galaxy never looked sexier and more informative :)
 
Last edited by a moderator:
Yep, known limitations. ;) Those alternate sector names are overrides, usually in spheres that may actually span across sector boundaries. I can try to think about ways to redirect it, but it would probably have to point to where the coordinate range for them is centered. Those systems are all included in the maps though, since I'm doing the sector categorization by id64's internal coordinates, and not the names.

Right now it's a custom HTML for each sector. Certainly not impossible to make it more dynamic, but that's for a later time.
 
I may work on both of those sooner rather than later. It occurs to me that since they both involve some rewrites of how I'm generating the HTML (which is fine, I just wanted to get it working first), they're probably more easily done together.

Heh, I should probably look at a 1920x1080 screen occasionally. I'm so used to using a much taller window. :D I'll see if there's an arrangement that works a little better.
 

Deleted member 38366

D
Haha, I feel so Low-Tech now... never had a higher-than FullHD Screen so far and my old Display still works with no signs of breaking (= excusing a purchase of a bigger and fancy new one) :D
 
Heh, I understand. I'm still using the same monitor after almost 15 years. Had to do a minor repair once, but otherwise it's still going.

Alrighty, an update! I have a more dynamic mode working on the UI now. It should only do full page reloads when you use the text search now. When using the buttons or the galaxy view, it should just reload the necessary assets. The URL format changed to accommodate this, but if you had anything bookmarked, it should redirect automatically.

I haven't worked on the sector name redirects for the "override" sectors. I'll need to build some tracking on the server side to find out where they should point to, etc. No ETA on that one yet. May take a break first. ;)
 
Looking at your sector list spreadsheet you already got average coordinates for all these sectors, wouldn't it be easy to simply center on those?
 
Haha, I feel so Low-Tech now... never had a higher-than FullHD Screen so far and my old Display still works with no signs of breaking (= excusing a purchase of a bigger and fancy new one) :D

I upgraded to 34" 3440x1440 last year when it became obvious I'd be working from home for a long time.

Had a day in the office last week (needed to fix a bug with some of the medium-fridge sized test equipment that people still have to go in to use) and suddenly the 24" 1920x1080 monitors, even though I had two, looked sooooo tiny.
 
Looking at your sector list spreadsheet you already got average coordinates for all these sectors, wouldn't it be easy to simply center on those?

Technically I can do it that way. Just trying not to rely on the spreadsheets if I can make something available in the database instead. ;) Haven't decided on the approach yet.

EDIT: The spreadsheets are generated the "slow" way, by looping over all systems in the database first, and keeping running totals/min/max. If I need to look something up quickly, I either need to store those sorts of details in the database, or make something rely on the spreadsheets. The latter is less "safe" because if one thing fails, it can cause other things that are "downstream" to fail too, so I try to limit dependencies between different things.
 
Yeah, I didn't exactly mean 'use the spreadsheet', more something like 'the averages won't change that much over time, so export it once to a location (DB) of your choice and use that', since you already calculate those averages I thought that would safe you time :)
 
Yeah, I didn't exactly mean 'use the spreadsheet', more something like 'the averages won't change that much over time, so export it once to a location (DB) of your choice and use that', since you already calculate those averages I thought that would safe you time :)

Heh, yeah. You're absolutely right, of course. Actually what I was thinking is that since the script is already doing the logic, it'll probably be able to store the results in the DB for me, and then I can use it from there. It's a subtle difference. If the program crashes, the spreadsheet can come up empty, but the previous DB details would still be there. And as you said, this isn't something that will change much, if at all. FDev would need to add/remove/relocate name override regions, and I don't think we've seen them do that before. In fact, I could probably store these details and never update it again, unless we hear of something missing. In which case, I can just manually run a script that loads from the spreadsheet. Heh, back to where I began. :D
 
Top Bottom