Validate a Bengaluru Land-Cover Map in Earth Engine

Why validation is the part that makes a map credible

A classified land-cover map can look persuasive long before it is trustworthy. Clean colours, sharp boundaries and a high training score do not tell a reader whether mapped water, built-up land, vegetation and bare ground are actually correct. Validation is the separate test that turns a visual output into a defensible result.

This walkthrough focuses on a Sentinel-2 land-cover map for Bengaluru's expanding urban fringe. It is deliberately about validation, not about choosing between classifiers. The same workflow works whether your map came from Random Forest, CART, SVM or another supervised approach.

Sentinel-2 is a useful starting point because its multispectral mission supports land monitoring, and its visible and near-infrared bands include 10 m pixels while red-edge and SWIR bands include 20 m pixels. In Earth Engine, use the harmonised surface-reflectance collection for a contemporary Sentinel-2 workflow: COPERNICUS/S2_SR_HARMONIZED. The harmonised collections address the processing-baseline value shift in newer scenes, so they are a safer choice when comparing imagery across the relevant changeover. Earth Engine Sentinel-2 catalogue

The aim is simple: take an already classified image, draw a genuinely independent set of reference labels, compare reference and predicted classes, then report what the errors mean.

Define the question before sampling

Suppose the map has four classes:

• 0 water
• 1 vegetation
• 2 built-up
• 3 bare ground

Write the class definitions before drawing training or validation features. For Bengaluru, "built-up" might include roofs, roads and paved open areas, while "bare ground" might include exposed construction sites, dry fallow plots and quarries. If that boundary is not stated, two interpreters can label the same location differently and the reported accuracy will mix mapping error with an unclear legend.

Also fix the map date or season. A reference label should describe conditions close enough in time to the Sentinel-2 composite. A field that was bare during image acquisition but planted weeks later is not a fair validation point for the earlier map. Good-practice guidance stresses that reference data need sufficient spatial and temporal representation, and should be of higher quality than the map being assessed. Olofsson et al. (2014)

Keep training and validation independent

The most common beginner mistake is reporting the classifier's training accuracy as the map's accuracy. That number is calculated on labels the model has already seen, so it is a resubstitution result, not an independent test. Earth Engine's own supervised-classification guide separates training from validation and describes validation error as the result to estimate with independent data. Earth Engine supervised classification guide

There are two practical ways to preserve independence.

First, collect separate polygons or points for training and validation before modelling. Do not split pixels from the very same small polygon between the two groups. Adjacent pixels often resemble each other, so a random pixel split can make the result look better than performance in a new locality.

Second, when field reference data are scarce, sample validation locations after producing the map, then label each location from dated high-resolution imagery, field photographs or a site visit. Do the interpretation without looking at the predicted class where possible. Record the source, image date, interpreter and a confidence note. Exclude points whose reference class cannot be determined, but state how many were excluded and why.

For a first portfolio project, use the same classes in both datasets, integer labels from 0 upward, and a documented seed. Earth Engine expects class labels used in its standard classification workflow to be consecutive integers starting at zero. Earth Engine supervised classification guide

Worked example: create a balanced validation sample

Assume classified is your Bengaluru classification image, roi is your study boundary, and the output band is named classification. The following code creates candidate points stratified by the predicted map class. Stratification makes sure a small but important class, such as water, is not lost among a large number of built-up pixels.

var classes = [0, 1, 2, 3];

var candidates = classified.rename('mapClass').stratifiedSample({
  numPoints: 75,
  classBand: 'mapClass',
  region: roi,
  scale: 10,
  seed: 42,
  geometries: true
});

print('Validation candidates', candidates);
Map.addLayer(candidates, {color: 'yellow'}, 'validation candidates');

stratifiedSample() returns a FeatureCollection and can request a specified number of samples for each distinct integer class. Its scale, region, seed and per-class options should be recorded because they define how the sample was drawn. Earth Engine stratifiedSample reference

