Cross-validation and quality control

ONE WAY, NOT THE ONLY WAY

QGIS usually offers several ways to do the same task: a processing algorithm, the Field Calculator, a plugin, or editing by hand. The steps in this module are examples of how to do each task, tested with the course’s sample data. They are not the only way, and other methods are equally valid as long as the outputs meet the guide’s requirements and agree with each other. Where a choice affects correctness (for example, using area($geometry) instead of $area), the module says why.

Before we begin

NOTE

For exercises in this module, you will use the bnhr_qgis-sflma-mapping-001.gpkg inside the data subfolder in the BNHR_QGIS-for-SFLMA-Mapping folder, and the outputs of the previous modules.

The geopackage also contains a fictional returned application with one deliberate error for each check in this module.

What we want to achieve

1. Confirm that the technical description closes.
2. Confirm that the area agrees across the polygon, the technical description, the attribute table, and the map.
3. Confirm that the corner coordinates agree across the shapefile, the computed coordinates, and the technical description.
4. Check the attributes and file names against the guide’s rules.
5. Check the application area against reference layers.

What we have

1. The complete outputs of the sample application from the previous modules
2. The returned application: returned_boundary, returned_corners, returned_td, and returned_tie_point
3. ref_forestland and ref_existing_tenure - fictional reference layers for the overlap checks

PRO-TIP

Load returned_boundary and returned_corners with the names area_boundary and area_corners. The checks below use those names, so the same expressions work on any application.

Relevant QGIS knowledge/skills

• Selects and filters by attribute
• Select by location
• Spatial predicates
• Expressions

Why cross-validate?

LEARNING OBJECTIVES

1. Understand what reviewers compare across the four outputs.
2. Distinguish rounding differences from real errors.

The four outputs are four views of the same area. Reviewers compare them against each other, so every value that appears in more than one output must agree:

Value	Appears in
Corner coordinates	Point shapefile (geometry and NORTHINGS/EASTINGS), computed coordinates file, technical description (through the traverse)
Bearings and distances	Technical description, map table, polygon geometry
Area	Polygon geometry, AREA attribute, map title block, technical description (through the traverse)
Location and applicant	Attributes of both shapefiles, map title block, file names

Some differences are expected: bearings rounded to the second and distances rounded to the centimeter do not reproduce a polygon to the millimeter. For the sample application, rounding moves the plotted corners by up to 7 millimeters and changes the area by 4.6 m² (0.0005 ha). The checks below separate rounding from errors.

Closure of the technical description

LEARNING OBJECTIVES

1. Compute the misclosure of a technical description.
2. Express it as a relative precision.

5.1. Checking that the technical description closes

Level: Intermediate

What we want to achieve

• The linear misclosure of a technical description and its relative precision, computed from the bearings and distances as written.

1. With the Field Calculator (), add an AZIMUTH field (Decimal number) to returned_td that reads the bearing text back into an azimuth:

with_variable('p', regexp_matches("bearing", '([NS])\\s*(\\d+)\\D+(\\d+)\\D+(\\d+(?:\\.\\d+)?)\\D*([EW])'),
with_variable('q', to_real(@p[1]) + to_real(@p[2]) / 60 + to_real(@p[3]) / 3600,
CASE WHEN @p[0] = 'N' AND @p[4] = 'E' THEN @q
     WHEN @p[0] = 'S' AND @p[4] = 'E' THEN 180 - @q
     WHEN @p[0] = 'S' AND @p[4] = 'W' THEN 180 + @q
     ELSE 360 - @q END))

S 55° 09’ 34” E back to an azimuth of 124.84°

2. Add the DEPARTURE (east-west component) and LATITUDE (north-south component) of each line:

"distance" * sin(radians("AZIMUTH"))

"distance" * cos(radians("AZIMUTH"))

Azimuth, departure, and latitude of each line

3. For a closed figure, the departures and the latitudes each add up to zero. The linear misclosure is how far they miss; preview it in the Field Calculator:

sqrt(sum("DEPARTURE") ^ 2 + sum("LATITUDE") ^ 2)

The returned technical description misses by 447.92 meters

4. Express it as a relative precision, the perimeter divided by the misclosure:

'1:' || format_number(sum("distance") / sqrt(sum("DEPARTURE") ^ 2 + sum("LATITUDE") ^ 2), 0)

Technical description	Misclosure	Relative precision
sample_td	0.005 m	1:369,491
returned_td	447.92 m	1:3

SOMETHING TO THINK ABOUT

The sample closes within rounding. The returned technical description misses by almost half a kilometer, which no rounding can explain. Which line is wrong? (Hint: compare each line’s bearing with the polygon. One of them has its E and W swapped.)

Area agreement

5.2. Checking that the area agrees everywhere

Level: Intermediate

1. Compute the area of the polygon in the national grid with area($geometry) (not $area; see Computing the area and location attributes).
2. Compare it with the AREA attribute and with the area printed on the map. Because the map’s area is read from the attribute, the map and the attribute always agree; the attribute and the polygon must be compared.
3. For a polygon plotted from the technical description (as in Exercise 2.2), the polygon is the technical description’s area.

Application	AREA attribute	Polygon, area($geometry)
Sample	23.7585 ha	23.7585 ha
Returned	15.1427 ha	14.7927 ha

The returned application’s AREA is 0.35 ha larger than its polygon.

Coordinate agreement

5.3. Checking that the corners agree everywhere

Level: Beginner

1. Select by Expression () the corners whose NORTHINGS or EASTINGS differ from the point by more than a millimeter:

abs("EASTINGS" - x($geometry)) > 0.001 OR abs("NORTHINGS" - y($geometry)) > 0.001

