Digitising & Topology

Digitising is creating vector features — points, lines, polygons — by tracing something you can see: georeferenced imagery, a scanned sheet from the last lesson, or an existing reference layer. When you draw straight over imagery on screen it is called heads-up digitising, and it is how most local base data still gets made: building footprints from satellite tiles, plot lines from a sanctioned layout, a footpath network from aerial photos.

The mechanics are simple — start an edit session, pick the layer, and place vertices click by click until you close a ring or end a line. The craft is in where the vertices go and how they relate to the features already drawn. A footprint traced with ten careful vertices on the roof edge is worth more than one scribbled with fifty.

Snapping makes the cursor jump to a nearby existing vertex, edge or endpoint when you get within a set tolerance. It sounds minor; it is the most important editing setting you will ever touch.

Without snapping, two boundaries that look joined are actually two separate vertices a fraction of a pixel apart. That invisible gap is a sliver — a hair-thin polygon or a break in a network — and it is the root of most "my analysis is wrong" bugs. With snapping on, the software pulls your new vertex exactly onto the existing one, so a shared boundary is genuinely one line used by both features. Set a sensible tolerance (a few pixels, or a real distance), decide what to snap to (vertices, segments, or both), and turn it on before you draw the first shape, not after.

Topology is the set of spatial relationships between features — which shapes touch, share a boundary, or enclose others — as distinct from their raw coordinates. For a layer that is supposed to partition space cleanly (land parcels, wards, zones), topology is expressed as rules the data must satisfy.

The two rules you will invoke constantly are must-not-have-gaps (adjacent polygons leave no unfilled space between them) and must-not-overlap (no two polygons cover the same ground). A parcel layer that breaks the first rule has holes that vanish from every area total; break the second and you count the same land twice. Other useful rules include lines that must not dangle, and points that must fall inside a polygon. Rules do not fix data by themselves — they flag violations so you can go and repair each one.

Once you validate a layer against its rules, you get a list of errors, each with a location. Now you edit. Common repairs: snap a stray vertex onto the boundary it should share; delete a sliver polygon and let its area rejoin the correct neighbour; move or merge duplicate vertices; trim an overshoot where a line ran past a junction, or extend an undershoot that stopped short.

The efficient move is to enable topological editing while you draw, so that dragging a shared boundary updates both polygons at once and new edges snap to existing geometry automatically. Prevention beats cure: a layer digitised with snapping and topological editing on will produce a near-empty error list, while one drawn carelessly can take longer to clean than it did to create.

Digitising accuracy can never beat its source. Tracing plots off ~10 m Sentinel-2 or medium-resolution imagery yields context, not cadastre; parcel-grade lines need high-resolution imagery, drone survey (as under SVAMITVA for rural abadi land) or an actual survey. India's urban base-mapping programmes set explicit target scales — the National Urban Information System works at 1:10,000 and 1:2,000 for utilities — and your digitising tolerance should match the scale you claim, not the zoom you happen to be at. Record your source, imagery date and intended scale as metadata; a footprint layer with no provenance is a liability the moment someone asks how accurate it is.