From Weather Data to Mission Context

From Weather Data to Mission Context: Why I Built PIC Weather Ops

How a mobile decision-support app for drone pilots is evolving into a broader web-based operational workspace.

A first-person account of why PIC Weather Ops was created, what the mobile and web products do today, and the operational principles guiding the next stage of development.

Figure 1. The mobile workflow brings Mission Briefing, terrain assessment and fire context into one mission-centered experience on iPhone and iPad.

The operational question behind the product

Drone pilots do not lack weather data. The harder problem is connecting that data to a specific operation.

Before a flight, an operator may need to check wind, gusts, visibility, precipitation, official alerts, daylight, terrain and nearby fire activity. The information exists, but it is often distributed across several apps, websites and map layers. Each source may be useful on its own, yet the pilot still has to build the operational picture manually.

The question that led me to create PIC Weather Ops was therefore not simply, “What is the weather?” It was: “What do these conditions mean for this mission, at this location, during this time window and along this planned route?”

PIC Weather Ops grew from that question. The goal was never to replace official weather sources, aviation procedures or the judgment of the Remote Pilot in Command. The goal was to organize relevant information around the mission so that important conditions, limitations and data gaps are easier to see before launch.

Starting with the pilot and the mobile workflow

The first practical layer was the mobile application for iPhone and iPad. I wanted a pilot to be able to define a Mission Point, review current conditions or a planned mission window, and move through the same core workflow without jumping between unrelated tools.

The app brings together wind and gusts, visibility, rain probability, temperature, daylight, official alerts, available cloud-base information, terrain assessment and fire-related environmental context. These are not presented as a generic weather dashboard. They are organized around a planned drone operation.

The Mission Briefing section became one of the core parts of the product. It turns a collection of readings into a structured preflight record: the mission reference point, selected time window, the main weather drivers, terrain status, environmental context, data freshness and any information that is unavailable or still requires review.

Making missing information visible was an important design decision. In an operational tool, an explicit “Unavailable” is often safer and more useful than a silent assumption. The application is designed to support the pilot’s review, not to present false certainty.

Terrain changed the scope of the project

Terrain was the feature that changed how I thought about PIC Weather Ops. A mission can have acceptable weather and still contain a route-level problem.

The terrain workflow allows the operator to compare a planned path and altitude with the underlying elevation profile. When the planned path intersects the terrain model, the system can identify the first intersection and show the minimum calculated clearance. In the web workspace, the same assessment can be viewed in both 2D and 3D.

This is still decision support. A terrain model does not account for every tree, wire, structure, temporary obstacle, positioning error or local operational factor. The value is in identifying a potential conflict early and making the limitation of the analysis clear enough that the RPIC knows what still has to be verified.

Figure 2. A 3D terrain-route assessment identifies the first terrain intersection and shows the planned path against the elevation profile.

Fire and environmental context: signal is not confirmation

Adding fire context introduced another principle that now influences the wider platform: a signal is not the same as a confirmed event.

Satellite thermal-detection data can be operationally valuable, especially for public-safety, inspection and environmental missions. However, a thermal anomaly should not automatically be described as a confirmed wildfire. It may be delayed, incomplete or associated with another heat source.

PIC Weather Ops therefore treats fire information as context that the operator can review alongside the mission point, weather, wind and route. The interface emphasizes observation time, source and proximity rather than presenting a satellite record as unquestionable ground truth.

That distinction – source signal, operational interpretation and field confirmation – has become one of the most important lessons in the development of the product.

From an individual pilot tool to a shared web workspace

The mobile app naturally centers on the individual pilot. The web platform is expanding the same idea toward a broader operational view for teams and decision-makers.

The current web evaluation workspace already combines a map-based mission environment with Mission Point selection, mission windows, route geometry, waypoints, terrain targets, 2D and 3D terrain views, wind context, fire signals, scenario saving, mission-readiness checks and generation of a structured Mission Brief.

This changes the center of gravity. Instead of asking only what one pilot needs to see on a phone, the web version asks what the operation needs to see in one place. The route, environmental context and readiness state become part of a shared picture that can be reviewed before a brief is completed.

The web platform is currently being developed and evaluated through controlled access and non-sensitive test scenarios. It is not presented as a certified aviation weather service or as an organization’s system of record. Those boundaries are intentional.

Figure 3. The web evaluation workspace combines mission location, route geometry, terrain status, environmental context and briefing readiness in a shared operational view.

What the development process has taught me

Building PIC Weather Ops has reinforced several practical lessons.

First, more data does not automatically create better situational awareness. Data becomes useful when it is connected to the mission and presented with enough context to support a decision.

Second, freshness and provenance matter. Operators should be able to understand where information came from, when it was observed or generated, and whether it may need to be checked again before flight.

Third, uncertainty should be visible. Missing cloud-base information, an incomplete terrain assessment or an old environmental observation should not disappear behind a polished interface.

Fourth, automation should assist the operator rather than quietly replace the operator. The responsible pilot or decision-maker must remain in control of the final operational judgment.

Finally, development benefits from real operational feedback. A feature may work technically and still fail to match how pilots prepare, communicate or document a mission. That is why feedback from working drone professionals is becoming an increasingly important part of the evaluation process.

Where the platform is heading

The long-term direction is a mission-centered operational workspace rather than a collection of disconnected map layers.

At a high level, that means continuing to connect planning, environmental context, terrain, mission status and evidence from the field. Future evaluation work will examine richer operational data, better continuity between preflight planning and mission execution, and selected live or near-live information from compatible systems.

I am also exploring how the same mission model could support specialized environmental and incident-response use cases. These capabilities are being developed incrementally: first validate the operational need, then test the workflow with appropriate users, and only after that expand the platform.

The central principle remains unchanged: software can organize evidence, highlight conflicts and support the workflow, but the human operator retains authority over the mission.

An invitation to evaluate the web version

PIC Weather Ops is available on the App Store for iPhone and iPad.

The web platform is also available for limited evaluation by selected drone professionals, operators and organizations using non-sensitive scenarios. I am particularly interested in feedback about what teams need before, during and after a mission – and which information genuinely improves the operational picture rather than simply adding another layer.

Professionals interested in reviewing the web version or discussing an operational use case can contact me directly through LinkedIn or at tech@sightnav.com

PIC Weather Ops began as an attempt to make preflight weather review more mission-specific. It is now evolving into a broader effort to connect conditions, route, terrain, environmental context and briefing inside one operational workflow.