Forem: Justin

Satellite maths meets reality

Justin — Wed, 13 May 2026 23:39:32 +0000

This is an image a friend took of a Comet (C/2025 R3 PANSTARRS) that is visiting the night skies currently. It is a 30 second exposure and the Nikon camera had a bad internal clock so it was timestamped at an uncertain time. The exact spot was known.

The challenge: can we reconstruct the same image, with the stars in the same place, identify the exact time it was taken and will everything match up?

This sounds straight forward but when you consider the chain of maths and coordinate systems that has to work correctly, it still boggles my mind that it works.

First, the camera location, from GPS, has to be correct. The GPS location is a lat long, and altitude. But not on a perfect sphere, it is on an oblate spheroid. It is no good putting the camera at 6371000 meters from earth center!

Next, the satellites in the picture have been pinpointed at a random moment in time up to 24 hours before the picture was taken and during the intervening time they have orbited the earth dozens of times. They have to arrive on-time, moving in exactly the correct direction. The propagation is a chain of maths that takes into account orbital mechanics, drag, gravity influences and so on.

All the stars in the picture are in charts, but the universe view precesses (from our viewpoint) slightly over decades so the (fixed) catalog one uses has to be rotated from its start point. This is because the earth has a spin-tilt that changes slightly over time. (There are 1 and 2 orders of magnitude effects on star positions as well that are only taken into account in very high precision astronomy).

The camera has that takes the picture needs very finely engineered optics that introduce no significant distortion. In addition, it needs to be level, and for a long exposure, it needs to be mounted on an electronic device (equatorial mount) that slowly moves it over the shutter duration to track the rotation of the sky, otherwise there would be star-trails.

The simulation has to reproduce the patch of sky (since I care about satellites, not star density or nebulae, only a few key stars are showing) at the exact time, at the exact instant the shutter was pressed, and it has to also mimic the equatorial mount motion, the focal length of the camera and fov h and v. It has to position the satellites correctly and move them over the same period and accumulate the frames in a similar way to a digital camera. If the observer is at the wrong spot, any of the coordinate frame conversions are slightly wrong, if the sky data has not been precessed the right way or in the right magnitude, or if the satellite propagation is off, things will not look right. The trails won't match, or they will, but the stars won't match, or the time will be wrong.

It is a good way to discover small numerical problems not obvious in casual use. In essence, nature has provided us one image and the giant pile of maths has to arrive at the same image, by an entirely synthetic process. Natures pixels on one side, a sim on the other, they have to match.

Just for fun, the simulation also plate-matches any picture you are working to match. Plate matching a process of identifying the brightest stars, measuring their relationship in angles, then searching the star catalog to find the exact piece of the sky pictured, and reverse calculating out (given location and time) what angle the camera must have been at to get that shot. (Elevation and azimuth and also the roll of the camera).

The result:

The sim stars (skybox) matches
The trails match in location length and so on
The plate-solve calculates the correct camera position
The Nikon camera was 6 minutes(!) wrong with its internal clock
The Roll of the camera was 0.5 degrees

If you have a picture with satellite trails, you can play with matching it to actual satellites. You will need to know the location and approximate time it was taken. The rest you can figure out.

Satellite photo simulator page

The wacky 2026 world of bot traffic

Justin — Fri, 08 May 2026 01:15:26 +0000

Three strategies to deal with bot traffic.

Give up. Have at it. Take what you want. As fast as you want. On my dime. Steal it. re-use it. Life is too short.
Hide behind cloudflare. Let them try to deal with it. Have re-captchas annoy your users. Pay cloudflare and be up-sold.
Understand more about it and do what you can to make it harder. Rage into the dying of the light. Etc.

I completely understand option 1 and 2. Life is too short with other priorities to be in an un-winnable battle with bots that don't even know what robots.txt was supposed to be let alone read it let alone obey it.

However in the spirit of stupidly writing an entire webgl/webgpu website without touching Cesium or Threejs, I'd rather understand more about it.

