Photo points do not prove a continuous route
How sparse positions, exact UTC ties and missing datum affect a GPX made from geotagged photos.
A useful photo GPX starts with a limited claim
M_K_Hubbert described wanting a GPX for a trip from photo coordinates without manually drawing a route. Anna also asked about a GPX from geotagged photos and later described restoring edited-photo GPS; she subsequently found an ART metadata setting. These accounts support the photo-position export task, without establishing browser preference or market size.
A camera records places where photos were taken. It does not necessarily record a route between them. A GPX track connects the known points, while waypoint mode leaves them as separate locations; neither inserts missing travel observations.
Exact time is useful even when order remains ambiguous
GPS UTC needs no inferred camera timezone. Sorting compares exact source nanoseconds, including a 1 ns difference around a segment threshold. Equal timestamps still do not identify which photo came first, so selection-index order is a stable convention with an ambiguity flag.
GPSDateStamp and GPSTimeStamp must explicitly provide Gregorian UTC in years 0001–9999. Hours/minutes are integers and seconds must be exact to at most 9 decimal places. No local-clock, camera-time, filename or file-time fallback; leap seconds and recurring fractions are unsupported.
| Known fact | Choice | Remaining uncertainty |
|---|---|---|
| Embedded photo positions | Track or waypoint export | The path between those positions |
| Explicit equal GPS UTC | Stable selection order with ambiguity | Actual capture order |
| Missing GPS datum | Explicit WGS84 assumption only if known | Coordinates cannot establish their own datum |
Retain provenance before sharing
Declared WGS-84/WGS84 is supported. A missing datum requires your explicit WGS84 assumption; a declared different datum is always refused. Source rational coordinates remain exact in JSON; GPX decimals truncate toward zero to 12 places. Exact +180° longitude is represented as −180° with an equivalence flag.
These are sparse photo positions, not a measured continuous route. No road matching, interpolation, geocoding or GPX elevation is added. Original altitude/ref/version and every present GPS field type, count, source span and SHA256 are retained; critical fields also have raw hex. For a GPS field with rawHex:null, read the original JPEG at the report’s absolute valueOffset for byteLength bytes; its SHA256 identifies those exact raw bytes.
The downloadable package contains original photographs and names as well as precise locations and times. Keep the package for your own audit and review which material you intend to share. Browser-local processing does not make a later shared GPX anonymous.
- Keep the original-photo ZIP for your own audit; check source indices and hashes before handing off a GPX.
- Read GPS UTC and every equal-time flag; retain the selection-order ambiguity instead of claiming a capture order.
- When rawHex is null, use valueOffset and byteLength to read the exact GPS value from the original JPEG and check its SHA256.
- Choose waypoints if connecting sparse positions would imply a path you did not measure; inspect filenames, positions and times before sharing.
A finite refusal protects the completeness promise
Baseline 8-bit SOF0 with one interleaved scan and terminal EOI; one Exif APP1 with classic little- or big-endian TIFF and GPS version 2.3/2.4. Progressive JPEG, BigTIFF, multiple-image MPF, JUMBF/APP11, XMP, trailers and unsupported structures refuse the whole queue.
Any unsupported, malformed, missing-field or over-budget photo stops the entire queue. Choose supported originals or correct the source before retrying. Cancellation discards unfinished output; rerun the same selected files.
A valid progressive photo can still be outside this profile. Refusing the whole queue makes that limitation visible; silently skipping it could make the remaining points look like the complete trip. Codec decoding and source GPS accuracy are separate checks.
References
- M_K_Hubbert — trip photos to GPX
Complete first-person request reviewed: share photo positions as a trip GPX without manually drawing a route. No original JPEGs, browser preference, region or demand volume supplied.
- Anna — GPX from geotagged photos
Her later purpose was restoring GPS to edited photos; the subsequent ART metadata-setting resolution is retained. Her original JPEG profile and GPX coverage are unknown.
- GPX 1.1 schema
Defines supported GPX output structure; schema validity does not certify a measured route or source GPS accuracy.
- CIPA Exif standards
Exif GPS field definitions and source rational values; this tool supports the declared finite GPS 2.3/2.4 profile.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
Photo GPS to GPXExport every supported local JPEG GPS position in explicit UTC order, with originals, source records and complete GPX/JSON/CSV ZIP.
Turn the embedded GPS positions in original trip photos into a sparse GPX track or waypoint set. Keep every source photo and audit exact GPS UTC ordering, equal-time ambiguity and coordinate provenance.
Steps
- Choose all original JPEG photos for the trip.
- Select track or waypoints, set the track gap threshold and confirm WGS84 only if you know the missing datum.
- Run and inspect every UTC, source index, coordinate and ambiguity row.
- Download the ZIP; open GPX in a compatible reader and use JSON plus originals to audit provenance.
Available options
- GPX output
- Sparse track · Waypoint set
- Track gap threshold (seconds)
- 3600
Split only when the adjacent UTC gap is strictly greater; unused in waypoint mode.
- I know a missing datum is WGS84
- Off by default
Only for an absent GPS datum; a declared other datum always refuses.
Capabilities and limits
- 1–500 original JPEGs, 10 MiB each and 100 MiB total. Filename labels allow up to 512 UTF-8 bytes; the operating-system file picker may impose a shorter basename limit.
- Baseline 8-bit SOF0 with one interleaved scan and terminal EOI; one Exif APP1 with classic little- or big-endian TIFF and GPS version 2.3/2.4. Progressive JPEG, BigTIFF, multiple-image MPF, JUMBF/APP11, XMP, trailers and unsupported structures refuse the whole queue.
- Per photo: at most 4096 JPEG markers, 4 IFD directories, 512 entries per directory and 1024 entries. The entire queue allows 100000 IFD entries. Unknown GPS tags, aliased/cyclic directories, overlapping structures, malformed values or required missing fields fail atomically.
- GPSDateStamp and GPSTimeStamp must explicitly provide Gregorian UTC in years 0001–9999. Hours/minutes are integers and seconds must be exact to at most 9 decimal places. No local-clock, camera-time, filename or file-time fallback; leap seconds and recurring fractions are unsupported.
- Declared WGS-84/WGS84 is supported. A missing datum requires your explicit WGS84 assumption; a declared different datum is always refused. Source rational coordinates remain exact in JSON; GPX decimals truncate toward zero to 12 places. Exact +180° longitude is represented as −180° with an equivalence flag.
- Every photo becomes one point. Exact UTC sorts the points; equal timestamps retain selection order and are marked ambiguous. Track segments split only when an adjacent time gap is strictly greater than the selected 0–86400-second threshold; waypoint mode has no track segments.
- These are sparse photo positions, not a measured continuous route. No road matching, interpolation, geocoding or GPX elevation is added. Original altitude/ref/version and every present GPS field type, count, source span and SHA256 are retained; critical fields also have raw hex. For a GPS field with rawHex:null, read the original JPEG at the report’s absolute valueOffset for byteLength bytes; its SHA256 identifies those exact raw bytes.
- The screen lists every point and copies a bounded scalar summary. Download photo-gps-package.zip for all original JPEG bytes, photo-points.gpx, complete photo-points.json and formula-safe quote-all photo-points.csv. CSV text is apostrophe-prefixed; JSON and original bytes preserve exact text.
- Protective output guards are GPX 4 MiB, JSON 8 MiB, CSV 8 MiB and stored ZIP 128 MiB; stricter input budgets dominate them. No photo is silently skipped and no partial package is returned on refusal or cancellation.
- Processing stays in this browser; no files, names or coordinates are uploaded. The parser checks bounded JPEG/Exif structure without decoding pixels or certifying source GPS accuracy, complete JPEG/Exif conformance or device compatibility.