neilk wrote:

Sample API results showing rationals where decimals expected

attachment url.txt ignored as obsolete

neilk wrote:

Sample API results showing rationals where decimals expected (JSON)

Attached:

This is the expected behaviour. (Mostly because that's the way its been forever and ever. It would perhaps make sense to convert the rationals to decimals before storing in db, or even convert it just for api output). GPSLatitude is different just because the array of three values is just plain annoying to deal with ;)

• Bug 32608 has been marked as a duplicate of this bug. ***

• Bug 35015 has been marked as a duplicate of this bug. ***

I submitted gerrit change 20288 which changes the behaviour just for GPSAltitude, since some of my other code was assuming it was a normal floating point number, which caused totally wrong displays when the altitude was below sea level.

I still feel that things which use the image metadata from MediaWiki should not make assumptions as to if the data is a rational number or a normal real number. In the future I do think it should probably be changed to convert all those fields (except maybe shutter speed) [converting them would be a mild breaking change in the api, but i doubt anyone would care]. However, even if that is done, anything using the image metadata from mediawiki would still have to support both rational numbers and normal decimal numbers, since the metadata from files stays cached for a long time (years).

ghouston wrote:

The upload wizard fails for every geocoded file that I upload, unless I manually change the Altitude field from 0/1 to 0.

This field is hidden by default in the "Add categories and more information ..." section, and if you don't open that section the upload simply fails without explaining what the problem is.

@Gary, for the UW specific part, I filed bug 39553

(In reply to comment #6)

I submitted Gerrit change #20288 which changes the behaviour just for

Status Merged, bug maybe resolved

@Bawolff, https://gerrit.wikimedia.org/r/#/c/20288/ / d1f0c5a7d8e25d378b06fb0850727a357b6b39f6 has been merged, is this bug fixed?

Honestly, I didn't really think its a bug in the first place.

Exif tags that are "rationals" according to the spec (with exception to lat/long) are still served as rational numbers afaik