So the other week I see in the logs that several entire net blocks from Alibaba data web hosting centers are essentially scraping the entire website all the leaf nodes in all the languages. Since there are 35,000 satellites and each page is in multiple languages, thats a lot of pages. They rotate user agents and use a vast number of IPs but they are easy to see, and block - just blank ban the entire netblocks involved. I've already got my web server set up so that from the CLI I can just type 'ban x.y.z/n' (or unban), and monitoring scripts to do this continually.

This quieted things for a few days. But then they came back. This time they came back from 35 THOUSAND ip addresses and each IP did one fetch, they used a relatively small set of rotating but legit user agents.

Investigating this pattern which seemed, on the face of it, to be impossible to block I can see all these residential IPs are using HTTP 1.1 protocol. This provides an option for detection. If you're using a modern browser AND HTTP 1.1, you're blocked. Because all modern browsers use HTTP 2.x. For bots, however, the picture is mixed. But legit bots have legit user-agents. (Note: I would not recommend you follow this life hack. Gemini can fill you in for all the reasons why it is a bad idea).

But the question is. Why? Why spend money crawling an entire tree of URLs via residential proxy IPs, when the information is ALL ephemeral. it would be like crawling an entire worldwide weather website. Absolutely no use at all.

The answer is possibly: AI training. Somewhere, someone, has decided they want an entire mirror of 10s of thousands of domains and do not care if the data is a maze of pointless twisty passages all alike, or the weather in Manitoba, or the stock price of google at this very instant in time. They just want it, and will disobey all the flimsy "laws" humans set up when they invented files like robots.txt.

So that's the landscape today. 75% or more of your traffic (in simple server logs) is fake. Even if it LOOKS real, it's probably fake. You're paying outbound bandwidth costs to feed AI training, SEO intelligence, competitive advantage keyword data-sets who knows what.

Of course google analytics would parse out all this because I doubt scrapers care to run the google fragments that record a "real user". (Baiduspider and others increasingly do execute all js now). But if you're paying for a CDN or paying for bandwidth by the terabyte, you're paying to feed bots anyway and they are way more voracious than they used to be.

An icon - the hardest work in software development now

Justin — Wed, 29 Apr 2026 00:48:48 +0000

1. Single source of truth
Design once:
Master: 1024×1024 (or SVG if vector)
Safe area: keep key content inside ~80% center (for masking/cropping)
Background: define both light and dark compatibility Everything else is derived from this.

2. Universal icon set (apps + web + installs)
Core exports
1024×1024 PNG (store listings, macOS, fallback)
512×512 PNG (PWA, Android)
192×192 PNG (PWA minimum)
180×180 PNG (iOS home screen)
32×32 PNG
16×16 PNG
SVG (where supported)

3. Favicon (browser identity)
favicon.ico (16, 32, 48 embedded)
favicon.svg (modern browsers)
favicon-32.png
favicon-16.png

4. PWA / install (manifest)
192×192
512×512
512×512 maskable
This is what Chrome/Android actually uses when “installing” your site.

5. iOS (still its own universe)
180×180 (apple-touch-icon.png) ← critical
(optional but safe)
167×167
152×152
iOS still ignores your manifest, so this is non-negotiable.
there are special html HEAD lines for IOS.

6. Desktop app surfaces (optional but real)
If your “product” becomes installable or wrapped:
256×256 PNG
512×512 PNG
.ico (Windows)
.icns (macOS)

7. Social sharing
These are just as important as icons now—they are your first impression.
Open Graph (general: Facebook, LinkedIn, Slack, etc.)
1200×630 PNG/JPG (canonical)
Aspect ratio: ~1.91:1
X (Twitter)
1200×600 (safe)
Or reuse 1200×630
Square fallback (some platforms crop aggressively)
1200×1200
Optional high-res / future-proof
2400×1260 (2× retina OG)

8. Xcode
oh god I've run out of energy

9. Android Studio
Please help me.

10. Caching.
Everything has its own idea about cache Persistence. Good luck working out if you're doing it right.

plushub.net vibe coded slop

