GPX-based editing workflow on osm.org — feedback before creating tickets

I’ve started teaching new contributors to add new or updated trails to OSM using recorded GPX tracks and noticed friction in the web workflow. I’d like feedback before creating tickets.

Observations

  • No way to drag & drop or preview a local GPX on website without uploading it to the Public GPS traces module or opening the editor.
  • The uploaded GPS traces “View Map” link shows only a marker, not the full trace.
  • Edit button on the website is disabled at low zoom, though iD supports jumping and shows “+ Zoom in to edit” at low zoom levels.
  • Private uploaded traces made later public don’t update the public GPS Traces heatmap, while initially created public traces do.
  • Not all users want GPX data public, but some may want it displayed in the Public GPS traces heatmap for verifiability; currently, they must upload public first, then switch to private.

Typical UX current flows

Using a local GPX:

  1. Zoom in somewhere on the map to enable Edit.
  2. Open iD and drag & drop the GPX.
  3. iD zooms to show the entire trace.
  4. User must often click “Zoom in to edit” again to start editing.

Using the GPS traces module:

  1. Be aware of the GPS traces module (few users are).
  2. Upload a new GPS and select visibility (public/private).
  3. Click “Edit in map”.
  4. Zoom in to the desired area.

Both workflows involve multiple steps and context switching, making the UX confusing—especially for newcomers.

Potential improvements

  • Allow GPX preview directly via drag and drop and view in map on the website.
  • Automatically upload GPS traces with a default/preferred visibility (e.g. private).
  • Enable Edit for iD at any zoom.
  • Update GPS Traces heatmap when visibility of traces changes, so private → public traces appear automatically.
  • Add a private-but-visible option to show GPX traces in the heatmap without making the raw data public.

Ideal flow:

  1. User drags and drops a GPX file on the website, which is automatically uploaded and displayed as a preview (“View in Map”).
  2. User reviews the trace and data and decides if any edits are needed.
  3. If so, user clicks Edit, opens iD, and sees the GPX trace centered directly on the area of interest.

I’m interested in feedback and technical, historical context before I create tickets. I’ve searched through existing issues but did not find a match yet.

One thing that I would suggest is to be a bit more clear about what the goal of someone who is trying to do something is, and when you say “the website” make it exactly clear which URL you are referring to.

I’m guessing that the goal here might be “to use trace data as a source alongside imagery et al when editing OSM in the future”, but it could also be one of a number of other things.

Personally I use GPX traces both for “this is the route that I went” and “here is something I want to add/modify in OSM” (stored as a waypoint in the GPS device based on the OSM-derived map in the GPS device). The waypoints I store won’t always be “where the GPS thinks I currently am”; instead they’ll usually be added relative to other OSM data that’s already mapped (and visible on the GPS device). Your “ideal flow” wouldn’t work for me for a couple of reasons - one obvious one is “User reviews the trace and data and decides if any edits are needed”, since I always know that I’ll want to take into account other sources. Even in a completely unmapped area I’d never want to “just convert a GPS trace to an OSM way”. Another is that if I’m adding information from a GPS trace I’d always start at one end, not the middle?

1 Like

After uploading a GPS trace in iD, I start editing based on it by clicking “Edit Map” in the “My Traces” page, which leads to the map in edit mode at the beginning of the trace. The URL will then look something like OpenStreetMap and then moving the map will change the coordinates in the URL accordingly. However when I reload the page (for instance to activate the Strava heatmap overlay or after shutting down my PC and starting again the next day to continue mapping), the map doesn’t reload at the location I was mapping before, but again at the beginning of the trace. This means that I have to start looking for the location where I was mapping before the reload, which may be 100+ km away from the start of the trace. It would be nice if the page reloads at the last mapping location, just like it does when no GPS trace is being used for mapping (no gpx=* in the URL).

This thread (not related to the issue above) might also be relevant How can I search and find OSM-tracks which were published by others

1 Like

Is there a “move to location” option in iD (once the editor is already invoked)? In Potlatch (which I mostly use for this sort of thing) “load a trace” and “move to location” are independent, so that’s not a problem I’ve seen.

Josm also has “download object” which can be used in the same way.

There’s a lot to be said about some of the misconceptions in your post, but most have been already addressed.

So I’ll just weigh in on this: the “GPS layer” is an, unmaintained, third party data overlay project.

The confusion with a “core” (BTW in OSM-time terms it is has just been available since yesterday) part of the central infrastructure has more to do with that currently osm.org doesn’t have a way to select overlay/transparent layers that is consistent with regular layer selection than anything else. Regardless, opening an issue will not achieve anything in this case, volunteering to adopt the project would.

Sorry, I thought my post was clear enough :) I added “own” to clarify: “teaching new contributors to add new or updated trails to OSM using their own recorded GPX tracks.” Imagery can help during editing but isn’t relevant yet to the UX flow. The goal is to teach users how to improve trail data based on their own recordings and knowledge. Remember, they aren’t advanced users—they just only want to add missing path segments or upgrade a section to a track.

What should we call https://www.openstreetmap.org/? It’s not an editor, but it’s the main entry point for new users. Every object’s details and history link to it. “Landing page”? “Viewer”?

“Public GPS traces heatmap” is critical for verifiability and data quality, so I am really surprised this functionality is not treated as a “core” feature.

Maybe you meant “GPS trace overlay available from sidebar on osm.org in viewing mode”? Maybe you meant GPS overlay available when editing with iD? Maybe both?

Agree it can get confusing, so let’s drop the word “overlay”. I’m referring to the following:

  • GPS Traces “module”: a dedicated section on osm.org where users can upload GPX files and view their public and private traces.

  • Public GPS traces “heatmap”: an aggregated visualization of all public traces from the GPS Traces module, available as an optional layer in editors and on osm.org.

  • GPS trace “preview”: a map display of a user-uploaded or drag-and-dropped GPX file, currently available only in editors.

Ah - it wasn’t clear to me whether you meant something (but not one of the editors) below osm.org or something else entirely.

I don’t think that OSM has ever had that as a core feature, although various third party ones have been available at various times externally and in e.g. editors. The GPS map tiles at e.g. https://gps.tile.openstreetmap.org/lines/15/16269/10633.png appeared in the early 2010s or so, are largely abandoned technology and do indeed have the drawbacks that you and @SimonPoole have mentioned. I believe (though someone closer to the story might correct me) that the original implementation of these was to provide a “GPS layer” in iD.

Previously to that, other editors like Josm and Potlatch had (and still have) their own GPS viewers. Josm’s is particularly good for tracking down the source and age of GPS data, where that has been recorded. If I download GPS data in Josm around the area of that example GPS tile I see data that is not in the GPS tile.

1 Like

That’s my recollection too ~2013. In any case I don’t think there was ever any “design” behind what has ended up as the GPX-api and there are undoubtedly a number of warts, my fav is that the bounding box search requires the first waypoint to be in the bounding box.

That btw is a very bad idea.

I understand that large datasets can’t be loaded at low zoom. That said, there’s no reason to disable the Edit button for iD on osm.org—iD already handles this by not loading data and showing “+ Zoom in to edit.”