fix github issue #122 - correct hemisphere on C2PA GPS longitude/latitude#135
Open
munzzyy wants to merge 1 commit into
Open
fix github issue #122 - correct hemisphere on C2PA GPS longitude/latitude#135munzzyy wants to merge 1 commit into
munzzyy wants to merge 1 commit into
Conversation
… longitude/latitude The original report was on 2.6.0-RC-2, which predates C2PAManager.kt entirely - that bug was hardcoded "N"/"W" suffixes in the old GPSTracker.getLatitudeAsDMS()/getLongitudeAsDMS() (org.witness.proofmode.c2pa package), which slapped on a fixed hemisphere letter no matter the actual sign. n8fr8's 3400860 already fixed the missing-GPS symptom from that thread; those DMS methods are unused on main now. Current main has a related but separate defect: exif:GPSLatitude and exif:GPSLongitude in the C2PA metadata assertion are written as raw signed decimal degrees (e.g. -6.148...). That's not a valid XMP GPSCoordinate - XMP has no separate ref tag like binary EXIF does, so the value has to be an unsigned "D,M.mmmmmmH" string with the hemisphere folded in. A plain signed double there leaves hemisphere interpretation up to whatever reads the field back, which is the same class of bug as the original report, just living in a different code path. Added toXmpGpsCoordinate() to build the D,M.mmmmmmH string with the correct hemisphere letter, and a JVM unit test covering the negative longitude case plus the equivalent latitude cases.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related to #122 - fixes the coordinate-format problem that's still on main after n8fr8's 3400860 (2026-06-26) fixed the missing-GPS symptom from that thread.
The reporter was on 2.6.0-RC-2, which is before
C2PAManager.ktexisted. That report traces to the oldGPSTracker.getLatitudeAsDMS()/getLongitudeAsDMS()(still in the tree underorg.witness.proofmode.c2pa, but no longer called from anywhere on main) - both hardcoded a" N"/" W"suffix regardless of the actual sign of the coordinate.What's still live on main is a different instance of the same underlying problem:
exif:GPSLatitude/exif:GPSLongitudein the C2PA metadata assertion get written as a raw signed decimal (it.longitude.toString()). Binary EXIF pairs an unsigned rational with a separateGPSLatitudeRef/GPSLongitudeReftag, but this is an XMP-style assertion and XMP has no ref tag - the hemisphere has to be encoded directly in the coordinate string asD,M.mmmmmmH(e.g.6,8.902567W). A plain signed double drops the hemisphere letter, so exiftool/the C2PA verify tool has nothing to go on for which side of the meridian or equator the point is on.The fix adds
toXmpGpsCoordinate(), which converts a signed decimal-degree value into thatD,M.mmmmmmHform and picks the hemisphere letter from the sign, then uses it for both latitude and longitude. Formatting usesLocale.USso a comma-decimal device locale can't turn6,8.902567Winto6,8,902567Wand corrupt the field.I couldn't run the Android instrumentation suite here (no device/emulator, no local JDK/Android SDK in this environment), but I added a JVM unit test (
C2PAManagerGpsCoordinateTest) that exercisestoXmpGpsCoordinate()directly - the negative-longitude case from the issue (west stays west, no leading minus sign) and the equivalent latitude cases. It lives insrc/test, same pattern asClaimBindingConformanceTest, so it runs on the JVM without a device. I checked the expected DMS values by hand before writing the assertions, but since this repo doesn't run test CI, it'd help if someone rangradlew :android-libproofmode:testDebugUnitTestlocally to confirm.