Building-Precise Location and Caption Metadata for Architectural Submissions¶

The Jade GT Location tab showing a single building pin dropped on the map, ready to apply to an entire architectural project. — One pin on the exact building face, applied to the whole project before the files leave your desk.

The short answer

Architectural editors want the building name, the architect, the year, and the exact coordinate baked into every file, not pasted into an email. Set the IPTC Headline, Location Created, Creator, Copyright, and Description fields once, then apply them across the whole project in a single browser pass. Files never upload anywhere; you type the project details once.

I shoot buildings. Detroit's Guardian Building lobby, the adaptive-reuse warehouses along the Tucson rail spur, the Chicago towers I keep going back to because the light off the river never repeats. The shooting is the easy part. Architectural photography metadata is the part that decides whether the work gets published. The part that decides whether a project gets published is the twenty minutes of metadata at the end: the caption an editor reads, the credit line that has to match, and the coordinate that puts the pin on the right facade instead of the parking lot across the street.

Architectural editors are strict about this in a way wedding and portrait clients never are. ArchDaily's contributors policy states plainly that it credits architects, photographers, and collaborators, and that it is "not responsible for disputes over credit or authorship submitted inaccurately." Get the credit wrong and the publication can be pulled. The credit, the filename, and the embedded copyright all have to agree, and the place they agree is the metadata, not the body of your submission email.

This post covers both halves of that twenty minutes. First, the location half: building name, the GPS pin on the actual facade, and the Creator and Copyright fields that travel with the file. Then the caption half: an IPTC Description template you can reuse by project type so you are not writing a four-line paragraph from scratch on frame 137. Both halves are the same gesture in the end. Type the project details once, apply them to all 200 frames, done before you import.

A terminology note before we start. When I name a field, I name the actual IPTC or XMP property ID, not just the friendly label your editor shows. The friendly label changes between Lightroom, Bridge, and Capture One. The underlying property ID does not, and it is the property ID that an editor's intake system reads.

Why do architectural submissions get rejected on metadata?¶

Three reasons, and all three live in fields you can set before you submit.

The first is credit. ArchDaily asks for at least five images "with proper credits and authorization" on editorial contributions, and treats inaccurate authorship as grounds for removal. Dezeen's submit-a-story page asks for the project credits and the copyright holder up front. Architectural Record's publication guidance is stricter still on caption discipline and exclusivity. The common thread: the architect, the photographer, and the copyright holder must be unambiguous on every frame.

The second is location. A default map pin is frequently wrong by enough to matter. Google's Geocoding documentation classifies a result's precision with a location_type value, and only ROOFTOP means street-address precision; RANGE_INTERPOLATED, GEOMETRIC_CENTER, and APPROXIMATE are progressively looser guesses interpolated from roads and region centroids. OpenStreetMap's geocoder is candid about the same limit: Nominatim inherits a building's address from "the most suitable street" rather than the structure itself, and warns that without good boundary data it falls back to a nearest-match that "will often be wrong." For a building, that gap is the difference between the entrance and the block.

The third is the caption itself: wrong architect role, missing year, a room descriptor an editor cannot verify. The Architectural Photography Almanac frames consistent attribution as both a copyright-protection and a discoverability move, and notes that both the AIA and ASMP advocate for photo credit wherever the licensing agreement allows. The caption is where that attribution either holds together or falls apart.

Which IPTC and XMP fields does an editorial building photo need?¶

Here is the set, with the real property IDs. These are the fields the IPTC Photo Metadata User Guide and the current IPTC Photo Metadata Standard 2025.1 define, and the ones a submission intake reads.

Treatment	Friendly label	Property ID	Per project?
Building / headline	Headline	`photoshop:Headline` (`Iptc4xmpCore:Headline`)	Yes (typed once)
Caption	Description	`dc:description`	Yes (template per type)
Short identifier	Title	`dc:title`	Sometimes
Photographer	Creator	`dc:creator`	No (studio default)
Copyright	Copyright Notice	`dc:rights` (`xmpRights:UsageTerms` for license)	No (studio default)
City / area	Location Created	`Iptc4xmpExt:LocationCreated` then `Iptc4xmpExt:City`, `Iptc4xmpExt:Sublocation`	Yes (typed once)
Building coordinate	GPS	EXIF `GPSLatitude` / `GPSLongitude`	Yes (one pin)

A few notes on why these specific IDs:

photoshop:Headline is your building line. The IPTC guide defines Headline as "a brief synopsis or summary of the contents of the photograph," explicitly distinct from Title. For an editorial building shot, that is where the building name and architect belong, the thing an editor scans first.
dc:description is the caption battleground. IPTC 2025.1 defines Description as "a textual description, including captions, of the image." This is the field that gets your submission rejected when it is wrong, so it gets the template treatment below.
Location Created versus Location Shown. IPTC 2025.1 notes the legacy City and Sublocation fields have "blurred semantics" about whether they mean where the photo was taken or what it depicts. For architecture those are usually the same place, but the modern Iptc4xmpExt:LocationCreated structure is the unambiguous one to fill. The same Iptc4xmpExt city and country fields, applied as a bulk location keyword schema across a multi-country trip, are what make a large location archive filterable later.
GPS is technical, so it lives in EXIF. IPTC 2025.1 is explicit that the spec "does not include any technical metadata," which is why latitude and longitude write to the EXIF GPSLatitude and GPSLongitude tags rather than an IPTC field. That is the tag every catalog tool and map reads.

How do you put the GPS pin on the building, not the block?¶

This is the part most workflows skip, and it is the cheapest credibility win in the whole set.

A geocoder hands you a coordinate, but you saw the building. You know which facade you shot, which corner the entrance is on, whether the address the geocoder returned is the lobby or the loading dock. The Google location_type scale tells you when not to trust the automatic result: anything below ROOFTOP is interpolated. Nominatim's FAQ says the same in plainer terms; building positions are inherited from streets, so a tall building set back from the road can land its pin tens of meters off the actual structure.

The fix is not a better geocoder. It is dropping the pin yourself, on the facade you shot, from a satellite or map view. One coordinate, placed by the person who was standing there.

In Jade GT that is the Location tab. Open the project folder, switch to Location, and either search the address to get close or drag the pin straight onto the building face on the map. Click apply, and every selected frame gets the same GPSLatitude and GPSLongitude written into EXIF. For a single-building project that is one pin for 200 photos, placed exactly where you stood, in about thirty seconds. The same gesture works for a single-venue shoot of any kind; the building case is just the version where the precision matters to an editor.

When a project spans a campus or a streetscape and the frames were genuinely taken at different points, you record a GPX track and match by timestamp instead. That path is its own walkthrough in the geotag-without-a-tracker post. For most editorial building shoots, the single pin on the facade is the right tool.

The Jade GT GPX preview view showing a track and matched photo points, an alternative to the single building pin for campus-scale projects. — For a campus or streetscape, a GPX track per point. For one building, a single pin on the facade.

What goes in the Headline and credit fields?¶

Set these once per project and they ride every frame.

photoshop:Headline carries the building identity. A workable pattern is building name, architect, city: Reva and David Logan Center, Tod Williams Billie Tsien Architects, Chicago. That single line is what an editor reads first, and it answers the three questions a submission desk asks before it reads anything else.

dc:creator is your name, the photographer. The IPTC guide allows a company or organization name where the individual "cannot or should not be identified," but for editorial credit it should be the person who pressed the shutter. This is a studio default; you set it once and never retype it.

dc:rights is the copyright notice, the current copyright holder. If your license terms matter to the publication, the structured place for them is xmpRights:UsageTerms, separate from the copyright assertion itself. The Architectural Photography Almanac makes the practical case for keeping this consistent: an embedded, accurate copyright line strengthens an infringement claim and travels with the file wherever it gets republished.

A caution that is general information and not legal advice: crediting and licensing for architectural work involve the photographer, the architect, and sometimes the building owner, and the joint ASMP and AIA best-practices guidance is the standard reference for how those relationships usually get structured. When real money or a dispute is involved, talk to a lawyer who knows the field. The metadata's job is to make whatever you agreed to unambiguous and portable.

What is a reusable IPTC caption template by project type?¶

The caption is dc:description, and the reason it sinks submissions is that people write each one cold. A reusable system for architectural photo captions in IPTC fixes that. The structure stays constant; you swap the specifics.

The shape that maps cleanly to editorial expectations, and to the Chicago-Manual-aligned caption examples architecture libraries publish, is: building or project name, architect, year completed, location, then one clause of what the frame shows. Year and architect are the two an editor checks first; lead with them.

ResidentialCommercial / officeAdaptive reuseInterior / detail

Hillside House, [Architect Firm], completed 2024. Tucson, Arizona. View from the west courtyard toward the rammed-earth living wall at dusk.

Keep the room or vantage in the last clause. "From the west courtyard" is verifiable; "stunning interior" is not, and an editor will cut it.

[Tower Name], [Architect Firm] (architect of record: [Firm]), completed 2023. Chicago, Illinois. Double-height lobby looking north toward the curtain-wall entrance.

Commercial work is where architect-of-record matters. The AIA content style guidance is explicit that a member's role and the architect-of-record designation must be "obvious, plainly visible and legible." Name both roles when they differ.

[Project Name], adaptive reuse of the 1921 [Original Building], [Architect Firm], completed 2025. Detroit, Michigan. Original steel trusses retained above the new mezzanine.

