Why Is Weather Radar Centered on the Radar Station Instead of You?
Open a weather radar map and there is a good chance the map is not really organized around you.
It may show your city. It may place a dot somewhere near your location. It may even know your exact coordinates.
But the underlying view often belongs to something else.
A radar station.
A predefined tile.
A regional coverage area.
A national weather service.
A map projection chosen for the convenience of the data provider rather than the person checking whether rain is about to hit the backyard.
We rarely notice this because software is very good at disguising infrastructure.
The map looks polished. The colors move. Roads and state lines provide orientation. Your location may be marked somewhere inside the frame.
So the arrangement feels natural.
But there is nothing inherently natural about making people locate themselves inside somebody else's coordinate system.
The latest version of Ovrvue rebuilt its radar around a different assumption. Its default radar view is centered on the user's actual coordinates, wherever those coordinates happen to be. The map is drawn around the pin rather than around a weather station. RainViewer supplies the precipitation imagery, while Ovrvue renders its own coastlines, lakes and major rivers from a static Natural Earth geometry file. In the United States, the higher-resolution NWS station radar remains available as an optional second source.
It is easy to describe this as a radar improvement.
The more interesting question is why so much software makes users adapt themselves to the shape of its infrastructure in the first place.
Interfaces Often Reveal Where the Data Came From
Every information system has a native shape.
Databases have tables.
Sensors have coverage zones.
APIs have objects and fields.
Organizations have departments.
Maps have projections.
Weather radar has stations.
When software is first built, the fastest path is often to expose that shape directly.
If a weather service provides a radar image centered on a station, display the station image.
If a business system stores data by department, organize the application by department.
If an analytics service returns metrics in ten fixed categories, build ten cards.
If a file system is arranged in folders, make people navigate folders.
This is understandable engineering.
The upstream structure already exists. It is reliable. It has names. It has boundaries. Building the interface around those boundaries reduces transformation.
But a provider's natural organization is not necessarily a user's natural organization.
That difference is easy to miss because users eventually learn the software.
They learn which station covers them.
They learn which department owns the form.
They learn which dashboard contains the number.
They learn which menu has the setting.
After enough repetition, infrastructure starts to feel like reality.
It is not.
It is merely one way the system happened to be built.
Radar Stations Solve a Meteorological Problem, Not a Human One
Weather radar stations exist for good reasons.
They are physical instruments with real positions, ranges and limitations. In the United States, the National Weather Service assigns radar coverage with awareness of terrain, blockage and other factors that make simple nearest-station logic inadequate. Ovrvue's PDD specifically notes that this is why it relies on NWS station assignment rather than calculating the closest station itself.
The resulting radar data can be excellent.
Ovrvue's document describes NWS RIDGE-II as genuinely better than the global composite in important respects: native single-station base reflectivity, higher resolution and a longer animation sequence.
But the station is the center because the station produced the view.
That makes sense from the instrument's perspective.
It is less obvious from yours.
You do not usually open radar because you are curious about the geometry of a radar installation.
You want to know:
Is that rain coming toward me?
How far away is it?
Will it cross where I am?
Is the storm north of me or directly west?
Those are egocentric questions in the literal sense.
The useful coordinate system begins with the person asking.
“Where Am I in This?” Is an Interface Tax
Every time an interface presents information in somebody else's frame of reference, the user has to translate.
On radar, the translation is spatial.
Find the city.
Find the road.
Find the county line.
Estimate your position.
Now find the rain.
Now compare the two.
Only then answer the actual question.
For a familiar area, this translation can happen almost unconsciously. You know roughly where your home sits relative to the lake, highway or city label.
For an unfamiliar place, the tax becomes obvious.
You are traveling. You search a town. The radar opens around a station whose geography means nothing to you. You can see precipitation, but first you have to solve a miniature map-reading problem before the weather becomes useful.
Ovrvue's latest radar design removes part of that work by putting a crosshair at the forecast coordinates and centering the canvas around them.
The user no longer has to answer “where am I?”
The interface starts there.
That changes what the map is for.
It stops being primarily a picture of radar coverage and becomes a picture of weather relative to a point of concern.
Ovrvue Had to Stop Treating the Station as the Product
The rebuild required more than moving a marker.
The old radar model depended on NWS RIDGE-II station imagery. That architecture naturally made radar a U.S.-specific feature and tied the viewing experience to station-centered output.
The new model uses RainViewer as the global default because it can provide radar tiles centered on arbitrary coordinates. According to the PDD, that single capability was decisive: it made a pin-centered view possible without constructing an aggregator across individual national weather services such as DWD, the Met Office, BOM or ECCC.
That is an important architectural choice.
Ovrvue did not merely ask, “Which radar source is best?”
It asked, “Which data source allows the interface to organize itself around the user's location?”
Those questions can produce different answers.
The NWS feed may offer superior detail in its territory.
RainViewer offers a more useful integration shape for the global default.
So Ovrvue keeps both.
The global, coordinate-centered view is the default everywhere radar coverage exists. Inside the United States, a Local · NWS toggle appears when an NWS station resolves, allowing the user to switch to the higher-resolution station product. Outside that context, the toggle does not appear at all.
The app is not pretending the infrastructure disappeared.
It simply stops making the infrastructure the first thing the user has to understand.
Better Software Often Requires Translating the Source
This is one of the less glamorous forms of product work.
A data source gives you information in one structure.
The user needs it in another.
Something has to translate.
The easiest products often make the user do the translation.
The harder products absorb it.
Ovrvue's radar now performs several of these translations itself. It stores the user's current radar latitude and longitude independently of the station code because the global renderer needs the coordinates themselves. It fetches static Natural Earth geometry and draws coastlines, lakes and major rivers locally rather than depending on a conventional map tile service. It obtains recent RainViewer frames and places them into a view whose center is determined by the forecast location.
This creates more implementation work.
But it reduces conceptual work for the person looking at the map.
That tradeoff appears throughout good interface design.
A scheduling product can show timestamps in the viewer's timezone instead of the server's timezone.
A finance application can translate database transactions into categories people actually budget with.
A medical portal can organize test results around the patient rather than the lab's internal department codes.
A logistics interface can say “arriving at your address” instead of exposing the route's sorting-hub hierarchy.
In each case, the software is doing more so the person can do less.
Centering Is Not Just a Map Decision
There is a broader design metaphor hiding here.
What does the software consider the center?
Many products say they are user-centered while keeping the underlying organization stubbornly system-centered.
A CRM is centered on records.
An enterprise platform is centered on workflows.
A cloud console is centered on resources.
A healthcare system may be centered on institutions.
A government service may be centered on agencies.
Users appear inside those structures as entities that must be routed correctly.
Sometimes this is unavoidable. Complex systems need internal organization.
The mistake is assuming the internal organization should also determine the external experience.
Radar provides a wonderfully literal example.
The physical radar station really is the center of the measurement system.
It does not follow that it should be the center of the user's map.
These are two different centers serving two different purposes.
Software becomes easier when it recognizes the difference.
The Best Source Is Not Always the Best Default
Another useful lesson from Ovrvue's radar design is that technical superiority and product superiority are not identical.
The PDD is quite candid that NWS RIDGE-II is, in meaningful ways, the better radar data product within its coverage area. It has native station resolution and a richer local loop.
Yet Ovrvue demotes it from default to opt-in.
Why?
Because quality has more than one dimension.
Resolution matters.
Coverage matters.
Geographic context matters.
Consistency matters.
The ability to center the image on an arbitrary location matters.
A technically richer source can create a less coherent primary experience if its structure forces the interface into the wrong frame.
This is common in software.
The most detailed dataset may not be the easiest to interpret.
The most powerful API may not be the one with the right abstraction.
The most flexible configuration may not be the best default.
The challenge is deciding what should lead and what should remain available for users who want more precision.
Ovrvue's answer is progressive: the coordinate-centered global view first, the NWS station view where it adds value.
Capability remains.
Hierarchy changes.
Geography Had to Become Part of the App
Once Ovrvue stopped relying on the station radar image as the entire map, it inherited a new problem.
Radar pixels alone are difficult to interpret.
You need geography beneath them.
A conventional answer would be to use a map tile provider.
Instead, Ovrvue uses Natural Earth geometry baked into a static geo.json file at build time. The PDD says this file contains coastlines, lakes and major rivers, is precached by the service worker and has no ongoing freshness requirement.
That choice fits the larger architecture.
Ovrvue is a static web app with no backend and few dependencies. Using static public-domain geometry gives the radar enough geographic structure to orient the user without creating another live service dependency every time the map opens.
It is a useful reminder that removing one inherited constraint often means accepting another responsibility.
If the upstream radar image no longer supplies the whole frame, the application has to build the frame.
User-centered design is frequently more work precisely because infrastructure-centered design already comes assembled.
A Pin Can Be More Important Than a Boundary
Maps encourage us to think in regions.
States.
Counties.
Cities.
Forecast zones.
Radar coverage areas.
But weather does not experience those boundaries in the way software does.
Rain does not stop at a county line.
Wind does not care which city a user searched.
A storm crossing a regional boundary remains the same storm.
For many immediate weather decisions, the most relevant geographic object is not a jurisdiction.
It is a point.
Here.
Ovrvue already reflects this in its broader location model. Searching another city does not rewrite the user's saved pin. Following the current GPS position does not automatically replace that saved location. The radar similarly reads coordinates rather than relying on a location mode abstraction.
These distinctions protect a basic idea:
the place being displayed and the system's administrative concept of that place are not the same thing.
That matters particularly when users travel.
A person can inspect another location without changing home.
They can follow their current position without losing a saved location.
And radar can center itself exactly where the forecast is being requested rather than around whatever station happens to serve the area.
Infrastructure Should Be Visible When It Helps
None of this means infrastructure should always disappear.
Sometimes knowing the source is useful.
Ovrvue keeps NWS radar available specifically because the station product has advantages. The source toggle communicates that there are two different radar representations rather than silently replacing one with another.
The distinction is not “hide infrastructure.”
It is “do not make infrastructure the user's problem unless understanding it adds value.”
That is a more useful design rule.
The user does not need to think about radar-station assignment merely to orient themselves.
They may want to know that a higher-resolution local station source exists.
Those are different levels of relevance.
Good software exposes the second without requiring the first.
Maybe the Map Should Begin With the Question
There are countless ways to draw the same information.
A weather radar can begin with a station.
A region.
A tile.
A country.
A city.
Or a person standing at one coordinate wondering whether the green patch to the west will arrive before dinner.
The first four are natural to systems.
The last one is natural to the question.
That distinction reaches far beyond maps.
Software constantly asks users to step into structures created for databases, organizations, networks and machines.
Sometimes those structures genuinely matter.
Often they are merely inherited.
Ovrvue's radar rebuild is a relatively small example of what happens when a product challenges one of those inheritances.
The weather station still exists.
The data provider still exists.
The radar infrastructure still has its own geometry.
But none of those things has to be the center of the interface.
The map can start somewhere else.
With you.
Ovrvue.app is a personal weather app built around actionable conditions and progressive disclosure. Its global radar centers the view on the forecast location itself, with optional higher-resolution NWS radar available where supported.
Learn more: https://ovrvue.app