Vertical Feet Skied Tracker/Estimator
Created by: Lucas Grant
Last updated:
Aggregate dated descended-vertical records or clearly labeled lift-rise proxies without claiming GPS tracking, calories or completed descents.
Vertical Feet Skied Tracker/Estimator
Snow SportsDated run groups • descended vertical or lift-rise proxy
What does this vertical feet skied tracker/estimator show?
A vertical feet skied tracker or estimator totals dated run groups by multiplying a whole completed count by average descended vertical. A separate lift-rise proxy mode is available when the corresponding descent was completed. Every record has exactly one mode so the same runs cannot be entered as both measured descent and lift proxy.
Vertical describes change in elevation, not slope length, horizontal distance, speed, effort or calories. USGS defines elevation as vertical distance relative to a datum. This calculator accepts the user’s per-run vertical value and does not inspect the accuracy, datum or sampling method behind a resort specification, map, altimeter or GPS device.
Lift rise is not automatically skiing. An upload, scenic ride, downloaded lift or lift cycle without the corresponding descent must be excluded. Even an included proxy does not prove which route was taken or whether its descended vertical exactly equals the lift rise; the mode label and notice remain attached to the result.
Dates allow daily totals inside one trip calculation. Multiple groups on the same date are added, while groups on different dates appear as separate bars. The page does not create an account, persist history, import a device track or claim leaderboard eligibility. Save exports deliberately if a durable log is wanted.
Unit switching converts every visible per-run value between international feet and meters, then clears the old result. Counts remain dimensionless whole numbers. The total is rounded only for display, preserving the same physical vertical across unit systems.
A descended-vertical record is an estimate unless measured directly. Lift rise is only a proxy when the corresponding descent was completed; exclude uploads, downloads and rides without a descent.
Method and calculation
For each included record, vertical equals completed count multiplied by average entered drop or lift rise. Excluded records contribute zero but remain visible in the details table. Trip total is the sum of included record totals.
Daily aggregation groups record totals by the exact entered date or day label. The label is not parsed into a timezone or calendar, so consistent ISO dates are recommended. Empty labels remain a poor record even though the arithmetic can still run.
Canonical calculation uses meters. International feet convert using exactly 1 foot = 0.3048 meter. No map-distance correction, slope geometry, ascent, speed, energy or calorie factor is applied.
Formula or lookup rule
record vertical = completed count × average descended vertical; trip vertical = Σ included record vertical
- Create dated run groups: Separate groups whenever date, average vertical or source mode changes.
- Choose one mode: Record descended vertical or lift-rise proxy, never both for the same runs.
- Exclude non-descents: Remove uploads, downloads and lift rides without a completed corresponding descent.
Worked examples
Five repeated descents
Five descents averaging 1,200 feet contribute 6,000 vertical feet. The result is an estimate if 1,200 is a route average rather than a direct measurement, so the record label should preserve that source.
Lift-rise proxy
Four completed cycles on a lift with 900 feet of rise contribute a 3,600-foot proxy only when each ascent had a corresponding descent. The table keeps the proxy label instead of presenting it as measured skiing.
Two dates and an exclusion
Groups sharing one date are summed into one daily bar. A download-only lift record remains visible with zero included total. The trip headline adds the two daily totals without counting the exclusion.
Practical applications
- Pre-booking comparison: Replace every example with a current checkout total and preserve its date, currency, scope and restrictions. A transparent scenario reveals missing inputs before money or time is committed.
- Group planning: Share the table with the group so day counts, cost bases, pace assumptions and exclusions can be challenged. Agreement about definitions matters as much as the arithmetic.
- Sensitivity review: Change one assumption at a time and recalculate. Comparing deliberately different scenarios is more useful than presenting one uncertain forecast as a precise promise.
- Dated trip records: Save the inputs with the output after a trip. Actual costs, times and vertical can then calibrate a future plan without silently rewriting the original assumptions.
- Boundary checks: Zero days, restricted access, missing return time and excluded records receive explicit treatment. These states stop a finite-looking number from hiding an undefined or unsupported decision.
- Handoff and review: Keep limitations and source links inside the exported result when another traveler, parent, fitter or technician will review it. Reconfirm changing external information independently.
Tips for useful results
Use the most defensible per-run source available and note whether it is a resort specification, map difference, device estimate or lift proxy. Split materially different routes instead of applying one convenient average to the entire day.
Reconcile completed counts soon after the session and exclude transport without descent. Do not interpret vertical as difficulty, quality, speed, exertion, calories or safety. Device algorithms and elevation sources can disagree, so compare repeated records only when collection methods are reasonably consistent.
Frequently asked questions
Is this vertical record a quote, guarantee or safety decision?
No. It organizes user-entered assumptions with transparent arithmetic. It does not retrieve live prices, inspect equipment, predict conditions, grant resort access, track a person or assess terrain. Confirm current terms, forecasts, measurements and local requirements with the responsible provider or qualified professional before acting. The result remains a comparison scenario even when every entered value is accurate.
Why are apparently similar inputs kept separate?
Trip days, ski days and lodging nights can differ; ticket access can vary by date; distance and gain constrain movement simultaneously; cash and net ownership costs answer different questions. Combining those concepts too early can double-charge a row or hide an unavailable denominator. Separate labels make the calculation auditable and let a reviewer identify precisely which assumption changed between scenarios.
How should I treat a zero input?
A genuine zero cost or count can be meaningful, but it must not stand in for an unknown value. The models reject invalid denominators and show unavailable metrics where appropriate. Enter zero only when the category truly contributes nothing under the declared scenario, and keep missing information unresolved until verified.
Why does changing an input clear the result?
A result must describe the values currently visible in the form. Clearing stale output prevents an old cost, time or vertical total from being exported after a price, unit, eligibility flag or record changes. Recalculate after reviewing the new assumptions, then save the complete result rather than only a headline number.
Should I round before entering a value?
Retain the best available measured or checkout value and let the display round at the end. Rounding each row before multiplication or conversion can prevent totals from reconciling and can shift an equality or break-even boundary. Keep the original source unit and definition with any value copied from another system.
Can I reuse the result next season?
Use it as a dated comparison point, not a standing answer. Prices, terms, access, equipment condition, group ability, maps and snow can change. Refresh the relevant inputs and sources, repeat measurements, and compare actual outcomes with the old scenario. A record becomes more useful when its limitations remain attached, including the original date, currency, units and scope.
Sources and references
- NIST: NIST Guide to the SI, Appendix B.8. SP 811 conversion factors. Section: Length and mass conversions. Accessed 2026-09-08. 1 inch = 2.54 cm; 1 pound = 0.45359237 kg.
- U.S. Geological Survey: Lidar Base Specification: Glossary. Current glossary inspected 2026-09-09. Section: Elevation definition. Accessed 2026-09-09. Defines elevation as vertical distance relative to a datum. The tracker uses entered descent or lift-rise values and makes no survey-accuracy claim.