Adaptive reuse needs two dates and sometimes two names: the original structure and the conversion. The retained-versus-new detail is exactly the context editors want and cameras cannot show.

[Project Name], [Architect Firm], 2024. Interior, [City]. Detail: blackened-steel stair stringer and white-oak treads.

Interiors live or die on material specificity. Name the materials. "Blackened steel and white oak" is a caption; "beautiful staircase" is filler.

A few rules that keep these out of the rejection pile:

Lead with architect and year. Those are the two facts an editor verifies first, and the two most submissions bury or omit.
One clause of description, not a paragraph. Hélène Binet's working method, described in her Dezeen interview, is a reminder that the strongest architectural images carry their own weight; the caption adds the facts a photograph cannot, and stops there.
Match the publication's house style. Academic and institutional desks often follow a documented style; Cornell's Architecture, Art and Planning editorial guide is a concrete model of the conventions a serious architecture desk expects.
Describe what is there, not how it feels. Materials, orientation, and structural facts survive editing. Adjectives do not.

How do you apply all of this across 200 frames in one pass?¶

Per-frame editing is the trap. A 200-frame project edited one file at a time is the afternoon that makes people skip metadata entirely. The whole point is that almost everything here is constant across the project.

The Headline, Creator, Copyright, Location Created, and the single GPS pin are identical for every frame of a single-building shoot. The only field that varies is the last clause of dc:description, and even that varies in batches: all the courtyard frames share a caption, all the lobby frames share another.

The Jade GT pass looks like this:

Drop the project folder onto the page. Nothing uploads. The files stay on your machine. (More on that below.)
Set the constants once. Creator and Copyright are already saved from last shoot. Type the Headline, the Location Created city and sublocation, and drop the GPS pin on the facade. This is the only typing that touches the whole project.
Caption in batches. Select the courtyard frames, paste the courtyard dc:description. Select the lobby frames, paste theirs. Each batch is one operation, not one-per-file.
Preview on ten frames. Before committing to 200, check the output on the first ten: Headline, caption, GPS, copyright, all visible and editable. Fix anything here, not after the run.
Run the pass. One click writes IPTC and EXIF into every frame. Import into Lightroom, Bridge, or Capture One to a set that is already submission-ready.

The Jade GT EXIF and IPTC viewer showing the written Headline, Description, Creator, Copyright, and GPS fields on a selected architectural frame. — The viewer confirming the IPTC and EXIF fields are written before the files ever leave the machine.

The benchmark for why this matters: leading editorial architectural photographers present per-project metadata, building, architect, city, and year, as a matter of course. Browse Iwan Baan's portfolio and every project carries that information cleanly. The difference between a hobby archive and a submission-ready one is whether that information lives in the file or only in your head.

One quiet note on where the files go¶

Jade GT runs entirely in your browser. Your RAWs and JPEGs never upload anywhere. The pin you drop, the caption you paste, and the IPTC and EXIF blocks Jade GT writes never leave your machine. Nothing syncs to a cloud, and nothing trains an AI on your work, because the tool cannot see your files in the first place. For commercial and editorial work under NDA, that is not a positioning argument; it is just how the tool is built.

What this is and is not¶

Two edges to know before you start

Not a catalog or an editor. Lightroom, Bridge, and Capture One still do what they do. Jade GT sits before them, in the metadata gap, and writes the fields they read.
One pin per pass. Right for a single building. For a campus or streetscape shot across many points, use a GPX track instead of one pin.

FAQ¶

Does this work with RAW files straight off the camera?

Yes. Jade GT reads and writes IPTC and EXIF directly to RAW files from every major manufacturer, including Canon CR3, Nikon NEF, Sony ARW, and Fujifilm RAF, alongside JPEG and TIFF.

Will the fields survive when I import into Lightroom or Bridge?

Yes. Jade GT writes the standard IPTC and EXIF properties: photoshop:Headline, dc:description, dc:creator, dc:rights, the Iptc4xmpExt:LocationCreated structure, and EXIF GPSLatitude / GPSLongitude. Lightroom, Bridge, and Capture One read all of them natively.

How accurate is a hand-placed pin versus a geocoder?

A hand-placed pin on the facade is as accurate as your read of the satellite view, usually within a few meters. A geocoder is only ROOFTOP-accurate some of the time and otherwise interpolates from the street, which for a set-back building can be tens of meters off.

Try it on one project¶

Pick one building shoot that you want published. Drop the folder into Jade GT, set the Headline and credit once, drop the pin on the facade, caption the frames in batches, and run the pass. The whole thing takes about as long as writing the submission email used to.

If the output is what an editor needs, your next project's metadata is already a solved problem.

Open Jade GT

Sources¶

Reply to Kenny

Questions, corrections, or a workflow story of your own? Send a note. It goes straight to my inbox.