Justin — Tue, 28 Apr 2026 22:34:51 +0000

I'm writing this post in case anyone else is searching for information about this website in their referrer logs that has zero contact details.

Someone vibe coded this rubbish and launched it without a care. The reason it hits up your log files as a referrer is that the bot that wrote the code thought it would be "cool" to show an "online/offline" feature for every single website listed on their re-skinned yahoo directory in purple and black.

As a result every poor visitor this hell-hole of a site fetches every URL listed continuously, in the background, IN FULL (not even /head) and there is nothing you can do about it to tell the bot and the human bot that launched it because there is no feedback form no contact us no discord no twitter no GitHub no anything. It just sits out there like a spider web trapping browsers into mass DDOS of every single URL mentioned in their (long) site list per category.

Ugh.

The tyranny of google page speed insights

Justin — Tue, 02 Sep 2025 00:54:22 +0000

"All good but why is the page speed insights score so low?"

The phrase that web developers just hate to hear.

The last week I have spent trying to find a balance between having a SPA (Single Page Application) that loads once and then can be used, with one that is also SEO and crawler friendly, has deep links, and also has good page speed insight scores.

Over a very short period I have had a fast re-introduction to the whole battleground of SEO vs Speed vs Functionality (it sounds like a pick two scenario).

History lesson

In the good old days of web development, php and modperl or static files we would shoot the web page from the server to the browser. Life was full of tables, and good. Sort of.

Then along came web development frameworks like React and about three dozen competitors. Suddenly it was all about hydration and shadow Dom and re-usable components. Recognisable html barely arrived at the browser any more. Instead whole chunks of JS arrived along with the "Flashes of Unstyled Content" (FOUC), and many other headaches.

But it also became about web crawlers failing to crawl your extremely js-heavy content. And it became about poor page speed ("lighthouse") scores too.

For a while google promoted a solution: renderbot! this product (basically chrome in a box) would sit on your server and render the complex pages, then deliver the final-final-really-final html to the dumb crawlers. This sounded good in practice if it could be just plugged in, but the devil was in the details. Now renderbot is render-not: deprecated by google and closed to new GitHub issues.

Solutions

A tempting solution is to just give up and build a static tree of URLs (html files) that can be crawled by all the spiders. Unsatisfying but still a solution many sites use because what else can they really do when crawlers are overloaded by the heavy task of piecing together a web page that displays a few H1 and H3 tags and a paragraph of keywords and about a million javascript instructions to get there?

Enter: server side rendering. Everything old is new again. Web-dev is back to building html complete web pages on the server and shipping them to the client where the glamorous parts start operating with sprinkles of late booted javascript.

But if you're NOT already invested in your main event being React, or Svelte5, or Vue, or NextJS or new sexy platform, then some kind of "enable SSR" (not that this is ever as easy as it sounds, anyway) switch is just not an option. What to do?

What I did

In the case of satellitemap.space the issue I faced is a satellite information website and tool needs an array of search engine friendly URLs that lead directly to satellites! and constellations! it is, after all, how many people might start with trying to get information. "where is the ISS?" "Where did that starlink satellite re-enter?"

I did have deep-links to satellites. But there was a problem. Page speed insights refused to believe the site was interactive until all the network traffic settled down. So it would give good usable URLs that opened the SPA in a certain mode, a failing grade. A deep link to the ISS would be interactive on my phone in a few seconds but google would score the URL as being a failure.

Worse, SEO-rich info related to a SPA deep-link should be mostly concentrated in the "HEAD" section of the page: the page TITLE, the meta tags, and so on. These parts appear first in the index.html that delivers the SPA, and while they can be re-written later, when the deep-link is inspected, dumb crawlers might fail to wait for that.

Enter Astro. Astro allowed me to build a page from any URL pattern, server-side, include complex js driven divs, but have a 90+ lighthouse score. I can still use tailwindcss. I can still can use any js modules or functions that the home page SPA already uses. So it was familiar. It did not require a re-think or much duplication of effort.

