Last modified: 2012-12-01 10:23:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34410, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32410 - MediaWiki api doesn't serve EXIF GPSAltitude (and other tags) as decimals
MediaWiki api doesn't serve EXIF GPSAltitude (and other tags) as decimals
Status: NEW
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.18.x
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Bawolff (Brian Wolff)
:
: 32608 35015 (view as bug list)
Depends on:
Blocks: 37144 42164
  Show dependency treegraph
 
Reported: 2011-11-14 20:02 UTC by Neil Kandalgaonkar
Modified: 2012-12-01 10:23 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Sample API results showing rationals where decimals expected (126 bytes, text/plain)
2011-11-14 20:05 UTC, Neil Kandalgaonkar
Details
Sample API results showing rationals where decimals expected (JSON) (1.66 KB, text/plain)
2011-11-14 20:06 UTC, Neil Kandalgaonkar
Details

Description Neil Kandalgaonkar 2011-11-14 20:02:35 UTC
If you upload an image with an EXIF GPSAltitude, and then fetch imageinfo via the API, you just get the difficult-to-work-with "rational" value, such as "9395/128". Many other fields, such as FocalLength, GPSTimestamp, etc. are displayed as rationals.

However GPSLatitude and GPSLongitude are shown with the expected "decimal" values.

Example: do this API query on test.wikipedia.org. 

http://test.wikipedia.org/w/api.php?action=query&titles=File%3ATest_rationals%2Ejpg&prop=imageinfo&iiprop=metadata

A sample result is attached to this bug.

You can also import that file into your own wiki to do testing.

The Exif module that handles bitmaps seems to have the fields tagged correctly as Exif::RATIONAL, so I'm not sure exactly what is going wrong; whether it's when the file is uploaded or how we render results in the API.
Comment 1 Neil Kandalgaonkar 2011-11-14 20:05:00 UTC
Created attachment 9447 [details]
Sample API results showing rationals where decimals expected
Comment 2 Neil Kandalgaonkar 2011-11-14 20:06:28 UTC
Created attachment 9448 [details]
Sample API results showing rationals where decimals expected (JSON)
Comment 3 Bawolff (Brian Wolff) 2011-11-14 20:22:38 UTC
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 ;)
Comment 4 Raimond Spekking 2011-11-23 19:28:11 UTC
*** Bug 32608 has been marked as a duplicate of this bug. ***
Comment 5 Bawolff (Brian Wolff) 2012-03-07 03:30:27 UTC
*** Bug 35015 has been marked as a duplicate of this bug. ***
Comment 6 Bawolff (Brian Wolff) 2012-08-17 12:04:35 UTC
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).
Comment 7 Gary Houston 2012-08-22 05:32:02 UTC
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.
Comment 8 Derk-Jan Hartman 2012-08-22 09:05:07 UTC
@Gary, for the UW specific part, I filed bug 39553
Comment 9 db [inactive,noenotif] 2012-12-01 10:23:40 UTC
(In reply to comment #6)
> I submitted Gerrit change #20288 which changes the behaviour just for

Status Merged, bug maybe resolved

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links