Corners whose NORTHINGS or EASTINGS do not match their position

In the returned application, corners 3 and 5 are selected

2. Select the corners that are not on the boundary:

distance($geometry, boundary(aggregate('area_boundary', 'collect', $geometry))) > 0.001

3. Check that the number of corners equals the number of lines in the technical description.
4. Compare the computed coordinates file with the shapefile, corner by corner.

In the returned application, corner 5 has its easting and northing swapped, and corner 3 lies 2.5 m off the boundary (so its coordinates do not match its position either).

Attribute and file checks

5.4. Checking attributes against the guide’s rules

Level: Intermediate

Use Select by Expression () to find features that break a rule.

X or Y not blank (on the corners):

"X" IS NOT NULL OR "Y" IS NOT NULL

REGION not in Roman numerals:

NOT regexp_match("REGION", '^(I|II|III|IV-A|IV-B|V|VI|VII|VIII|IX|X|XI|XII|XIII|NCR|CAR|BARMM|NIR)$')

Possible abbreviations (a period in a name, such as Gen. or Sto.; check each one by hand):

regexp_match(concat("NAME", ' ', "PROVINCE", ' ', "MUNI_CTY", ' ', "BARANGAY"), '\\.')

Municipalities or barangays not alphabetized, or separated by anything but a comma:

"BARANGAY" <> array_to_string(array_sort(string_to_array("BARANGAY", ',')), ',')
OR "MUNI_CTY" <> array_to_string(array_sort(string_to_array("MUNI_CTY", ',')), ',')
OR "BARANGAY" LIKE '%, %' OR "MUNI_CTY" LIKE '%, %'

Shared attributes that differ between the corners and the boundary (on the corners):

"NAME" <> aggregate('area_boundary', 'max', "NAME")
OR "TENURE" <> aggregate('area_boundary', 'max', "TENURE")
OR "REGION" <> aggregate('area_boundary', 'max', "REGION")
OR "PROVINCE" <> aggregate('area_boundary', 'max', "PROVINCE")
OR "MUNI_CTY" <> aggregate('area_boundary', 'max', "MUNI_CTY")
OR "BARANGAY" <> aggregate('area_boundary', 'max', "BARANGAY")

In the returned application, these find: X filled in on corner 2; REGION written as Region IV-A; Gen. Nakar; Pisa, Batangan; and every corner disagreeing with the boundary on REGION, MUNI_CTY, and BARANGAY.

Then check the file names against the prescribed naming formats.

CONFIRM BEFORE SUBMITTING

NCR, CAR, BARMM, and NIR have no Roman numeral. Confirm with your reviewing office how to write REGION for applications in these regions.

Checking against reference layers

5.5. Checking the application area against reference layers

Level: Intermediate

1. Use Select by Location () to select the application area where it intersects ref_existing_tenure.

Selecting the application area where it intersects an existing tenure

2. Run Processing Toolbox ‣ Difference with the application area as the input and ref_forestland as the overlay. Any output is the part of the area outside forestland.
3. Recompute the barangays the polygon overlaps with the BARANGAY expression and compare them with the attribute.

The returned application (red) overlaps an existing tenure (blue) and crosses the edge of the forestland (green)

In the returned application, the area overlaps an existing tenure, 5.20 ha of it lies outside the forestland, and it overlaps only Batangan, although its BARANGAY attribute says Pisa, Batangan.

REFERENCE LAYERS ARE INDICATIVE

Administrative boundaries and other reference layers may not be authoritative. Treat an overlap as something to verify with the source records, not as a final finding. See Not all data are created equal.

Final quality control

5.6. Final QC checklist

Level: Beginner

Run through this list for every application before submission:

Coordinate reference system

• Shapefiles, technical description, and tie point are in the same datum and national grid zone
• No layer was converted between Luzon 1911 and PRS 1992
• The projection printed on the map matches the shapefiles
• The map grid is in latitude and longitude on the map’s datum (EPSG:4683 for PRS 1992, EPSG:4253 for Luzon 1911), not WGS 84

Shapefiles

• One point shapefile per parcel and one polygon shapefile for all parcels
• All prescribed fields are present, with text fields of 254 characters (50 for REGION) and coordinates with 3 decimals
• Geometries are valid, fixed by hand rather than with Fix geometries
• AREA is computed with area($geometry)
• Attributes follow the guide’s rules; X and Y are blank

Technical description and coordinates

• Lines are numbered consistently with the corners
• The technical description closes within rounding
• The tie point’s coordinates and the tie line are complete
• NORTHINGS and EASTINGS match the geometry and the coordinates file

Map

• Title, location, area, scale, projection, and legend are present and agree with the attributes
• Technical description and original coordinate tables match the exported files
• Certification and signatories are complete

Files

• All files follow the prescribed naming formats

Capstone: one application from plot to final

General instructions

Using a technical description provided by the instructor, prepare a complete application from start to finish, without referring back to the sample outputs.

Objectives

Produce the four required outputs for a new application, and show that they agree.

Instructions

1. Set up the project in the datum and zone of the technical description (Module 1).
2. Plot the area, create the shapefiles, and fill in the attributes (Module 2).
3. Generate the corners, coordinates, and tie line, and export the technical description and coordinates (Module 3).
4. Produce the map from the layout template (Module 4).
5. Run every check in this module and complete the final QC checklist.
6. Present your outputs and your QC results to the group.

Certification and support

LOOKING FOR CERTIFICATION AND SUPPORT?

We offer additional resources, certificates, official QGIS certification, ongoing support, and other perks to those who join our instructor-led training.

Join an upcoming training to take this as an instructor-led course, or contact us to arrange one for your team or organization.