“Supports GPX and FIT” is the kind of bullet point that looks tiny on a pricing page.

In a route-planning product, it is not tiny at all.

By the time we had Trek Point handling real uploads and exports, that one feature implied:

  • file validation
  • size limits
  • parsing multiple formats with different quirks
  • coordinate chain extraction
  • activity metric derivation
  • playback data generation
  • route enrichment through external services
  • export constraints tied to both product and plan

The feature sounds like file handling. It is really a pipeline.

Import Is More Than “Can We Parse the File”

The first job is obvious: read GPX and FIT and turn them into a usable coordinate chain.

The second job is where the product value appears:

  • derive distance and duration
  • preserve timestamps where available
  • build playback-friendly track_series
  • compute start and end points
  • normalize a route representation the rest of the app can use

At that point you are no longer just accepting a file format. You are translating an external representation into your internal activity model.

That translation layer becomes a product boundary in its own right.

Good Route Products Always End Up Caring About Derived Data

A raw track is rarely enough.

Users expect more than “we stored your points.” They expect:

  • route playback
  • charts
  • distance summaries
  • meaningful previews
  • export behavior that feels consistent across imported and native data

That is why Trek Point’s processing pipeline computes secondary structures instead of leaving the file as the source of truth for every UI.

This is one of those choices that adds work early but saves pain later. If every screen has to reinterpret GPX or FIT raw data differently, the product stops being coherent.

Decimation Was Not Just an Optimization

One of the more interesting details in the code is that we decimate coordinate chains before sending them to Valhalla to derive ordered way-type segments.

You could describe that as a performance tweak. It is also a product decision.

External services have practical input limits, latency costs, and diminishing returns. We do not need every point in a dense track to classify the route meaningfully. But if we decimate too aggressively, the route loses fidelity and downstream labeling gets worse.

That tension is common in map products:

  • too much fidelity is expensive
  • too little fidelity is misleading

There is no perfect answer. There is only a product-informed threshold.

Export Adds a Second Layer of Constraints

Supporting export sounds like the inverse of import. It is not.

Now you care about:

  • output format expectations
  • coordinate count caps
  • attachment naming
  • browser download behavior
  • whether the current user is allowed to export that format at all

In Trek Point, FIT export from the planner is gated both by entitlement and by coordinate count. That is the right shape of guardrail. It protects the product from abuse and the user from asking the system to do something we know will be brittle.

Billing and File Formats End Up Intertwined

This is one of the more “real product” aspects of the implementation.

Not every export format is equal from a product perspective. GPX can be part of a free-tier experience with limits. FIT and GeoJSON are stronger signals of advanced use and can sit behind premium access.

People sometimes criticize this kind of gating as arbitrary, but it is often a good reflection of actual cost and value:

  • advanced exports attract advanced users
  • those users stress the product differently
  • those formats often require more support and correctness guarantees

The important thing is to gate capabilities consistently and transparently, not to pretend all bytes are equal.

Testing the Edge Cases Was Worth It

One of the tests I like in Trek Point verifies that GPX processing emits time_dist, because route playback depends on it. That is a perfect example of a high-value test.

It is not just checking parser output mechanically. It is protecting an actual user-visible capability.

The best tests in import/export systems are rarely “did function X return dict Y.” They are “does this uploaded artifact still support the product behavior users depend on?”

What I’d Tell Teams Building Similar Features

Do not let file-format support get trapped in a storage mindset.

Ask these questions early:

  • what is the normalized internal representation?
  • what derived data should be computed once instead of repeatedly?
  • what external enrichment is worth the latency and failure modes?
  • what are the safe limits for upload and export?
  • which tests protect product behavior, not just parser mechanics?

If you answer those well, GPX and FIT support becomes a capability. If you do not, it stays a pile of parsers.

The Lesson

Import/export features are often marketed like interoperability checkboxes. In reality they expose how mature your product model is.

Trek Point’s GPX and FIT support became valuable when we stopped thinking of the files as endpoints and started treating them as inputs and outputs of a richer route and activity pipeline.

That is the hidden complexity. The files matter, but the product meaning you derive from them matters more.