Make an Annotated Location Map From Supplied Coordinates for a Film Pitch
Make an Annotated Location Map From Supplied Coordinates for a Film Pitch
Every location map in a pitch deck makes an argument about geography. Three labelled pins on a coastline can look equally finished when they sit on the right quay and when they sit on the wrong hemisphere. The picture itself will not tell you which one you have.
What separates a useful location map from a decorative one happens before anyone draws anything. Somebody reads the supplied table, works out what its numbers mean, loads them so they keep that meaning, and checks the result against something outside the table. Only then do they choose an extent, a label scheme and a legend for a particular reader.
That reader is deciding whether to develop your film. They need to know where the story happens and which places are genuine candidates for a shoot. They do not need a map that looks surveyed when it isn't.
Read the table before you open a basemap
Start with the file, not the map. Open the table in whatever reads it comfortably and answer five questions in writing, because in three weeks you will not remember any of them.
- Which column identifies a place, and is that identifier stable?
- Which columns hold coordinates, and which is which?
- What units and what coordinate reference system did the supplier declare?
- What does each row represent — a place in the story, or a place you might actually film?
- What is the status of that row: confirmed, candidate, unknown, rejected?
Keep the original file untouched. Work from a copy, or better, load it without editing at all. The moment you start overwriting values so the points "look right," you have destroyed the only record of what you were given.
Here is a fictional three-point table for a fictional feature pitch. The coordinates are invented; they are placed in a real city so the example behaves like real data. A supplier's note travels with the file and says: x is longitude, y is latitude, WGS 84 (EPSG:4326), supplied 11 September. Role: "story" means the place appears in the narrative; "site" means the production might film there.
id,name,role,status,x,y
P1,North Pier,story,,10.74312,59.90971
P2,Ferry Terminal,site,candidate,10.74105,59.90836
P3,Warehouse 7,site,candidate,10.74688,59.90602
Three rows, three places, and already a distinction that matters more than any cartographic choice you will make later: one of these is a place in a story and two are places you might stand a camera. A deck that blurs them is telling the financier something untrue about what has been secured.
Note also what the file does not tell you. The headers say x and y. Those names are a convention, not a guarantee. The declared system is in the accompanying note, which is part of the data whether or not it lives in the same file.
If any of the five answers is missing, ask the person who supplied the table. Guessing until the pins land somewhere plausible is the failure this whole exercise is designed to avoid.
Import what the table says, then check where it landed
The delimited-text import in QGIS asks you to name the fields that hold X and Y and to choose the geometry's coordinate reference system. The supplied QGIS documentation covers explicit field selection alongside a geometry CRS, and an import preview before you commit. Menu names below follow the QGIS 3.40 documentation; 3.40 is now marked end-of-life, so check the equivalent controls in the version you actually have installed before following any label literally.
Column order is not evidence. Plenty of tools and regional conventions write latitude first. And the EPSG definition of 4326 lists latitude before longitude, while most files and most software list longitude first — so the code names the system without settling your file's field order. That has to come from the supplier.
I have not run the walkthrough below. The numbers, though, are chosen so the failure states are arithmetic rather than a matter of judgement — you can verify where a swapped pair lands without opening any GIS at all.
Take the table above and import it three times, naming the layers so you can tell them apart:
- As documented. X field =
x, Y field =y, geometry CRS = EPSG:4326. - Axes swapped. X field =
y, Y field =x, geometry CRS = EPSG:4326. - System wrongly assigned. X field =
x, Y field =y, geometry CRS = EPSG:3857.
The first is the table the supplier described. The points sit within about half a kilometre of each other — roughly 190 m between the pier and the terminal, about 460 m between the pier and the warehouse, spread across a box about 330 m east–west and 410 m north–south. That is a small cluster, and it tells you something about the deck before you design anything: at this scale you cannot show buildings, so the map's job is the relationship between three places and their relation to the water, not a site plan.
The second import is the interesting one. Nothing is invalid. Swap the pair 10.74312, 59.90971 and you get longitude 59.90971, latitude 10.74312 — both inside the legal ranges for EPSG:4326, so the software has no reason to complain. You have placed a Norwegian waterfront in open water in the Arabian Sea, roughly 6,800 km from where the note says it is.
Zoom to the layer and it will look fine. The cluster is still a cluster — the swapped points span roughly 400 m by 650 m, the same order of magnitude as the correct version — so an extent check on size alone will not catch this error. What catches it is position. Overlay the layer on a reference you trust, look at one place you can identify independently, and ask whether it is where it should be. A known landmark, a coastline you can name, a second dataset from a different source: any of these will do. What won't do is checking the table against itself.
Assigning a coordinate system is not the same as transforming one
The third import fails differently, and it is worth understanding why. A layer's coordinate reference system setting tells QGIS how to read the numbers already stored in the file. Changing that setting reinterprets the numbers; it does not convert them. Converting them is a different operation — exporting or reprojecting the layer into another system — and it produces new numbers. If a point is in the wrong place, reprojecting it will not fix it. Only correcting the interpretation will.
So in the third import, the correct longitude and latitude values get read as metres in EPSG:3857, Web Mercator. The points land roughly ten metres east and sixty metres north of the projection's origin, and the whole cluster spans about 5.8 mm east–west and 3.7 mm north–south. Here the extent check does fire: zoom to the layer and you are looking at an extent nearly five orders of magnitude smaller than the half-kilometre box the note describes, and the cluster's shape has flipped from taller-than-wide to wider-than-tall. That is what a genuinely wrong layer CRS usually looks like — not a subtle displacement, but a collapse.
The correct sequence is: assign the actual source system, which for this table is EPSG:4326, because that is what the numbers are. Then choose a project CRS for display, which controls the common view through coordinate transformations. The project CRS is a viewing choice and you can change it freely; the layer CRS is a claim about what the data is, and you should not change it to make something appear where you want it.
For a half-kilometre site in southern Norway, a projected system covering the area is the sensible display choice — UTM zone 32N (EPSG:25832 or 32632), for example. At roughly 1.75° from that zone's central meridian, the scale distortion is a fraction of a percent, which is nothing on a pitch map.
Choose Web Mercator for the display instead and you inherit a real problem. Web Mercator's scale factor is sec φ, so at 60° north a length on the projected plane is about twice the ground distance. A metric scale bar drawn in that projection overstates how far apart things are by roughly a factor of two. If you display in Web Mercator at this latitude, check the bar against a distance you know rather than trusting the number underneath it. The projection changed the view; it did not change the source's position or the fact that you are looking at a stretched picture of it.
Annotate for the decision the deck has to support
Now you can design. Every choice below should be traceable to the reader's decision rather than to a house style.
Extent. The three correct points fill a box about 330 m by 410 m. Frame enough around them that the water reads as water and the town reads as a town, and no more. If the pitch's claim is "these three places are within a short walk of each other," the frame has to make that legible; if the claim is "the warehouse sits across the water from the terminal," the frame has to include the crossing.
Hierarchy. Story places and candidate sites get different symbols, and the legend says which is which in the project's own words. Status gets its own treatment — a candidate is drawn as a candidate. Crucially, status comes from the production office, not from the map. You cannot read availability off a coordinate.
Labels. Name plus role is usually enough. Keeping the source identifier (P1, P2, P3) on the map as a small index is worth the space: it lets someone holding the deck cross-reference a pin to a row in the table without asking you.
Orientation. A north arrow helps, but a coastline, a road or a district name helps more, because your reader may not know the city at all.
Scale and attribution. A scale bar or a stated distance, plus where the coordinates came from, the basemap credit if you used one, and the date the table was supplied. A basemap needs its own permission check before the deck circulates outside the team.
What not to claim. No walking times, no driving times, no route lines you drew yourself and then drew confidently. No boundaries. No access, ownership or availability statements the table does not support. A pin next to a road does not establish that anyone can park there.
What not to expose. If a story location is a private address, or a candidate site is sensitive, think about whether it belongs on a slide that leaves the room. A map is easy to screenshot.
Export and inspect the map where it will be read
Build the export as a print layout rather than a screenshot of the working canvas: the QGIS training material describes a layout that holds a map item together with the explanatory items around it, and exports the result. That is the right container, because a title, legend, scale and source note are part of the map's claim, not decoration bolted on afterward.
Then reopen the exported file at the size the deck will actually be shown. This is the step people skip, and it is where the small failures live: a label clipped by the frame edge, text that was legible at full screen and is not legible on a slide, a legend key whose symbol no longer matches the layer after you changed one of them, a source note that lost its date.
Check one more thing while you are looking: that nothing sensitive became legible in the export that was only marginal on screen.
If the pitch also needs a sketch of invented geography — the fictional town's districts, the imagined ferry route, the made-up relationship between two places that do not exist — keep it as a separate artifact, drawn in a visibly different style and labelled as invented and not to scale. It can sit in the same deck. It should not sit in the same visual register as the georeferenced map, because the two are doing different jobs: one is a claim about real places, the other is a description of a story.
What you keep afterwards
Three things, and they are small. The source table, unchanged. The imported layers, named so their interpretation settings are recorded — something like locations_as_documented_EPSG4326 rather than final_v3. And a short note listing the source file and its date, the declared CRS, which field you mapped to X and which to Y, the layer CRS you assigned, the project CRS you displayed in, and the status of each place.
That note is what lets you answer "where did this come from?" six months later, when the deck has been forwarded twice and someone wants to visit a place that no longer looks the way it did. It is also the honest boundary of the map: it shows what the records said, at the time they said it. Whether anyone can film there is a different question, with a different answer, and it does not live on the map.
Frequently asked questions
What five questions should I answer in writing before opening a basemap?
Which column identifies a place and whether that identifier is stable; which columns hold coordinates and which is which; what units and coordinate reference system the supplier declared; what each row represents—a story place or a possible shoot site; and what the status of each row is: confirmed, candidate, unknown, or rejected. Keep the original file untouched and work from a copy or load it without editing. If any answer is missing, ask the supplier.
How can swapped X and Y axes look plausible, and how do I catch the error?
Swapping can produce values still inside legal ranges for EPSG:4326, so the software does not complain; the article's example moves a Norwegian waterfront to open water in the Arabian Sea about 6,800 km away. Zooming to the layer can still look fine because the cluster size stays the same order of magnitude, so an extent check on size alone will not catch it. Overlay the layer on a reference you trust, look at one independently identifiable place, and ask whether it is where it should be.
Why is assigning a coordinate system different from transforming one?
A layer's CRS setting tells QGIS how to read the numbers already stored in the file. Changing that setting reinterprets the numbers; it does not convert them. Converting is a separate operation—exporting or reprojecting—and produces new numbers. If a point is in the wrong place, reprojecting will not fix it; only correcting the interpretation will. In the example, assigning EPSG:3857 to correct longitude and latitude makes them read as metres, collapsing the cluster to millimetres and triggering an extent check.
What should an annotated map claim, and what should it avoid?
Every choice should trace to the reader's decision. Frame an extent that makes the relevant relationship legible. Give story places and candidate sites different symbols, with status coming from the production office, not read off a coordinate. Include name plus role, source identifiers, orientation, scale or stated distance, source date, and basemap credit if used. Do not claim walking or driving times, route lines, boundaries, or access, ownership, or availability the table does not support. Think about whether private or sensitive locations belong on a slide that leaves the room.
What should be kept after exporting the map?
Keep the source table unchanged; the imported layers named so their interpretation settings are recorded, such as locations_as_documented_EPSG4326 rather than final_v3; and a short note listing the source file and date, declared CRS, which field was mapped to X and which to Y, the layer CRS assigned, the project CRS displayed in, and the status of each place. Reopen the exported file at the size the deck will actually be shown and check for clipped labels, legibility, legend symbols that no longer match, and a source note that lost its date. If the deck also needs invented geography, keep it as a separate artifact in a visibly different style, labelled as invented and not to scale.