Prepare for the GISP by practising decisions, not definitions. For each knowledge area, learn the paired concepts that get confused (datum versus projection, vector versus raster, overlay versus interpolation, count versus rate), work a paper scenario where the wrong choice looks reasonable, and write the metadata line that documents the choice. Finish with a readiness review: if you can state the coordinate reference system, resolution, date, and accuracy of any dataset you touch, and name the analysis method its question requires, you are ready to sit down with confidence.
Datum, Projection, and Coordinate System: Keep Three Ideas Separate
A coordinate reference system pairs a datum, which anchors coordinates to the Earth, with a projection or grid that flattens them. Keep the two independent: they can be changed separately, and confusing them leads to the wrong fix.
A datum defines the size and shape of the Earth model used and where its origin sits; NAD83 and WGS84 are familiar examples. A projection is the mathematical recipe that converts that curved surface onto flat coordinates, such as Transverse Mercator. A geographic coordinate system stores unprojected latitude and longitude on a datum; a projected coordinate system adds the projection and linear units. Whenever you describe a dataset, name all three parts: datum, projection or geographic method, and units.
The distinction matters because the two components fail differently. Reprojecting between coordinate systems on the same datum is a conversion with a fixed formula. Moving between datums is a transformation that needs a defined method and carries its own accuracy, which varies by region. Display software that projects layers on the fly can hide a datum mismatch, so a map can look aligned while the stored coordinates disagree by metres. Practise stating, for any layer, which part changed and which stayed fixed.
Scenario: Two Layers That Refuse to Line Up
When two layers of the same features sit apart, first classify the offset as a projection, datum, or units problem; each has a different fix. Guessing risks silently mislocating the assets you are mapping.
Picture a paper scenario: a county's water-main layer was digitized years ago on NAD27 in a State Plane zone using feet, while new valve locations arrive from GNSS collection referenced to NAD83. A technician overlays them, sees valves consistently offset from the mains by many metres, and reprojects one layer into the other's system. The offset persists, because reprojection on the wrong datum is still the wrong datum, and the technician has changed the projection twice without touching the underlying problem.
The better decision is diagnostic rather than mechanical: confirm each layer's datum and units, apply an approved datum transformation when the datums differ, then verify the result at two or three known points such as road intersections or survey monuments. Any residual after that check should be recorded, with the transformation method used, in the metadata. This matters because a misplaced main can send a crew to dig at the wrong address; the offset's consistent direction is a clue to its cause, not just an annoyance.
table
| Observed symptom | Likely cause | First correction to try | Verification step |
|---|---|---|---|
| Consistent shift in one direction across the whole layer | Different datums | Datum transformation, not plain reprojection | Check the residual at two or three known points |
| Features fit after reprojection; shapes look rotated or sheared | Different projections, same datum | Reproject both to a common system | Compare edge-matching along a seam between zones |
| Everything scaled by roughly 3.28, or its inverse | Feet and metres declared inconsistently | Correct the unit definition in the layer properties | Re-measure a segment of known length |
| Offset that varies randomly across the layer | Different source accuracies, not a CRS issue | Document each source's stated accuracy; do not force alignment | Compare against the highest-accuracy source available |
Vector, Raster, and the Database Underneath Them
Vector models store discrete features with exact boundaries; raster models store continuous surfaces as cells. Let the phenomenon and the planned analysis pick the model, then design tables so every fact lives in exactly one place.
A parcel fabric, a road network, and utility points are naturally vector: boundaries and connectivity are the point. Elevation, temperature, and satellite-derived surfaces are naturally raster, where cell size sets the resolution of every statistic you derive. Many projects use both, and conversion between them is itself a decision: rasterizing a parcel layer forfeits its exact boundary, while vectorizing a smooth surface generalizes it into steps. Name what each conversion costs before you run it, and keep the source model authoritative.
Database design rewards normalized thinking. Splitting one wide table into parcel, owner, and transaction tables joined by keys removes repeated values that drift out of sync when an owner changes. Domains and coded values stop free-text entries like Rd and Road from splitting one road class into two during summaries. When a scenario hands you a flat table with repeated blocks, a strong written answer identifies the redundancy, proposes the related tables and keys, and states which queries become easier and why.
Exercise: Audit Three Datasets Before You Analyze Them
Pick one vector layer, one raster, and one image or derived product. For each, record the datum, projection, units, resolution or scale, acquisition date, and stated accuracy before any analysis. The gaps you find are the preparation material.
Run the audit as a written exercise. For the vector layer, open its properties and note whether the datum and projection are both defined, or whether one is missing and the software is guessing. For the raster, record the cell size and whether any positional accuracy statement exists at all. For the derived product, trace which sensor and acquisition date produced it. Expected observation: at least one field will be unknown or absent, and that gap, not the cell values, is the real finding of the exercise.
Turn the audit into a six-week rotation so it doubles as an adaptable preparation sequence. Weeks one and two, audit layers whose datum and projection differ deliberately and practise the misaligned-layers diagnostic above. Week three, audit a database schema and sketch its normalized form. Week four, audit imagery against the question it would actually answer. Week five, audit an analysis output and ask which projection and method produced it. Week six, audit a finished map for classification and labeling choices. Reorder the rotation toward your weaker areas; the rotation, not the calendar, is the point.
_rubric
- Datum and projection both recorded, and different from at least one other audited layer
- Resolution or scale recorded, with a one-line note on the smallest feature it can resolve
- Acquisition or publication date noted against the date of the event the data must represent
- An accuracy statement found, or its absence recorded as an explicit data gap
- One written sentence per layer saying whether it is fit for your stated question, and why
Overlay, Interpolation, or Density: Name the Method Before You Run It
Overlay answers what coincides where; interpolation estimates values between samples; density summarizes how points cluster. State the question in one sentence first, then choose the method whose assumptions that sentence can actually support.
A setback question, such as which stream segments fall within a buffer of agricultural parcels, is overlay, and its quality depends on the geometry rather than on statistics. Estimating soil readings between boreholes is interpolation, which presumes spatial autocorrelation and depends heavily on where samples were taken. Summarizing where incidents cluster is a density or point-pattern question. Mixing these produces confident-looking maps of things the data cannot support, so the first edit to any analysis plan is the method name written beside the question.
Two follow-on checks earn their keep in scenarios. First, areal units: joining population to zones and comparing results is sensitive to how the zones were drawn, and redrawing boundaries can change the apparent pattern, so report the unit design alongside the result. Second, counts versus rates: comparing zones by raw counts rewards the largest zone, so normalize before ranking and state the denominator you used. Neither check requires new data; both require pausing between the tool and the report.
Scenario: A Floodplain Report Built in Web Mercator
Area and distance measurements inherit the projection they were computed in. A web display projection can look fine on screen yet inflate areas away from the equator; measure in a system whose property matches the task.
Scenario: an analyst joins flood zones to municipal parcels and reports eligible hectares for a grant application, leaving every layer in the projection used by the web map. The numbers are internally consistent, reproducible, and wrong: that projection preserves local angles for display, not area, and its area error grows with latitude. A municipality farther north would see its floodplain inflate more than a southern one, purely from position on the globe. The mistake was not arithmetic; it was never choosing a measurement projection at all.
The better decision reprojects the zones to an equal-area system before computing hectares and names that system in the report. Extend the same logic across properties: preserve shape and local angles for engineering-style work with conformal systems; measure distances from a single facility with an equidistant system centred there; compare regions by area with equal-area systems. When a scenario hands you a measurement task, a strong answer states the property required, names a system providing it, and notes that every projection trades something away.
Ethics, Documentation, and Your Final Readiness Checks
GISCI publishes official ethical guidelines for GIS professionals, and sound practice calls for documented, defensible judgment: record limitations, state sources, and disclose uncertainty. Finish preparation by rehearsing how you would document a contested decision.
Read the guidelines on GISCI's site directly rather than through secondhand summaries, then apply them to paper scenarios. One rehearsal: a stakeholder asks you to publish a flood layer whose accuracy you never verified. The defensible response is neither silent compliance nor flat refusal but a structured choice: publish with its limitations stated in the metadata, or hold publication while you verify, and record the decision either way. Practising that structure, uncertainty named, options weighed, choice documented, builds professional judgment you can also reuse in scenario practice.
Management content overlaps with ethics here: metadata, versioning, and access decisions are stewardship. A scenario that hands you an outdated but only-available dataset tests whether you would document the vintage and its implications rather than quietly proceed. Write each scenario response as a short memo covering what you used, what you assumed, and what you would verify next. That memo format is both a professional habit and a compact way to review every knowledge area in the final week.
_rubric
- You can state the datum, projection, and units of every dataset you touched this month without reopening its properties
- You can explain in two sentences why an area statistic needs an equal-area projection, using the floodplain scenario
- You can name the analysis method for a one-line question and state that method's key assumption
- You can write, from memory, the four audit fields for a dataset: coordinate reference system, resolution or scale, date, accuracy
- You can describe how you would label and document a layer you were unable to verify
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.