As a result of astro I can now add an entire satellite catalog over URLs like: https://satellitemap.space/sat/:norad_id with SEO rich headers and content, but it also loads blindingly fast from the perspective of google lighthouse:

Apart from being able to do API requests before emitting even a header line back to the browser, Astro also enables the trick of only hydrating the sections of page when they are visible, or first interacted with. In the case of the above-mentioned single satellite catalog page these were:

The Search function
The full monty webgl globe visuals plugin
The satellite description accordions
The Sky transit table
(and any others I want to add)

So now the complete pageload before any attempt to use search or scroll down to the globe plugin looks like:

that's it. vs any other typical modern website page, this is a lean. A web page with ozempic face.

Scrolling down the page causes the entire globe visualisation to boot up. (And that process was already a lot leaner than the Caesium globe library). So visually it only takes a second or two.

Pressing the Search icon causes the incremental search process to boot up.

None of these late hydrations are relevant to the page crawlers.

Another solution like Astro is Qwik - Qwik City. which is probably slightly faster still. But perfect is the enemy of good. The goal is not to go from 95 to 100 web page speed scores, It was just to not get failing web page speed scores.

Anyway. Astro rocks, I will use it next for constellation information leaf pages, and more.

Webgl shaders and POV Satellites

Justin — Sun, 24 Aug 2025 10:22:58 +0000

Today I spent time refining the POV view of the globe from a satellite. To be specific, the ISS. The basic view started like this:

Very boring. The globe at night! One can barely even discern the horizon. It is where the stars stop. That's it.

Adding an atmosphere shader got me a layer of gas. The atmosphere shader is a ray march with a simple rayleigh phase function:

As I mentioned in the last update, I'm still not happy with the atmosphere layer, but it at least reacts to the presence of sunlight, lighting up before dawn.

Switching on the "4k" globe texture instead of the dim "no distractions" texture, things are starting to look better:

But there is no cloud layer and the specular highlights on the ocean are unsatisfying. I had ocean specular highlighting on the globe when viewed from a distance so this confused me, where had it gone? tricks used at one distance rarely work well when the camera is close. So after playing around, I managed to recover the specular highlight:

So now we are starting to see something better. The sun bounces off the ocean. I can dial it up until it really glares. Sunrises and sunsets start to look better.

