GISI Foundation common mistakes
GISI Foundation · Understand the traps and how to avoid them.
Treating raster cell size as a purely visual setting and comparing two rasters (e.g., slope versus land cover, or a DEM at 10 m versus one at 30 m) as if their cells were directly interchangeable, then computing area or overlay statistics across them without resampling or documenting the mismatch.
Candidates learn cell size as a display/property value in the layer panel and never connect it to ground sampling distance, so they miss that area totals, zonal statistics, and overlay results change with resolution and that mixing resolutions silently biases results.
What to do instead
Before any raster analysis, state the ground sample distance of every input, decide explicitly whether to resample (and with which method: nearest for categorical, bilinear/cubic for continuous), and check whether area or density results are resolution-dependent. Practise by computing the same zonal sum at two resolutions and explaining the difference.
Reading projected coordinates (e.g., 500000, 4500000) as if they were latitude/longitude or vice versa, and reporting a location or distance without checking the coordinate range and units of the layer.
Candidates see numbers in an attribute table or status bar and assume the map's units match their intuition; they do not habitually check whether values fall in plausible degree ranges (lon -180 to 180, lat -90 to 90) versus metre ranges typical of projected systems.
What to do instead
Adopt a routine: inspect coordinate values, confirm the layer's coordinate system and linear unit, and sanity-check magnitude against known extents. Convert one known landmark to both geographic and projected coordinates and verify it lands in the right place.
Choosing a projection for a statewide or national area by default (e.g., Web Mercator or a global geographic system) and then measuring distances or areas in it, or reprojecting data without recognising that reprojection cannot restore accuracy lost in the source.
Web maps make Web Mercator ubiquitous, and candidates conflate 'the map looks right' with 'measurements are valid'; they also assume on-the-fly reprojection in the software permanently fixes the data.
What to do instead
Match projection to purpose: equal-area for density/area comparisons, conformal for navigation/bearing, equidistant or local State Plane/UTM zone for distance work, and note distortion grows away from the standard parallels or central meridian. Remember that reprojection resamples or transforms coordinates but never adds precision.
Confusing topology rules with simple spatial queries, or assuming that overlapping polygons, dangling lines, or gaps are automatically errors that must be deleted rather than conditions to be validated against a stated rule set.
Candidates memorise 'topology' as a vocabulary item and cannot distinguish a legitimate overlapping coverage (e.g., overlapping service areas) from an invalid one, so they either ignore topology entirely or over-correct valid data.
What to do instead
Learn to state the rule first ('polygons must not overlap', 'lines must not dangle', 'no gaps'), then test data against it and decide whether a violation is a data error or a modelling choice. Practise writing the rule set for a parcel layer before running any validation.
Running a buffer or overlay with default parameters (default distance units, default dissolve, default environment extent and cell size) and reporting the output as if the parameters were neutral.
Software defaults are convenient and candidates rarely inspect them; they do not realise that a buffer distance in the layer's units, a missing dissolve, or a clipped processing extent can change counts and areas substantially.
What to do instead
Before running any tool, write down distance/units, dissolve behaviour, environment settings (extent, snap raster, cell size, mask), and the input coordinate system. Re-run one analysis with two different parameter sets and explain why results differ.
Selecting a classification method (equal interval, quantile, natural breaks, standard deviation) for a choropleth by aesthetics alone, then interpreting the resulting map as if class breaks reflected real thresholds in the data.
Candidates focus on making the map 'look balanced' and do not connect classification choice to the statistical distribution of the values, so they misread quantile maps as showing absolute magnitude and equal-interval maps as showing clusters.
What to do instead
Inspect the histogram first, then choose a method that matches the message: quantile for rank/relative position, equal interval for absolute magnitude, natural breaks for clustering, and manual breaks when policy thresholds exist. Always state the method and class breaks in the legend or metadata.
Treating metadata as a form to fill at the end (or skipping it) and delivering data whose lineage, accuracy, currency, and coordinate system cannot be reconstructed by the recipient.
Metadata entry feels administrative and is often left until delivery, when details of sources, processing steps, and accuracy are no longer at hand; candidates underestimate how much metadata drives discoverability and fitness-for-use decisions.
What to do instead
Capture lineage as you work: record source datasets, dates, processing tools and parameters, coordinate system, and known limitations in a running log, then populate the metadata record from it. Test yourself by handing a dataset to a peer and asking whether they can judge fitness for use from the metadata alone.
Accepting a dataset's positional accuracy claim at face value and using it for a purpose with tighter tolerance (e.g., using a 1:24,000-scale-derived boundary for a metre-level setback decision) without a documented fitness-for-use check.
Candidates equate 'digital' with 'accurate' and do not connect source scale, positional accuracy, and attribute completeness to the tolerance required by the decision being supported.
What to do instead
For each project, state the required positional and attribute tolerance, compare it with the dataset's documented accuracy and source scale, and record the gap and any mitigation. Practise converting a source scale to an approximate ground accuracy and judging whether it meets a stated tolerance.
Delivering a map without map elements that make it independently readable (scale, north arrow where orientation is not obvious, legend with units, source and date, projection note), or adding decorative elements that do not serve the reader.
Candidates treat cartography as visual design and prioritise appearance over communication, forgetting that a reader who was not in the analysis cannot interpret classes, units, or orientation without explicit cues.
What to do instead
Use a checklist tied to the map's purpose and audience: title, legend with classification method and units, scale bar or scale statement, orientation, source/date/author, projection or coordinate system note, and a short interpretation note. Have someone unfamiliar with the project read the map and list what they cannot determine.
Skipping the problem-definition and requirements stage and starting in the software, then discovering late that the question, scale, accuracy target, or deliverable format was never agreed with the client or decision-maker.
Hands-on candidates equate progress with tool use and are uncomfortable spending time on scoping; unclear requirements only surface at review, when rework is expensive.
What to do instead
Practise writing a one-page scope before touching data: decision to be supported, questions, required accuracy and scale, data sources, deliverables and formats, assumptions, and acceptance criteria. Get explicit sign-off on that page, and revisit it at each milestone.