Digitizing Parcels from a 1:4,800 Scan and Other Scale-Accuracy Mismatches in a GIS Project
A municipal GIS team is digitizing parcel boundaries from a scanned subdivision plan compiled at 1:4,800. The raster was scanned at 400 dpi. The client's request for proposals asks for a parcel layer positionally accurate to +/-5 cm and a PDF plot at 1:1,000. In the same project the team must derive 2 m contours and a slope map for a 40 ha site from a 30 m resolution DEM, and the technician has been given a vector layer that was digitized in a different geodetic datum and shows a consistent 180 m shift to the northeast relative to existing layers.
1. Compute the ground size of one scanned pixel and estimate the best positional accuracy the parcel layer can achieve. Can the +/-5 cm requirement be met?
Read the worked answer
Pixel size on paper: 25.4 mm / 400 dpi = 0.0635 mm.
Ground size of one pixel: 0.0635 mm x 4,800 = 304.8 mm = 0.30 m per pixel.
So every pixel of the source alone is a 30 cm ground cell - six times the requested tolerance, before any digitizing error is added.
Map accuracy: the conventional planimetric standard for a map is about 0.5 mm at compilation scale, i.e. 0.5 mm x 4,800 = 2.4 m. Even the most careful digitizing of this source (typically 0.2-0.5 mm of operator/registration noise, or 1.0-2.4 m on the ground) cannot beat the source.
Verdict: the +/-5 cm parcel accuracy cannot be met from this data - it is out by a factor of roughly 50. The requirement is a survey requirement (GNSS/total station observations on the ground, or a photogrammetric/ortho source of adequate GSD), not a digitizing requirement. Also note that a 1:1,000 plot of data with 2.4 m accuracy conveys a false impression of precision.
Response to the client: state the achievable accuracy against the source, propose either a re-survey of the parcels that matter or a renegotiated specification, and record the lineage and accuracy statement in the metadata. Do not relabel the layer as 5 cm because the software allows a precision setting.
2. Evaluate the proposal to derive 2 m contours and a slope map for a 40 ha site from a 30 m resolution DEM.
Read the worked answer
The DEM is the wrong tool for this deliverable, for three independent reasons:
- Sampling: a 30 m cell means the surface is only described every 30 m. Features shorter than roughly two cells (about 60 m) cannot be represented at all, so an area of 40 ha (about 630 m x 630 m) is described by only about 450 cells in each direction - a very coarse picture for engineering decisions.
- Vertical accuracy versus contour interval: a 30 m DEM (e.g. SRTM-class or a coarse national product) commonly carries vertical error of several metres (often 5-10 m or more). Drawing a 2 m contour interval from it implies more vertical resolution than the data has; the result is smooth, plausible-looking but fictional contours.
- Slope: slope from a 30 m grid averages over 900 m2 per cell and systematically flattens short, steep features. It is a reconnaissance product, not a grading or drainage design input.
Recommendation: use LiDAR or a photogrammetric DEM at 1-2 m spacing for contours at this interval, or retain the 30 m DEM but explicitly downgrade the deliverable (e.g. 10 m contours, regional slope classes) and document it. Either way the metadata and the map legend must state the source resolution, the vertical accuracy and the intended use.
3. What does a consistent 180 m offset to the northeast indicate, and how should it be corrected?
Read the worked answer
A uniform directional offset is the signature of a reference-frame mismatch, not a digitizing blunder. Random digitizing error would scatter in all directions; systematic displacement of the whole layer indicates it was digitized in a different geographic/datum realisation (e.g. a legacy local datum versus the modern geocentric datum, or a different projection) and is being drawn as though it shared the project CRS. Offsets of 100-200 m are typical between old local datums and modern geocentric datums.
Correct handling:
- Identify the layer's true source CRS from the data supplier, its metadata or the coordinates themselves - do not guess.
- Apply a proper datum transformation (a published 3- or 7-parameter Helmert transformation accepted for that datum, or the national transformation grid), not a constant translation.
- If the layer has no CRS record, test candidate transformations against independent control points and inspect the residuals: a correct transformation leaves a small, random-looking residual pattern; a constant shift leaves a structured one.
- Reproduce the transformation in a documented geoprocessing step so it is repeatable, store the layer in the project CRS, and record the source CRS, transformation name and parameters in the metadata.
- Never rubber-sheet or nudge the layer to make it visually line up; that destroys any chance of an audit trail and can vary from editor to editor.