Travel Photo Metadata: Tag a Multi-Country Library by Country and City¶
The short answer
A multi-country trip is not one geotag problem; it is a taxonomy problem. Write the country, state, and city into the standard IPTC location fields in bulk, grouped by day, and your catalog filters by country in one click. Coordinates alone will not do that. The words in City, ProvinceState, and CountryName are what Lightroom's Library Filter reads.
Three weeks. Five countries. Twelve cities. Roughly 3,000 frames sitting on a drive when you get home, and not one of them knows what country it belongs to.
The slow way to fix that is the one most people reach for first: open the catalog, drop a pin on each photo, move to the next. That is a coordinate per frame, by hand, three thousand times. The pros I talk to who file stock and blog work from trips do not do it that way twice. They do it once, learn the lesson, and switch to a schema.
This post is about the schema. Not the pin-by-pin grind, and not the GPX timestamp mechanics that belong in the multi-day GPX matching guide. This is about the words you write into your library so it answers the only question a travel archive ever gets asked later: show me everything from Portugal.
A note on what "metadata" means here, because the word gets stretched. A coordinate is a number pair: latitude and longitude in the EXIF GPS block. A location is a set of words: Lisbon, Lisboa, Portugal, PT. Those are different fields, and they answer different questions. A coordinate puts a dot on a map. The words are what a text filter, a stock-agency ingest pipeline, and a future you typing "Portugal" into a search box can all actually read. A multi-country trip needs both, but the words are the part everyone skips and the part that does the filtering.
I am a photographer, but I do not shoot travel for a living. The workflow below is assembled from how working travel and stock shooters describe their location passes, from the IPTC location-field documentation that defines what goes in each slot, and from the Lightroom keyword and filter mechanics that Adobe and evangelist Julieanne Kost document directly.
Why does coordinate-per-photo geotagging fail on a big trip?¶
Coordinates are accurate and almost useless for browsing. A latitude of 38.7223 tells a map exactly where you stood. It tells your search box nothing. Nobody types "38.7223, -9.1393" into a filter to pull their Lisbon set.
The reason is that Lightroom's Library Filter, and every other catalog tool's search, reads named location fields, not raw GPS. As Adobe documents, the Metadata mode in the Library Filter offers Country, State/Province, City, and Location as filterable columns. You pick a country in one column and the grid narrows to that country. That only works if the country name is written into the file. A bare coordinate does not populate those columns on its own.
Lightroom can reverse-geocode a coordinate into an address, but that step is optional, rate-limited, and disabled by default for privacy. Working pros who depend on the location filter do not leave it to chance. As one Lightroom Queen forum thread on exactly this question lays out, the City, State/Province, Country, and ISO Country Code fields are most reliable when you write them yourself rather than hoping the auto-geocoder filled them.
So the real job on a multi-country trip is not "geotag 3,000 photos." It is "write the right country and city words onto 3,000 photos, in as few passes as possible." That is a taxonomy problem, and taxonomy problems are solved by schema, not by clicking.
What location fields actually make a library filterable?¶
The standard is IPTC, and it is more precise than the friendly Lightroom labels suggest. The IPTC Photo Metadata Standard defines a Location Created structure (where the photo was taken) and a Location Shown structure (what place appears in the frame). For most travel work the two are the same, and the IPTC user guide walks the hierarchy field by field. These are the slots, named by their XMP identifiers, not just their friendly labels:
| Friendly name | XMP field ID | What you write | Example |
|---|---|---|---|
| Sublocation | Iptc4xmpExt:Sublocation |
Neighborhood or landmark | Alfama |
| City | Iptc4xmpExt:City |
Nearest settlement | Lisbon |
| State / Province | Iptc4xmpExt:ProvinceState |
Full name, not abbreviation | Lisboa |
| Country | Iptc4xmpExt:CountryName |
Country name | Portugal |
| Country Code | Iptc4xmpExt:CountryCode |
ISO 3166 code | PT |
| World Region | Iptc4xmpExt:WorldRegion |
Continent or region | Europe |
Two rules from the user guide are worth keeping. First, write the full State/Province name rather than an abbreviation; the IPTC guide recommends full names for international clarity, because a two-letter abbreviation that is obvious at home is ambiguous abroad. Second, the Country Code field is not a free-text box. It should resolve to an ISO 3166 code, the official two-letter or three-letter country code that ISO maintains. Stock agencies and editorial ingest pipelines validate against ISO 3166; an ad-hoc "POR" or "Port." can bounce a submission that "PRT" sails through.
The reason to name the field IDs and not just the labels: Lightroom shows you "Country," but Bridge, Capture One, Photo Mechanic, and every stock-agency uploader read the underlying Iptc4xmpExt:CountryName property. Write to the field, and every downstream tool inherits it. Write to a Lightroom-only label, and you are betting the next tool maps it the same way.
The schema approach: group by day, write by city¶
Here is the shift that turns a three-week archive from an afternoon of clicking into a 20-minute pass. You do not tag photos one at a time. You tag groups, and on a trip the natural group is already sitting in your folder structure: the day.
The pros I talk to who run trips two to four times a year tend to converge on the same habit. One folder per shooting day, named with the date and the place, like 2026-07-02_Lisbon. By the time the trip is over, the folder names are the taxonomy. A day in Lisbon, a day in Sintra, a day on the train to Porto. Each folder is a homogeneous location set, which means each folder needs exactly one location schema applied to the whole batch.
That collapses the math. Three thousand frames across twelve cities is not 3,000 location decisions. It is twelve. You select a day's worth of frames, write City, State/Province, Country, Country Code, and World Region once, and apply to the whole selection. Twelve passes, one per city, and the entire trip is tagged.
This mirrors how Julieanne Kost describes hierarchical keywords in Lightroom Classic: build a nested structure once, like Europe > Portugal > Lisbon, and applying the leaf applies the whole branch. Kost's Painter tool lets you click-drag a keyword across a grid of images, and a hierarchical keyword set is the manual mirror of the bulk-schema idea. The difference is that keywords are a parallel free-text taxonomy, while the IPTC location fields are the structured ones the Map filter and stock pipelines expect. Smart travel libraries carry both: location fields for the structured filter, a Place keyword branch for the free-text search.
How do you write one city schema across a whole day at once?¶
This is the bulk pass, and it is the part Jade GT was built to make trivial. The gesture is the same one from the single-venue pin-drop, scaled to a day's folder and pointed at the named fields instead of just the coordinate.
1. Drop one day's folder onto the page¶
Open Jade GT in your browser and drag a single day's folder, 2026-07-02_Lisbon, onto the drop zone. Nothing uploads anywhere; the files stay on your machine. You are working one homogeneous location set at a time, which is the whole point.
2. Fill the location schema once¶
On the Location tab, drop the map pin on the city for the coordinate, then fill the named fields below it: City Lisbon, State/Province Lisboa, Country Portugal, Country Code PT, World Region Europe. Add a Place keyword branch if you keep one. That is the entire schema for this day. You will retype it for the next city and never again for this one.
3. Preview on ten frames¶
Before you commit to the whole day, Jade GT shows the resulting fields on the first ten frames. Country, city, code, keywords: all visible, all editable. This is your "did I spell Lisboa right" moment. Catch a typo here, not after it is baked into 300 files.
4. Apply to the selection¶
One click. Every frame in the day's folder gets the same City, State/Province, Country, Country Code, and World Region written into the IPTC fields on disk. Move to the next day's folder and repeat. Twelve cities, twelve short passes.
5. Open Lightroom to a library that filters by country¶
Import as usual. Now open the Library Filter, switch to Metadata mode, and pick the Country column. Every country you visited is listed with a count beside it. Click Portugal and the grid is your Portugal set. Click again to add City and you are down to Lisbon. As Adobe's finding-photos documentation describes, you can stack those columns to drill state to city to sublocation. That stack only works because the words are in the file.
You can verify any single frame's fields in an EXIF and IPTC viewer before you trust the whole batch.
Where does the GPX track fit on a travel trip?¶
It fits, but it is the supporting act here, not the headline. If a given day was a single city, you do not need a track at all; one pin and one schema cover the whole folder. The track earns its keep on the days you moved: the road day across a border, the hike that crossed three valleys, the city where you walked six neighborhoods and want each frame on the right street.
The mechanic is timestamp matching, and it crosses time zones, which is where travel bites. ExifTool's reference geotag documentation is explicit that it treats image times as local and GPS times as UTC unless you tell it otherwise, and that you must specify the correct offset per image when you cross zones. A clock an hour off at a border drops every frame an hour down the road. The full walkthrough of that matching gesture, clock sync and tolerance included, lives in the multi-day GPX guide; there is no reason to re-teach it here.
The point for the schema workflow: even when you do match a track, the GPX gives you coordinates, not country names. You still run the city schema pass afterward to put the words in. The track and the taxonomy are two layers, and the taxonomy is the one that filters.
What GPX gives you and what it doesn't
A GPX file is a light-weight XML format for GPS waypoints, routes, and tracks, the format your phone's logger or a field app like Gaia GPS exports. It carries timestamped coordinates. It does not carry "Portugal." Matching a track writes the GPS block; it does not write Iptc4xmpExt:CountryName. That field is always a separate, deliberate write.
A note on privacy and where the coordinates live¶
Two things worth knowing before you publish a travel set. First, the operational one: Jade GT runs entirely in your browser. The folders you drop, the schema you type, and the IPTC fields it writes never leave your machine. Nothing uploads, nothing syncs, nothing trains a model on your trip.
Second, the general-information one, not legal advice: precise location metadata is great for a stock pipeline and worth thinking about before posting to the open web. A home address embedded in a frame, or the exact coordinate of a private property you photographed, travels with the file wherever it goes. Many photographers keep full IPTC location fields on their archive copies and strip or coarsen the GPS block on web exports. The fields make your library searchable; how precise a copy you hand to the public is a separate, deliberate choice.
What this workflow is and is not¶
Two edges to know before you start
- This is a location-taxonomy pass, not a cull. It writes where every frame was taken. It does not rate, pick, or color-correct. Keep doing that in Lightroom or Capture One afterward.
- One schema per homogeneous folder. The whole speed-up depends on each batch being one place. A folder that mixes Lisbon and Porto frames needs two passes, or a re-sort first. Day-named folders keep batches honest.
The schema does one job: it makes a 3,000-frame, five-country library answer "show me everything from Portugal" in one click. That is the whole pitch for the location pass.
FAQ¶
Do I need GPS coordinates if I write the country and city fields?
Not for filtering. The Library Filter reads the named IPTC fields, so a frame with CountryName set to Portugal and no GPS block still filters into your Portugal set. Coordinates add the map dot and let Lightroom reverse-geocode; the words do the searching. For a clean library, write both, but if you only do one, do the words.
Will these fields survive into Lightroom, Capture One, and stock uploaders?
Yes. Jade GT writes the standard Iptc4xmpExt location properties into the file, the same ones every major catalog tool and agency ingest pipeline read. Write the field, and the next tool in your chain inherits it.
What country code should I use, the two-letter or three-letter ISO code?
Either is valid ISO 3166; check your agency's spec. Editorial and stock pipelines often prefer the three-letter alpha-3 code (PRT) for clarity, while consumer tools default to alpha-2 (PT). The rule that matters: it must be a real ISO 3166 code, not an improvised abbreviation.
Try it on one day's folder¶
Pick the messiest day from your last trip, the one that crossed a border or wandered six neighborhoods. Drop that one folder into Jade GT, fill the city schema once, preview on ten frames, and apply. If the Country column in Lightroom lights up the way your archive always needed, the other eleven days are the same gesture, eleven more times.
Sources¶
- IPTC Photo Metadata Standard: defines the Location Created and Location Shown structures that hold the country and city fields.
- IPTC Photo Metadata User Guide: field-by-field guidance for City, State/Province, Country, and ISO Country Code, including the full-name recommendation.
- ISO 3166 Country Codes: the official maintenance source for the alpha-2 and alpha-3 codes the Country Code field should resolve to.
- ExifTool Geotagging Documentation (Phil Harvey): reference implementation for GPX matching and the UTC-vs-local-time handling that crossing time zones requires.
- GPX: the GPS Exchange Format (Topografix): the XML track format a phone logger produces, carrying timestamped coordinates but no place names.
- Gaia GPS, Export Data as GPX, KML, or GeoJSON: a mainstream field app's documented GPX export path.
- Adobe, Find photos in a catalog (Lightroom Classic): documents the Library Filter Metadata mode and the Country, State/Province, City location columns.
- Julieanne Kost, Working with Keywords in Lightroom Classic: hierarchical keyword structures and the Painter tool for bulk application.
- Lightroom Queen Forums, How IPTC city, state, country, and ISO code are populated: community discussion on writing the location fields reliably rather than relying on auto-geocoding.
- Thomas Heaton, Blog: a widely-followed travel and landscape photographer documenting multi-country trips and catalog organization.
- Lonely Planet, Travel Photography articles: destination-level editorial standards from a publisher whose photographers file from dozens of countries a year.
- Luminous Landscape, Photo Travel: craft-level travel pieces reinforcing that workflow, not gear, is the differentiator on multi-country trips.
Have a travel-archive workflow question this did not answer? Reply to this post or email me directly. The next version of this guide comes from the trips that did not fit the schema.
Reply to Kenny
Questions, corrections, or a workflow story of your own? Send a note. It goes straight to my inbox.