Geometry Is a Work Order

Geometry is more than a map layer

Outside plant software loves maps because fiber work is visibly spatial. A cable has a route. A pole has a location. A splice closure sits somewhere. A service address either is or is not inside a marketable area. The temptation is to treat the map as the product: get something onto a basemap, make it clickable, and let the rest of the workflow happen in forms, screenshots, PDFs, and human memory.

That is too small. Geometry is not only how the work looks. Geometry is part of what the work means.

The Osprey ECO workflow already hints at this. The initial investigation task is a point: an incident location that says, “start here.” If the technician discovers follow-on work, the geometry can change shape. A cable run or conduit repair is a LineString. A pole, terminal, or equipment repair is a point. Those are not cosmetic choices. They are different work contracts.

A point gives dispatch a target. A line gives a crew a path. A polygon gives a reviewer a bounded area. A closure point with connectivity metadata gives the NOC a place where service paths can change. A route segment with evidence gives engineering a candidate as-built fact. The same coordinate system is underneath, but the operational meaning is different.

This is the missing middle between The As-Built Is the Network Model and The Splice Is the Network’s Truth Table. The as-built article argues that closeout records should become operating data. The splice article argues that connectivity deserves first-class modeling. This cairn focuses on the spatial contract that sits underneath both: the shape of the work itself.

The shape chooses the question

Every geometry type answers a different question. A point answers, “where is the thing or observation?” A line answers, “along what path does the work, route, or impact extend?” A polygon answers, “inside what boundary does this claim apply?” A multi-geometry answers, “which set of places belongs to the same logical record?” A geometry collection says, “this thing is spatially composite enough that the pieces should travel together.”

That vocabulary is familiar to GIS systems, but product teams often flatten it. They store one geometry column, accept whatever the frontend draws, and let context live in a nearby task type or description. That works until the same drawing surface starts serving several workflows: dispatch, permit review, closeout, damage assessment, serviceability, grant reporting, outage triage, and network design.

The geometry then needs a role.

The same visible shape can appear in more than one row of that table. A LineString might be a proposed design route, an assigned repair segment, a redlined as-built segment, a suspected outage span, or the footprint of an OTDR event interpretation. Those are not interchangeable just because they render with the same SVG path.

A geometry role is different from an asset type. “Aerial fiber” describes what the thing is. “Repair task geometry” describes how the workflow is using that shape right now.

The rule is practical: choose the shape that matches the question. If the user is creating an investigation, a point may be enough. If the user is assigning underground conduit work, a point is probably dishonest because the work exists along a path. If the user is validating serviceability, a single point at the center of a neighborhood is weaker than a polygon or a set of address-level points because it hides the boundary of the claim.

ECO geometry should evolve with certainty

An emergency callout starts with uncertainty. The NOC sees an alarm, a customer report, a cut ticket, a field note, or some other signal. The first location may be the affected customer, the nearest known asset, the last known splice point, the midpoint of a suspected span, or simply the place where a person should begin investigating. That is useful. It is not the same as the final repair geometry.

The Osprey workflow captures this distinction in its stages. ECO creation starts with an investigation task at an incident point. The field technician investigates, then clones or creates follow-on tasks under the same subsector. Those follow-on tasks can carry more specific geometry: a LineString for a cable run or conduit segment, a point for a pole or equipment repair. Completion rolls up through the shared ECO container.

That pattern matters because it avoids a common data mistake: overwriting uncertainty with later certainty and losing the path between them. If the incident point is replaced by the final repair segment, the NOC loses the original triage clue. If the repair segment is stored only as a note on the investigation point, engineering loses the as-built candidate. If the evidence footprint is collapsed into the task geometry, audit loses the difference between where work happened and where proof was collected.

flowchart TD
  A[Incident signal] --> B[Investigation point]
  B --> C[Field investigation]
  C --> D{Follow-on work?}
  D -->|Discrete repair| E[Repair point]
  D -->|Linear repair| F[Repair LineString]
  D -->|Area review| G[Review polygon]
  E --> H[Evidence and completion]
  F --> H
  G --> H
  H --> I[Accepted operating projection]

