Summary

Geo scoring turns parcel evidence into an operational opportunity surface. The methodology is not simple radius search. It combines H3 aggregation, smoothing, road-network drive time, accessibility features, score families, and map-layer publication so operators can compare places by reachable opportunity.

Reader Question

How does LKCI turn parcel facts, H3 cells, drive-time reachability, and score families into a map surface that can be inspected, explained, and reused?

Methodology

The method starts with parcel features. Canonical parcel rows are normalized into observable facts: property type, age, ownership and classification signals, and location. Those features aggregate into H3 cells so the map can reason about neighborhoods instead of isolated parcels.

H3 aggregation is then contextualized. Smoothing and feature services derive nearby context so one sparse cell does not dominate interpretation. Routing services build sparse origin-destination matrices from the road network, then accessibility jobs ask which opportunity is reachable within configured drive time constraints.

Scoring combines observed features, smoothed context, and reachable opportunity into score families. Jobs publish scores and map layers; the geo console reads prepared layers instead of recomputing routing or scoring inline.

Boundaries

libs/geo/h3, libs/geo/routing, and libs/geo/scoring define reusable calculation contracts. services/geo/features and services/geo/routing own capability logic. jobs/geo owns rebuildable compute entrypoints. The UI owns inspection, not methodology.

Tradeoffs

Drive-time scoring costs more than geometric distance, but it is closer to how operations actually evaluate serviceability. The price is a stronger batch compute boundary and a need for explicit freshness and map-layer publication.

Why H3 Instead Of Only Parcels

Parcel-level facts are essential, but they are often too noisy for strategic inspection by themselves. A single parcel may be misclassified, stale, duplicated, or simply less important than the surrounding pattern. H3 gives the platform a stable spatial index for aggregating evidence into comparable cells. That lets the map show neighborhoods, corridors, and service-area pockets instead of only individual points.

The point is not to hide parcels. The point is to make them inspectable at the right scale. An operator can start with an H3 cell or score layer, then drill back into the parcel and candidate context that produced it. This preserves source evidence while giving the surface a usable geography. It also lets jobs rebuild features consistently when source data changes.

H3 also gives the platform a common shape for multiple feature families. Residential density, commercial/industrial signals, parcel age, source coverage, candidate type, and accessibility can all be expressed at a cell level. That common shape makes scoring and map publication easier to reason about than a collection of unrelated source-specific layers.

Why Drive Time Instead Of Radius

Radius search is attractive because it is cheap and easy to explain. It is also often wrong for operational work. Serviceability depends on road network, traffic assumptions, crossing patterns, barriers, dispatch origin, and the shape of the service area. Two parcels the same distance away can have very different operational meaning if one is reachable by a direct corridor and the other is separated by slow roads.

Drive-time features are an attempt to make the score reflect reachable opportunity rather than geometric proximity. The platform builds sparse travel time matrices and accessibility features so a cell can be evaluated by what is practically reachable within configured constraints. That does not make the score perfect. It makes the assumptions more operationally honest.

The tradeoff is compute and freshness. Routing matrices and accessibility features should be built by jobs and services, not by the interactive map. The console should show published features and their freshness, then let the operator inspect and decide. If a layer is stale or incomplete, the system should say so rather than silently falling back to an easier but misleading metric.

Score Families

Score families are a way to keep methodology explainable. A single aggregate score can be useful for ranking, but it can also hide why a place looks interesting. Separate families let the platform distinguish source coverage, parcel intensity, accessibility, smoothing context, and other opportunity signals. The map can then show both an overall interpretation and the reasons behind it.

This matters for review. An operator may trust a high score more if it comes from several consistent signals. They may discount it if the score is mostly a smoothing artifact or a sparse source. They may save a selection because the commercial signal is strong even if another family is weak. The methodology should support that judgment instead of pretending that scoring is a black box.

Score families also support downstream reuse. Marketing may care about one kind of opportunity. Service planning may care about another. A future market intelligence article may want to explain commercial activity in a corridor without using the same score that powers campaign targeting. Keeping score families explicit makes those uses possible.

Publication And Inspection

The final methodology step is publication. Jobs build parcel features, hex features, smoothed context, travel-time matrices, accessibility features, scores, and map layers. The geo console consumes those published artifacts. This keeps expensive compute outside the interactive request path and gives operators a stable surface to inspect.

Publication also creates a natural quality boundary. A map layer can carry freshness, source coverage, score version, and known limitations. If source data changes, the platform can rebuild and republish. If scoring logic changes, the layer version can explain why results moved. If a downstream workflow imports a saved selection, the selection can reference the layer or context it came from.

This is the difference between methodology and a one-off analysis. A one-off analysis can produce a map; a methodology produces a repeatable path from source evidence to inspected and reusable spatial decisions.

Failure And Calibration

Every scoring methodology needs humility. Geocoding errors, parcel misclassification, stale sources, sparse areas, routing assumptions, and over-smoothing can all distort the map. The system should make those risks visible enough that operators can calibrate their trust. Tests can protect feature and routing contracts, but human inspection still matters.

Calibration should happen at several levels. Engineers can test feature builders and routing behavior. Operators can compare map layers against field knowledge. Saved selections can record why a set of cells was chosen. Future outcomes can show whether a score family was useful. That loop is what lets geo mature from a map into a platform capability.

How This Supports Broader Insight

The same methodology can support public-facing market intelligence without turning every article into a software explanation. H3 cells, drive-time reach, parcel evidence, and score families can help explain where commercial or industrial activity clusters, where service reach is strong, or where the local built environment is changing. The public article would not need to describe every job and feature builder. It could cite a methodology note like this one and then focus on the business interpretation.

That is why the methodology belongs in the engineering site. It gives the company a disciplined way to say how map-based insights are produced, what the limits are, and why the analysis is more than a radius search. Readers who want the deeper technical context can follow the links; readers who only need the market observation can stay at the broader article.

How To Review A Scored Map

A scored map should be reviewed in layers. First, the reader should ask whether the source population is appropriate: parcels, customers, permits, properties, jobs, or other facts. Second, they should ask whether the spatial unit is appropriate for the question. H3 cells are useful for comparing areas, but they do not replace parcel-level evidence when a decision depends on a specific property. Third, they should ask whether the travel model matches the business interpretation. Drive time is a better proxy for service reach than a simple radius, but it still represents a model, not a guarantee.

The score itself should then be decomposed. A cell can look attractive because it has many relevant parcels, because it is close to existing work, because it has sparse coverage from competitors, or because it aligns with a campaign strategy. Those reasons should remain inspectable. A single opaque score is less useful than a ranked area with visible contributing features and a clear explanation of what the score is trying to optimize.

This review posture keeps the methodology honest. It lets the company publish or use map-based insight without pretending the model is more exact than it is. The right claim is disciplined: given these sources, assumptions, and weights, this area appears more relevant for this operational question.