(Side note: webgl2 should actually support HDR. I've seen one (exactly one) good HDR particle demo that runs on chrome. HDR looks amazing when it works. Since HDR seems half baked in browsers, I put it into the too-hard basket for now. Even caniuse does not know what you mean when you say "caniuse HDR webgl". Despite being an idea since 2021, adoption is glacial. A recent discussion is here: https://discourse.threejs.org/t/true-hdr-color-support/78370 )

Turning on the cloud layer now. Most critically, making sure cloud shadows are working wrt. the sun gave more of a 3d effect. This the final result:

Sometimes it looks pretty good in motion with the bright sun glare effects off snow and some lighter coastal waters and cloud drop shadows.

To get anything close to correct physical rendering is a deep rabbit hole especially when it also has to work at different camera distances. I should stop.

A real ISS picture of the horizon is so much better. Looking at reality vs the sim again perhaps the specular glint color should be more gold and less blue? Ok maybe I can play with it a bit more...

Feature update.. POV mode

Justin — Sat, 23 Aug 2025 03:09:23 +0000

If you own an Apple TV you'd know they like to show screen savers of drone shots and what looks like a 4k video from the ISS showing the globe and horizon so today I added POV mode for any satellite.

This as usual proved to be more challenging than expected. Just stick the camera on the satellite, right? how hard could that be.

Firstly, the camera has to face in some direction. At first I figured facing it in the direction of travel would be sensible but this turned out to be confusing for geo-synchronous satellites whose direction of travel in earth fixed frame is not really travel at all. So for "slow" satellites, the better default camera was looking towards earth.

After implementing a pan/tilt of the pretend camera, I then struck 3d math issues. What is "up" in space even anyway? On a LEO satellite, up can be the vector from origin of earth to satellite, this is roughly orthogonal to direction of motion but on geo satellites that causes a maths collapse as "up" being too close to same as "where I am looking" doesn't work too well.

Another problem was that the spherical earth is not tessellated well for a lovely horizon view, it looked like a geodesic dome! so this required switching to high tessellation when switching into POV mode.

The next challenge was accelerated time travel reveals the approximations between satellite fixes made the camera jump at every new exact fix. So I had to re-calculate (just for the POV satellite) on every frame, the full SGP4.

As it stands the new feature is getting there. Pan/tilt works. No zoom yet. The earth looks good below in "4k" globe mode. No atmosphere. The sun and moon are impossibly small. That needs to be fixed. In fact the whole sun/moon thing (apparent size in all modes) needs re-doing, really. No mobile touch controls for the pretend webcam, yet.

The sim also showed the moon almost on top of the sun for my location (and is almost completely un-lit) and I thought that was a bug but it turns out from here at least, the moon is, in fact, almost eclipsing the sun. A few degrees away in altitude and azimuth.

You can get into POV mode from the last Actions button of a satellite info panel:

Well, happy with this new mode. A lot of things still to touch up however. No good feature goes unpunished!

Feature update

Justin — Wed, 20 Aug 2025 03:08:45 +0000

A few things have been added in the last couple of days I should probably explain them here as a way to get used to dev.to posting.

Selection of satellites

With 8000 something starlink satellites in the visualiser (or many more if all satellites are loaded) it became quite frustrating to select and unselect individual ones by point and click or touch. To make this easer there is now a widget that keeps the recent selections in a stack. This widget allows

clicking the item to zoom the camera to it
clicking the information symbol to open the larger panel of detail that USED to open
clicking the x to un-select that satellite
clicking to unselect all of them. Oh also you can move that little widget around using the grab handle in the left corner:

Copy/pasting TLEs

I get good suggestions via Feedback but if you don't leave your email I can't say it's implemented. From the satellite information panel you can now click the button to copy the TLE into your clipboard

Faster on slow connections

Using the network test tab of chrome with "simulate slow connection" it became clear that some textures were making the boot-up pretty unbearable in that scenario (for example, mobile + 3g). Worse, the largest textures are optional: for example, the background universe texture, or the detailed country borders. Now these textures are not loaded if the connection is detected to be slow. The time to load with no constellation selected is dramatically faster and even though loading "all of starlink" involves quite a bit of data, it is now bearable. Since this website is a SPA (single page app), the loading is one time. There is more work I need to do in this area.

Deep linking

I'm trying to build out the deep linking in order to go straight to a feature. For example:

https://satellitemap.space/constellation/kuiper
https://satellitemap.space/altitude-history?norad=25544 There might still be bugs with deep links and/or the browser back button.

Some random new-ish features:

Altitude history

After loading a constellation, you can go to Functions .. Timeline and this shows some tabs including growth (the default), launches and so on. In the Launches tab, the groups of satellites are now clickable :

and this goes straight to the altitude-history URL which ...

... plots their mean altitude all on a little graph.

Constellation altitude slots

Another interesting tab displays how the satellites in a constellation are grouped by altitude, with this year being compared to previous years.

You can see the bump at 360km for the 'direct to caller' starlink hardware in 2025 that was not there a year ago.

Re-entry view

This is an old feature but had bugs, now it doesn't have bugs. This screenshot shows the "exploded" view of the starlink constellation (the button with the blue box with exploding sides has been pressed) plus the "Re-entry risk" filter with everything de-selected except <180km. If you look carefully to the middle right of the globe you can see two red starlink satellites that are about to meet a fiery end.

satellitemap.space

Justin — Wed, 20 Aug 2025 02:41:55 +0000

I decided to start this dev.to account to document changes made to https://satellitemap.space over time. I'll find a good place to link to it from the site itself.

The audience is me for a dev diary. Plus, anyone that uses the site and is for some strange reason interested in a more detailed description of ongoing progress & features (with maybe some nuts and bolts dev chat). So this is it. The first post.