(This may count as a bug, but for now I am posting it as a general post in case the fault is at my end rather than with iNat.)
When I convert my RAW files to JPG using Corel AfterShot, then upload to iNaturalist, the location is automatically detected perfectly. However, when I use FastStone to do the format conversion (which for various reasons is much more convenient for my workflow), iNaturalist picks up the location BUT it changes the latitude to north when it should be south.
Initially, I assumed FastStone was at fault. But I have been examining the metadata of the two JPGs (using ExifTool) and everything looks ok in both files. Taking one photo as an example, here is the relevant EXIF metadata from the file generated by FastStone, which causes the issue in iNat:
GPS Version ID : 2.2.0.0
GPS Latitude Ref : South
GPS Longitude Ref : East
GPS Altitude Ref : Above Sea Level
GPS Time Stamp : 09:18:23
GPS Status : Unknown ()
GPS Measure Mode : Unknown ()
GPS Dilution Of Precision : 0
GPS Altitude : 1372 m Above Sea Level
GPS Latitude : 18 deg 51' 15.00" S
GPS Longitude : 47 deg 33' 56.40" E
GPS Position : 18 deg 51' 15.00" S, 47 deg 33' 56.40" E
And here is the relevant EXIF metadata from the file generated by AfterShot, which iNat has no problems with:
GPS Version ID : 2.2.0.0
GPS Altitude Ref : Above Sea Level
GPS Time Stamp : 09:18:23
GPS Satellites : 04
GPS Status : Measurement Active
GPS Map Datum :
GPS Date Stamp : 2012:10:22
GPS Altitude : 1372 m Above Sea Level
GPS Date/Time : 2012:10:22 09:18:23Z
GPS Latitude : 18 deg 51' 15.00" S
GPS Longitude : 47 deg 33' 56.40" E
GPS Latitude Ref : South
GPS Longitude Ref : East
GPS Position : 18 deg 51' 15.00" S, 47 deg 33' 56.40" E
I canāt see anything in the first set of metadata that is wrong. Does anyone know what is causing iNat to interpret that one as being in the northern hemisphere?
Assuming this is an iNat bug, and that it wonāt be fixed immediately, what change would I have to make using ExifTool to get iNat to pick up the location correctly?
i think the system should just be using the GPS latitude and GPS latitude ref to figure the latitude coordinate. i assume that if the latitude is right except for the sign, then itās reading the GPS latitude fine, but thereās some sort of problem interpreting the GPS latitude ref. maybe the system expects an upper case S, but the file has a lower case s or something like that.
load your observation, and look at the photo page to see what it extracted in the metadata for GPS latitude and GPS latitude ref, and that will probably shed more light on the issue.
or else, if youād rather have someone else do the sleuthing, you probably need to post the actual photos to a cloud share and either point the staff to those photos in an e-mail to help@inaturalist.org or share it in a forum post.
Hi @pisum thanks for the reply. Yes, you are correct that is just the āsignā that is wrong, and manually adding a ā-ā after upload puts the point back in the correct place. As you see in my original post, the EXIF values for GPS Latitude and GPS Latitude Ref are identical in the problematic files from FastStone and the correctly working ones made by AfterShot.
I have checked the extracted metadata from iNatās end (in the photo info, as you suggested) and it looks correct. Hereās the info for a test photo from AfterShot that is correctly showing as located in Madagascar, and hereās the info for a test photo from FastStone that is wrongly showing as located in Saudi Arabia. As you can see, both of them show SOUTH in the Latitude metadata, but in the observation itself the latter gets geolocated as NORTH.
Update: I think I have confirmed the issue is with the EXIF entry for āGPS Latitude Refā. The value for this shows as South in both the good files and the bad files. However, when I use ExifTool to overwrite that line with the same value (using the ExifTool commend āexiftool -GPSLatitudeRef=S filename.jpgā) then the bad files are fixed.
Exiftool implements various internal fixes to properly display metadata across a whole range of brands and models. As a first step you should inspect the raw, unformatted values using the ā-v -nā switches.
i was thinking that iNatās photo records should show iNatās interpreted values, but both of the uploaded examples seem have āSā as the interpreted value for GPS latitude ref. but itās possible that thereās something thatās not obvious to human eyes that could still be throwing off the system ā like maybe itās actually "S " (with a trailing space) or something like that.
so maybe seeing the raw values stored in the files will shed more light in such a case.
if thereās still nothing obviously different about the raw values, then maybe the best course of action is to load the actual AfterShot- and FastStone-generated files to a cloud share and let iNat staff do some debugging on them.
ā¦ actually, itās probably a good idea to send those files to iNat staff either way. whatever FastStone is doing in this case, this is probably a case that iNat needs to handle.
Is it possible to change the format of the coordinates to decimal degrees, either in the camera or post software? Thereās generally less parsing that needs to happen and the + or - takes care of the hemisphere. More of a work-around than a fix butā¦
In camera not, unfortunately, as that opportunity has passed; this is a camera I no longer own. I have over 50,000 raw files from that camera, of which a large proportion are wildlife so Iām gradually working through to find the flora & fauna shots and upload them to iNat.
I agree with you about decimal vs deg-min-sec waypoints, though. The insistence of various mapping software to default to the latter has caused so many frustrations over the years! Especially as thereās no standard agreed way of formatting a deg-min-sec string.
Thanks everyone, helpful advice. I hadnāt used ExifTool in years so the tip about the -v -n switches was helpful. But, even with that, I canāt immediately see the issue (I see GPSLatitudeRef = S in both files with no trailing space or anything). Anyhow the ExifTool overwriting is a quick fix that sorts out my problem for now. I will do as you suggest and send a sample problem file to iNat for analysis.