The workflow should allow confidence to increase without erasing history. A simple confidence scale can be enough at first: reported, inferred, assigned, field-verified, accepted. A reported geometry tells dispatch where to begin. An assigned geometry tells a crew where to work. A field-verified geometry tells reviewers what the technician observed. An accepted geometry tells downstream systems what the operator is willing to rely on.

Spatial standards are necessary but not enough

The good news is that the geometry primitives are not exotic. PostGIS implements the OGC geometry model in PostgreSQL. OGC Simple Feature Access gives the common conceptual vocabulary. GeoJSON gives web clients and APIs a familiar exchange format built around geometries, features, and feature collections. The industry already has stable words for points, lines, polygons, multi-geometries, spatial reference systems, and spatial operations.

Those standards solve a real problem. They let us store, index, validate, transform, and exchange shapes without inventing our own coordinate math. They let a backend ask whether a task is near an asset, whether a route intersects a boundary, whether a closure lies on a segment, or whether a field point falls inside a service area. They let a frontend render work without needing a bespoke geometry language.

But standards do not decide product semantics. A valid GeoJSON LineString can be a design route, an actual route, a proposed repair, a technician path, an outage hypothesis, or a measurement interval. PostGIS can tell whether it intersects another geometry. It cannot tell whether that intersection means “dispatch this crew,” “block this permit,” “update this as-built,” or “notify this customer.”

That decision belongs to the application model.

Spatial reference systems matter because coordinates are not self-explaining. The same numeric pair can mean different real-world locations under different coordinate systems. Most web maps standardize enough of this away for display, but storage and analysis still needs explicit discipline.

For OSP work, the model should make at least four things explicit: the geometry itself, the geometry role, the source of the geometry, and the lifecycle state of the claim. Without those, the database can become a spatial junk drawer. Everything is queryable, but little is reliable.

A field task is a spatial contract

A task geometry should constrain completion. This is where geometry stops being a map feature and becomes a workflow rule. If a field technician is assigned to replace a damaged pole, the system should expect point evidence: photos at the pole, a form tied to that asset or location, and any resulting change to the equipment record. If the task is underground conduit work, the system should expect segment evidence: start and end, route deviation, depth or restoration notes when required, and photos or forms distributed along the work.

The Osprey ECO workflow already says completion is not merely a status toggle. Field technicians complete required form fields, upload required photos, and submit the task. Geometry can make those requirements sharper. It lets the system ask whether the proof matches the work.

This matters for the false-complete problem. A status can say “done” while the spatial evidence says “not enough.” A task may be complete in a field tool, but the operator may still need a grace period before treating the ECO as hard complete. Geometry gives that grace period something concrete to inspect.

This does not require a heavyweight GIS implementation on day one. A first version can be modest: validate that point tasks have point evidence, line tasks have segment evidence, and area reviews preserve the reviewed boundary. The important shift is conceptual. The shape is not an optional annotation after the task is done. It is part of the task contract.

The projection is where geometry becomes useful

Raw spatial data rarely serves one audience. The NOC wants a current operational view: what is open, where crews are working, which customers or spans might be affected, and which ECOs are at risk of false completion. The OSP supervisor wants an assignment view: what can be released, where crews should go, and what evidence is required. Engineering wants a design-versus-built view. Analytics wants clusters, cycle times, repeated trouble spots, and capacity signals.

Those readers should not all consume the same undifferentiated table. They need projections.

In Osprey-shaped systems, this fits the existing event and projection mindset. Field events, task updates, geometry changes, evidence uploads, and review decisions form a history. Read models turn that history into current views. One projection can power the NOC dashboard. Another can power closeout review. Another can feed the as-built model once a claim is accepted.

