Missing wiki documentation for archaeological_site=temple (385 uses)

General talk Tagging general discussion
1

While tagging some ancient temples as historic=archaeological_site + archaeological_site=temple, I noticed that archaeological_site=temple has no wiki page, despite 385 uses in the database per taginfo.

The Key:archaeological_site page lists values like cliff_dwelling (769 nodes / 3 ways), rock_painting (288 nodes / 5 ways), roman_circus (4 nodes / 18 ways), and geoglyph (6 nodes / 112 ways), all with comparable or lower usage. Meanwhile temple is absent from the taglist entirely.

There is also some overlap with two other tagging approaches for the same features:

  • historic=ruins + ruins=temple (426 uses), the generic fallback (Tag:ruins=temple wiki page exists)
  • historic=temple (214 uses), a standalone value (Tag:historic=temple wiki page exists, used e.g. on the Parthenon)

I’d like to:

  1. Create a Tag:archaeological_site=temple wiki page
  2. Add temple to the taglist on Key:archaeological_site

Before doing so, I’d appreciate community input on:

  • Is the description “The archaeological remains of an ancient temple, a structure originally built for religious worship or ritual (Greek, Roman, Egyptian, Meso-American, etc.)” reasonable?
  • What guidance should the page provide to differentiate between the three approaches:
    • historic=ruins + ruins=temple (426 uses)
    • historic=temple (214 uses)
    • historic=archaeological_site + archaeological_site=temple (385 uses)

A broader question: do we need to keep extending archaeological_site=*?

While working on the Acropolis of Rhodes, I also tagged a ruined ancient library, a gymnasium, a stadium and an odeion. This brought up a familiar problem in OSM tagging: multiple conceptual dimensions of a feature getting mixed into a single tag. For archaeological features, there are at least four dimensions at play:

  • Physical: what you see on the ground: ruins, a wall, a foundation, a reconstructed building (ruins=yes, building=*)
  • Functional: what the structure originally was or is used for: a temple, a library, a theatre (amenity=*, leisure=*)
  • Classification: what category it belongs to: archaeological site, heritage site (historic=*, heritage=*)
  • Lifecycle: what state it’s in: active, disused, abandoned, ruined (disused:, ruins:, was:)

For living features these dimensions merge naturally: a functioning library is both a building and a library. For archaeological remains, however, they split apart.

But OSM already has a mechanism designed for exactly this situation: lifecycle prefixes, including the ruins: prefix (over 15,000 uses). Instead of inventing archaeological_site=temple, we could use was:amenity=place_of_worship for the former function and ruins:building=temple for the current physical state, reusing tags that data consumers already understand.

Looking at the current archaeological_site=* values already documented on the wiki page, several overlap with existing OSM tags:

archaeological_site value Existing OSM equivalent
church amenity=place_of_worship + building=church
amphitheatre amenity=theatre + theatre:type=amphi
baths amenity=public_bath
city place=city
settlement place=*
roman_circus leisure=stadium (hippodrome)
roman_villa building=villa
tomb tomb=*

And the values we’d need to add for the features at the Acropolis of Rhodes would extend this overlap further:

Proposed archaeological_site value Existing OSM equivalent
temple amenity=place_of_worship + building=temple
stadium leisure=stadium + building=stadium
library amenity=library + building=civic
theatre (odeion) amenity=theatre + theatre:type=odeon

All of these could be expressed with lifecycle prefixes. Instead of:

historic=archaeological_site
archaeological_site=church

we could use:

historic=archaeological_site
was:amenity=place_of_worship
ruins:building=church

This cleanly separates the layers: historic=archaeological_site classifies the site as archaeologically significant, was:amenity=place_of_worship captures the former function, and ruins:building=church captures the current physical state. No need for archaeological_site=church at all.

Meanwhile, many values have no modern equivalent and genuinely belong in archaeological_site=*:

cairn, cliff_dwelling, crannog, earthwork, enclosure, geoglyph, grave_field, hut_circle, megalith, necropolis, petroglyph, rock_painting, trap_pit, tumulus

So should we:

  • Keep extending archaeological_site=* with values like temple, library, gymnasium, duplicating concepts that already exist in OSM’s tagging?
  • Or prefer lifecycle prefixes (e.g. was:amenity=place_of_worship, ruins:building=temple) for structures whose original function maps cleanly to an existing tag, and reserve archaeological_site=* for genuinely unique archaeological feature types?

An even broader question: do we need to keep extending historic=*?

The historic=* key itself has the same pattern: values like church, temple, monastery, farm, house, warehouse duplicate concepts already expressed by building=* and amenity=*. If lifecycle prefixes carry the “what it was” and “what state it’s in” information, then historic=* wouldn’t need to repeat the feature type at all. A simple historic=yes would suffice to flag historical significance. But that’s a much larger discussion.

I’d love to hear the community’s thoughts on this.

2

The definition would exclude standing remains, i.e. temples that could be still in use, either as places of worship or repurposed, is it intentional? I have always seen archaeological site as a very broad term that can be applied to all historic sites.

Historic=temple could be more suitable for a temple that is still standing, but I wouldn’t be surprised to find the tag also applied to just a pile of stones.

1 Like
3

@dieterdreist Thanks for the feedback. You’re right that the original description would exclude standing temples. I’ve updated the OP to: “The remains or site of an ancient temple, a structure originally built for religious worship or ritual (Greek, Roman, Egyptian, Meso-American, etc.), in various degrees of preservation.”

As for historic=temple (214 uses) vs archaeological_site=temple (385 uses), I couldn’t just pick one of the two existing approaches like a normal person. Instead, being a proper OSM mapper, I naturally proposed a third way using lifecycle prefixes :) See the extended discussion in the OP.

That said, the lifecycle prefix approach is more of a theoretical question for the community. Practically, I think we still may need the archaeological_site=temple wiki page regardless of which direction the community prefers long-term.

4

Let’s see. The archaeological_site key is supported as a project by lots of projects, was:amenity by 2 and ruins:building by 4.

Ignore the wiki page. It is just a laundry list of “some values” (the 5th most used value isn’t listed). Look instead at how this key is used in combination with others already.

If you want to start mapping new archaeological sites that you find with was:key=value and ruins:key=value you are entirely free to do so, but please don’t break the data for everyone else. Near me nwr["historic"="archaeological_site"]["was:amenity"]; finds one in Ireland and nwr["historic"="archaeological_site"]["ruins:building"]; also finds one, also in Ireland.

1 Like