I don't think this file has GPS data encoded in the way the standard specifies.

Basically, per http://www.exif.org/Exif2-2.PDF GPSLatitude and GPSLongitude are supposed to be a three element array with the elements being Degrees, minutes, seconds. This file just has a single rational value these two properties. It works in exiftool because exiftool is forgiving (We should also perhaps be forgiving as well). The file probably doesn't work that well in other software (Exiv2 for example says the latitude is 37769612/1000000, where most files it would format the latitude into nice 37 degrees, x', y''.)

This is a regression, previous MW versions did display the geolocation in the
EXIF for this file.

Previous Mediawiki was doing wrong things regarding GPS exif tags, that just happened to make it work for this particular case.

I also understand the EXIF standard to say that there must be three rationals.
Yet it would be nice if we could be more permissive here. ("Be liberal in what you accept...")

After all, PHP's exif_read_data *can* read this geolocation fine, otherwise even previous MW versions could not have displayed it correctly. I think exif_read_data returns either just one RATIONAL, or an array with only one element. (Don't remember which.)

The file is at least consistent, it contains

00 02 00 05 00 00 00 01 00 00 0E DF

which is "00 02"->(tag: GPSLatitude), "00 05"->(type: Rational), "00 00 00
01"->(count: 1), "00 00 0E DF"->(offset for value > 4 bytes). The value at the
offset is then "02 40 51 8C 00 0F 42 40", which is 37769612/1000000, i.e.
37.769612 degrees.

Since exif_read_data can deal with it, it'd be really nice if our Exif.php could also handle it.

I also understand the EXIF standard to say that there must be three rationals.
Yet it would be nice if we could be more permissive here. ("Be liberal in what
you accept...")

I agree that we should be liberal, I just feel it's a low priority issue since the file is not doing what the standard says (and there aren't an over-abundance of such files)