Indicates the Creative Commons Attribution 4.0 International license. lets anyone share and adapt a work for any purpose, including commercially, as long as they give appropriate credit, link to the license, and indicate if changes were made.
A list of alternate names for the climb.
When there is history, confusion, or disagreement in the community,
alternate names keep climbs discoverable and reinforce a common idea moving forward.
This issue comes up most frequently when different guides use different names
or more rarely more direct naming conflicts
(e.g.,
,
Realization vs. Biographie
Rastaman SDS vs. Lucid Dreaming
Veritas Right Project becoming Hypnotized Minds)
Examples
Valid values for a Climb's alternate_names attribute.
This indicates whether this is a known climb awaiting an ascent.
for areas where ethics support the idea of closed/reserved projects,
this should include relevant info.
it's a good idea to make the first word "open" or "closed".
null is invalid, presence of the this attribute implies project status and that status should be clarified
Examples
Valid values for a Climb's project_status attribute.
"open"
the climb is established as a project but anyone may attempt it
"closed for equipper John Smith until 2055"
recommended pattern for closed projects gives the community context to respect the reservation. It identifies who, why, and adds a limit (however distant).
"closed"
the climb hasn't been redpointed, but attempts from the community are discouraged
these are encapsulated into a single unit becausue they can't be cleanly separated. protection always depends on the style of climbing, and difficlty grading systems like the aid scales and the british adjectival grade also take protection into account Furthermore, when a certain climb is done in a different discipline, (aiding vs freeing the nose) (top roping or bouldering too big to flail) all three of these aspect tend to change together.
The GPS location for the start of climb.
In addition to the longitude and latitude (in decimal degrees),
an accuracy measure (in meters) can specify an margin of error for the coordinates
Length answers a single question about a climb:
how far does a climber travel from start to finish?
Length can be imagined as if a climber dragged a tape measure along the wall from start to finish.
This is not the height of a climb;
a 7 meter traverse that stays a few feet off the ground has a length of 7 meters.
this respresents the steepness of the wall as the climber progresses.
this is a rough sketch of the climb and is treated stepwise.
the "from" value can be anything from 0 to 1
and each segment must be in order
this respresents the type of rock climbing as a climber progresses
the "from" value increases from 0 (the start of the climb) towards 1 (the end of the climb)
and each segment must be in order
a tag is a single word or phrase to highlight _something unique_ about the climb.
that isn't covered by other features.
In many bouldering areas, it might be worth having a `highball` tag.
In Bishop though, it might be better to have `fluttering-heart` field.
useful labels help climbers identify climbs with unique aspects.
Examples
Valid values for a Climb's tags attribute.
[
"manufactured"
]
a climb with chipping or glued-on holds
[
"area classic",
"crimpy"
]
for Slash And Burn at the New River Gorge
[
"classic",
"exposed"
]
for Zoo View at Moore's Wall in North Carolina
[
"top-out crux",
"bad fall",
"slick"
]
these imaginary tags describe an usettling problem
plain text descriptions about various aspects of the climb.
notes are divided into topics for easy organization
and simple inclusion and exclusion in different publishing formats.
Examples
Valid values for a Climb's notes attribute.
[
{
"topic": "elevator pitch",
"content": "unless you love unpleasant choss, don't climb it"
}
]
must be a terrible climb
[
{
"topic": "Elevator Pitch",
"content": "non-stop quality climbing with a stellar view and a rich history makes this one of Yosemite's greatest routes"
},
{
"topic": "FFA Story",
"content": "It was May 1975. John Bachar, John Long, and Ron Kauk were ..."
}
]
for Astroman
[
{
"topic": "Elevator Pitch",
"content": "a beautiful roof crack"
},
{
"topic": "Recognizing It",
"content": "this boulder is hard to find and looks tiny from the front ... "
}
]
Most commonly this will be a entry with the first free ascent.
Depending on the area or history, the first ascent on aid, top-rope,
lead, or any other significant first could be worth mentioning.
Noting "FA" or "FFA" is almost always redundant
and sometimes incorrect when earilier ascents are discovered.
Proper Soul, at the NRG. Note the community's progression on style, a visiting pro, and especially Jarrard's return 30 years after equipping to get an ascent. It builds a history more than giving credit or ownership.
Offers an opportunity for developers to record info about where to find further info.
Examples
Valid values for a Climb's resources attribute.
[
{
"title": "2012 Trip Report",
"resource": "https://southernsierraclimber.blogspot.com/2012/12/blog-post.html",
"description": "From Southern Sierra Climber, this offers the only well-documented ascent of this obscure route"
}
]
Potential links for the East Face Route on Moro Rock in Sequoia National Park
[
{
"title": "FA Video by Ben May",
"resource": "https://www.youtube.com/watch?v=_VtpZ9GtNP4"
},
{
"title": "Third Ascent Video by Matt",
"resource": "https://www.youtube.com/watch?v=QnYS1x9t16Y",
"description": "shows alternative, much more dynamic, beta"
}
]
A universally unique identifier.
Under nearly all circumstances, this should be autogenerated and never changed.
It can be changed to align with another catalog's UUID for the same climb.
Doing so breaks references from photos and any external tools keyed on the old value.
Update those at the same time.
GPS coordinates for the boundary of the area.
The first and last points of a polygon must be identical to form a ring (like GeoJSON and WKT).
It's recommended that the points should wind counterclockwise and the first point starts where the trail comes in.
This can help make downstream judgements about rendering.
The perimeter is a single ring. Unlike many geospatial polygon representations,
an area doesn't contain holes and is not a multi-polygon.
The Mushroom boulder (Cooper's Rock) is a good candidate for approximation because the dense tree cover makes it hard to draw an exact perimeter. This circle can guide the construction of a hierarchy, but might require manual review.
The Nautilus is a perfect use-case for a perimeter. it's oblong and easy to outline with satellite imagery. Climbs inside the polygon are undoubtedly on the Nautilus
a tag is a single word or phrase to highlight _something unique_ about the area.
that isn't covered by other features.
useful labels help climbers identify areas with unique aspects.
Examples
Valid values for an Area's tags attribute.
[
"beginner friendly",
"easy access"
]
for Sandstonia at the New River Gorge
[
"moderate access",
"good for groups"
]
this imaginary distant is less frequently traveled and has many routes close to one another
[
"frequently crowded",
"beginner friendly"
]
for The Black Corridor at Second Pullout in Red Rock
plain text descriptions about various aspects of the area.
notes are divided into topics for easy organization
and simple inclusion and exclusion in different publishing formats.
Examples
Valid values for an Area's notes attribute.
[
{
"topic": "elevator pitch",
"content": "unless you love choss and poison ivy and getting lost don't bother hiking out"
}
]
must be a terrible area
[
{
"topic": "Elevator Pitch",
"content": "an excellent winter climbing destination in North Carolina. The granite/gneiss here provides any style of climbing you could ask for"
},
{
"topic": "History",
"content": "The first routes were established in the early 1970s ..."
}
]
for Rumbling Bald in North Carolina
[
{
"topic": "Elevator Pitch",
"content": "Solid, sticky rock with all clibing over 8,000'"
},
{
"topic": "History",
"content": "Developed almost entirely by Mike and Tommy Caldwell [...]"
},
{
"topic": "Getting There",
"content": "expect many turns: from the town of Drake, [...]"
}
]
a tag is a single word or phrase to highlight _something unique_ about the photo
that isn't covered by other attributes.
tags are well-suited to a photo's purpose, condition, or capture context.
for properties that apply to most photos in a catalog and/or take a range of values,
prefer `fields`.
useful labels help authors and consumers find photos to fit a specific need.
Examples
Valid values for a Photo's tags attribute.
[
"overview",
"drone"
]
a wide shot of an area, captured from the air (important because it's a view a climber can never see)
[
"historical"
]
a photo kept for record rather than current reference, e.g., a wall before a rockfall
[
"needs-reshoot",
"low-quality"
]
a placeholder photo flagged for replacement
[
"topo"
]
this probably _shouldn't_ be used because in most catalogs, because it's the default assumption for stele1 photos
a collection of polygons that identify areas on a photo
It's suggested that the first point be on or near the access trail,
and that the points wind counterclockwise.
first and last points are be identical, enforcing a ring
Valid values for a Photo's capture_time attribute.
"2000-02-01"
a photo taken on the first day of February 2000
Context
This can be useful for in giving a hint about shade and vegitation at certain times of the day or year. Usually this can be pulled straight from the photo's metadata.
info about the parking area:
- does it close at dusk?
- are break-ins a concern?
- do you need to pay?
- is it hard to find?
- is there a towing policy?
Examples
Valid values for a Parking's description attribute.
"this is a school bus turnaround; do not use on the weekdays"
"a gravel strip on the side of the road. rarely maintained, frequently covered in trash"
The description should be a concise overview.
- is it a trail, access road, paved street, or something else?
- what quality is the trail in?
- it the trail quality unpredictable, e.g., does it wash out in heavy rain? does it get overgrown in the summer?
- other noteworthy features...
Examples
Valid values for a Trail's description attribute.
"don't even bother from May through August, the \"trail\" is just thick jungle"
machine-readable metadata for the specific stele1 catalog. Structured data describing the catalog as a whole. (follows the Metadata format)
stele1.txt
a human-oriented introduction to stele1 for someone who comes across the catalog without context. your tools should populate this with a file automatically. Add a README next to this file if you want a human-friendly intro tho the specific stele1 catalog.
climb
contains a file for each climb
climb/{climb.uuid}.json
a spec-conforming json object for a climb
area
contains a file for each area
area/{area.uuid}.json
a spec-conforming json object for an area
trail
contains a file for each trail
trail/{trail.uuid}.json
a spec-conforming json object for an trail
parking
contains a file for each parking
parking/{parking.uuid}.json
a spec-conforming json object for a parking
photo
contains a file for each photo
photo/{photo.uuid}.json
a spec-conforming json object for a photo
photo/{photo.uuid}_image.{extension}
the raw photo data. filetype (e.g., JPEG, HEIF, PNG, GIF) and extension (e.g. .JPG, .jpg, .JPEG) support are left to the implementation
extension
contains a directory for each extension used in the catalog
extension/{extension_name}
A self-contained directory for everything related to an extension. Its contents are at the discretion of the extension.
Notes on Open Text
Attributes like tags, fields, note.topic, and rating.difficulty,
don't have a spec-enforced taxonomy.
These fields are intentionally open.
Different climbing destinations have different needs,
and local authors can make better judgement calls than this spec could.
The editor's has an extension to help keep words consistent.
You can review the least used terms that appear in a catalog to catch drift.
Modeling Geometry
Geometry is modeled for each use case; this differs from what you'd get from GeoJSON.
Areas might not be possible to draw on a map cleanly, so two representations apply.
Climb location has a meter radius because it's not possible to always get perfect gps coordinates
and the climber should to know how close the gap between a specific point and what and author intended.
Parking is a specific point (no meterRadius) because it mark the last useful point for vehicle nav software.
even 10m or 100m accuracy would be fine in most cases you're setting your nav software to route to the nearest point..
Trail .path does what it needs to, point a to b.
This diverges from other standards because these are significantly better-fit for the climbing community.
Area-Climb Relationships
stele1 stores no area-climb relationships, by design.
A climb's location is a fact,
but an area is often a judgment about how to organize.
The judgment can change as developers get to know the place,
as trails are built, or as new sectors are devloped.
Recording membership directly would make every rethink a chore
and harden a catalog around its earliest, least-informed choices.
Instead, the catalog records locations and lets the map inform membership:
redraw an area, and its climbs follow.
As stele1 is a foundation for publishing, it needs to respect that
groupings change depending the publication target.
Plucking climbs from a catalog for a small best-of guide demands a
shallow hierarchy; marshalling everything for a comprehensive
guidebook benefits from intermediate areas.
There's also the technical hurdle that areas aren't always exclusive.
Suppose a canyon where the "lower canyon" is anything before the
tunnel and the "upper canyon" is everything after. It's common to
also say "middle canyon" for the rocks around the tunnel. The climbs
just past the tunnel are both upper and middle canyon — depending on
who's talking, or who's making the guidebook.
In practice, many areas
(especially in the open terrain of the western US)
work on geometry alone.
Where tree cover and continuous cliff lines make the map a weaker guide,
as across much of the east, a publication will usually want an explicit tree.
The classic-area-organization extension holds it:
geometry scaffolds a first draft, and the author massages it into finished shape:
walls are ordered for the approach,
splitting or collapsing groups to fit the guide.
The tree comes from stable facts about location and the author's judgement.
It's cheap to rebuild when the area or the publication changes.
During maintenance, an explicit hierarchy has turned out to be unnecessary:
search and a map beat clicking through breadcrumbs.
During publishing, editorial needs dictate the hierarchy's shape.
Hard-coding a canonical series of parents would be a toss-up between saving effort and costing it.
UUIDs
Use lowercase when UUIDs appear in filenames.
Coordinates
Coordinates are expressed as decimal degrees.
Assume WGS 84 (EPSG:4326) unless the catalog authors specifically state otherwise.
This is the de facto standard for consumer mapping.
GPS receivers, phones, CalTopo, and OpenStreetMap all use WGS 84.
Coordinates in stele1 use the named
{latitude, longitude} instead of an ordered pair.
Pair order is a widespread point of confusion.
stele1's format is unconfusable.
Dates
Photo's capture_time or an event in a climb History's date
are stored as a string.
For dates that software can sort and filter,
use EDTF,
an extension of ISO 8601.
Level 0 is plain ISO 8601;
Level 1 adds the coarse and uncertain forms that suit old photos and half-remembered events.
2003-04-20 is April 20, 2025
2025-03~ means around March 2025
199X means in the 1990s
1975-23 means Fall of 1975.
(21 spring, 22 summer, 23 autumn, 24 winter)
1988? means maybe 1988
Climb Length
A Climb's length gets a {lower,upper}_estimate,
and a unit.
This isn't the only choice, but it's better than its peers.
Climbers rarely (if ever) measure each climb,
so the format models the uncertainty that usually exists.
Units are included because a catalog should be able to use different units for boulders and routes.
lower_estimate and upper_estimate match how most climbers think.
We say "20 or 30 feet" instead of "25±5 feet".
(we might say "around 20 feet", but that can't be clearly modeled)
It's natural to think "I know this is over 15'", or "definitely under 100'" and modeling endpoints aligns with this relative-thinking that we're prone to.
It also happens to simplify code:
consumers don't branch on an (imaginary) exactly key before checking the upper_estimate.
Checking a catalog for climbs under 100 feet,
requires a single check of whether upper_estimate is under 100'.
It could have been specified as flexible plain text,
but the field exists to capture data, and a string gives up the re-usability of data.
A user wanting text should use a "length" or "height" as a climb.field.
Versioning
stele1 is stable. the 1 is a compatibility commitment.
The spec is firm but not frozen.
New attributes are possible but would have to clear a significant bar,
and those changes will never break existing catalogs or tools. Specifically:
Top-level attributes defined in the spec will never change shape.
climb.rating, area.location, photo.climb_layers, etc.
are permanent as specified.
Top-level attributes can be added under a compelling case.
Top-level attributes will never be deprecated.
A reader that encounters an unknown top-level attribute preserves the value verbatim on write.
Unknown nested keys
(e.g. a custom attribute inside climb.notes[x])
are out of spec and fail loudly to ensure future compatiblity;
extensions and top-level attributes are the points for growth.
A reader from 2060 loads a catalog from today.
Today's readers load 2060 catalogs without erroring; unrecognized attributes are preserved.
Extensions are not covered.
Anything under extensions/{name}/ is at the discretion of the extension's author.