flowchart LR
  A[Task and field events] --> B[Geometry claims]
  B --> C[Operational projection]
  B --> D[Closeout review projection]
  B --> E[As-built candidate projection]
  C --> F[NOC dashboard]
  D --> G[Reviewer workflow]
  E --> H[Network model]

The projection has to preserve meaning. A NOC map can show both incident points and repair LineStrings, but it should label them differently. A closeout view can show evidence footprints and accepted asset geometry, but it should not imply that a technician photo proves every foot of a segment unless the workflow actually collected that evidence. An analytics view can aggregate by area, but it should remember whether the source data was point-based, segment-based, or polygon-based.

This is where geospatial tooling and product design meet. PostGIS can answer spatial questions quickly. The application decides which questions are allowed, which states are visible, and which claims are strong enough to promote.

What to model first

The first useful model does not need every telecom GIS feature. It needs enough structure to keep intent, evidence, and lifecycle from collapsing into a generic map blob.

Start with these fields or concepts:

That model creates room for growth. It can later connect to closure-level connectivity, OTDR traces, serviceability polygons, construction packages, and formal utility network models. More importantly, it prevents an early system from lying by omission. A line that is only assigned work does not masquerade as accepted plant. A point that came from a customer call does not masquerade as verified damage. A polygon used for planning does not silently become a regulatory claim.

This is also a good place to be conservative with automation. Spatial inference can be useful, especially when relating incidents to nearby assets or summarizing work by region. But inferred geometry should remain visibly inferred until a human workflow or trusted source promotes it. The map should be allowed to help; it should not quietly launder guesses into facts.

What the team should take away

Geometry is one of the earliest decisions that shapes an OSP product’s truth model. If every workflow receives a generic pin, the system will eventually need side channels to explain what the pin meant. If geometry is typed by operational intent, the system can start answering better questions immediately.

1. Geometry is operational data. Points, lines, and polygons are not just display primitives. They describe how work should be dispatched, proven, reviewed, and promoted.
2. Shape and role are separate. A LineString can represent proposed design, assigned repair, accepted plant, or evidence footprint. The model has to say which one.
3. ECO geometry should evolve without erasing uncertainty. Preserve incident locations, follow-on task geometry, evidence footprints, and accepted records as related claims.
4. Spatial standards provide the grammar, not the product semantics. PostGIS, OGC, and GeoJSON help store and exchange geometry. Osprey still has to decide what each geometry means.
5. Completion should be spatially aware. The task shape should help define the evidence required before a status becomes trustworthy.
6. Projections make geometry usable. NOC, OSP, engineering, closeout, and analytics views need different spatial projections from the same underlying history.

The practical bar is simple. When we draw a shape, we should be able to answer: what job does this geometry do, who can rely on it, what evidence supports it, and what event would change it? If those answers are missing, the map is still useful context, but it is not yet an operating record.

Discussion prompts

• For ECOs, which geometry roles do we need first: incident location, assigned repair geometry, evidence footprint, accepted as-built candidate, or affected-service area?
• Where should confidence change in the workflow? For example, what exactly promotes a geometry from reported to field-verified, and from field-verified to accepted?
• Which projection should consume task geometry first: NOC visibility, OSP dispatch, closeout review, or the longer-lived network model?

References

1. PostGIS: Data Management - PostGIS implements the OGC geometry model in PostgreSQL and documents the core geometry subtypes used throughout spatial applications.
2. OGC Simple Feature Access - The standards family behind simple feature geometry, including the base geometry model and its common subclasses.
3. RFC 7946: The GeoJSON Format - The web exchange format most teams encounter when passing points, lines, polygons, features, and feature collections between APIs and clients.
4. ArcGIS Pro: Telecom Domain Networks - A useful signal that telecom GIS tooling is moving toward domain-specific network models rather than generic map layers alone.
5. The As-Built Is the Network Model - The companion cairn on promoting closeout records into operational network truth.
6. The Splice Is the Network's Truth Table - The companion cairn on why connectivity inside closures needs first-class modeling beyond spatial placement.