It’s relatively common for various national and regional GNSS correction networks to be referenced in a CRS other than WGS84 used in OpenStreetMap. The reason for this practice is that countries and regions use their own coordinate systems, most suitable for the territory they cover.

For example, the Oregon Real-Time GNSS Network (USA) uses NAD83 (2011) epoch 2010.00, according to their website.

It means that any RTK measurement taken while receiving NTRIP correction data from such a network will be referenced to the same CRS. That applies directly to the NMEA data output of the receiver, despite it normally being implied to be in WGS84. The majority of receivers available to amateurs are incapable of being configured to be aware of that. (The only sub-$1k receiver core I’m aware of that can “understand” the NTRIP CRS defined manually is Septentrio Mosaic.)

So, unless you perform a transformation from said CRS to WGS84, your tracks are going to be completely unsuitable for submission into the OSM public tracks database.

However, there’s a pretty straightforward way to perform the required transformation. Unfortunately, it’s “a little” longer than ideal for the exact same reason that NMEA data is implied to be in WGS84, so feeding a NMEA log directly may result in the reader ignoring the input CRS override.

The key tool for this is, coincidentally, JOSM. Here’s the workflow that functions just fine in my experience:

• Record the “raw” NMEA output log from your RTK-enabled receiver while performing the measurements.
• Load this log file into JOSM without simplification.
• Convert it into an editable layer using the context menu in the layer list.
• Optionally, “clean” the log (remove low-accuracy segments, etc.).
• Save the layer content into a GeoJSON file.
• Use a transformation tool of your choice (e.g. ogr2ogr) to perform the transformation, set GeoJSON as an output format. (I’m not going to dive into exploring the choice of tools and/or transformation parameters here.)
• Load the transformed GeoJSON back into JOSM.
• Convert it into a GPX layer.
• Export the resulting layer as a GPX file.

This entire hassle is meant to retain the additional information typically found in GPS track files. So a track point doesn’t look like a pair of coordinates, but like this:

<trkpt lat="45.35513644019843" lon="-122.60441061871428">
        <ele>54.7008</ele>
        <time>2025-11-29T21:21:56Z</time>
        <fix>rtk</fix>
        <sat>38</sat>
        <course>47.9</course>
        <hdop>0.4</hdop>
        <vdop>0.7</vdop>
        <pdop>0.8</pdop>
        <ageofdgpsdata>1.0</ageofdgpsdata>
        <dgpsid>412</dgpsid>
        <stdhdev>0.01</stdhdev>
        <stdvdev>0.022</stdvdev>
</trkpt>

The only known issue with this method is that the elevation values might not get transformed at all, depending on the transformation parameters and tools used.

For instance, if transformations are performed using ogr2ogr, for a 3D CRS, it expects a structure like this containing the Z-coordinate:

"geometry": {
	"type": "Point",
	"coordinates": [
		-122.61229189617,
		45.35316629967,
		54.7008
	]
}

It’s not going to read "gpx:ele": "54.7008" property generated by JOSM and use it.

The reverse seems to be true for JOSM when you import the transformed GeoJSON back.