Inspect the candidates in the Code Editor or export them for interpretation. Add a property called refClass to every accepted feature using your independent reference source. Do not change mapClass, because it is the prediction you are testing. A small table might look like this:

After you have labelled and re-imported the points as validation, calculate the error matrix:

var order = [0, 1, 2, 3];
var matrix = validation.errorMatrix('refClass', 'mapClass', order);

print('Validation error matrix', matrix);
print('Overall accuracy', matrix.accuracy());
print('Producer accuracy', matrix.producersAccuracy());
print('User accuracy', matrix.consumersAccuracy());

errorMatrix(actual, predicted, order) compares two feature properties. Its rows represent actual values and its columns represent predicted values, so here rows are reference classes and columns are mapped classes. Supplying order prevents a missing class in the validation set from silently changing the arrangement. Earth Engine errorMatrix reference

Read the results like an analyst

Overall accuracy is the share of validation samples that land on the diagonal of the matrix. It is useful, but it can hide a bad result for a small class. A map that mostly captures Bengaluru's extensive built-up area can still be poor at distinguishing water or exposed soil.

Producer's accuracy answers: of all reference locations that truly belong to a class, how many did the map capture? Its complement is omission error. If vegetation has low producer's accuracy, the map missed real vegetation, perhaps by assigning it to bare ground or built-up land.

User's accuracy answers: of all locations mapped as a class, how many really are that class? Its complement is commission error. If built-up has low user's accuracy, a person using every pixel labelled built-up should expect many false positives.

With equal numbers of validation points per predicted class, raw overall accuracy is a convenient diagnostic, but it is not automatically an area-representative estimate for the whole region. Stratified random designs need analysis consistent with the sampling design. For publication-grade class areas or map-wide accuracy, calculate the area-weighted error matrix, report class-area proportions and quantify uncertainty. Olofsson and colleagues recommend reporting overall, user's and producer's accuracy, estimating class areas from reference information, and reporting confidence intervals. Olofsson et al. (2014)

A concise reporting template

In a project report or portfolio caption, state the image collection, composite period, study boundary, class definitions, reference-data source and date, sampling design, sample counts by class, seed, confusion matrix, and all three accuracy measures. Then add the most important confusion in plain language, such as: "Bare ground was frequently confused with sparse vegetation around construction corridors."

Avoid claiming that a map is "accurate" from a single percentage. A better statement is: "Independent, stratified validation found strong agreement for built-up land but lower reliability for bare ground; results should be interpreted at the stated class definitions and date." That is more useful to a recruiter, supervisor or local planning team than an unsupported headline score.

Frequently asked questions

Can I use the same points for training and validation?

No, use separate and independent validation labels. Reusing training points measures how well the classifier reproduces examples it already knows, which usually overstates map performance and does not test transfer to new locations.

Why should I stratify validation points by mapped class?

Stratification ensures that small or rare mapped classes receive enough checks to reveal their errors. It is especially useful when water, wetlands or bare ground occupy far less area than built-up land, but the sampling design must be reported.

Does a high overall accuracy prove every class is reliable?

No, overall accuracy can be dominated by common classes. Always inspect user's and producer's accuracy for each class and read the off-diagonal cells, because these show the specific land-cover confusions your users will encounter.

Should I label a validation point from imagery taken years later?

No, reference evidence should represent the mapped date or season as closely as practical. Later imagery may show genuine land-cover change, turning a temporally valid map pixel into an apparent classification error.

References

• Google Earth Engine, Sentinel-2 datasets catalogue
• Google Earth Engine, Supervised Classification guide
• Google Earth Engine, ee.Image.stratifiedSample reference
• Google Earth Engine, errorMatrix reference
• Olofsson et al., Good practices for estimating area and assessing accuracy of land change

Cover image: AI-generated illustration (ChatGPT image generation), not satellite data.

Researched and drafted with AI assistance; sources are linked for verification.