GPS EXIF parsing issue

[pocketmon]

I used Robogeo to tag GPS info. to EXIF. It happened to me that gps.php get different result.
In formatGPSData(), the following seems strange.

                        $seconds = GPSRational(substr($data,0,16),$intel);

                        $minutes = GPSRational(substr($data,16,16),$intel);

                        $hour = GPSRational(substr($data,32,16),$intel);
I check EXIF v2.2 specification, the format should be
dd/1 mm/1 ss/1 or dd/1 mmmm/100 0/1
.

If the code follow the specifcation, it means that "hour" should be the first one element.
The most strange thing for me, is that I get inconsistent result.

I use Robogeo for both file, but it seems that Robogeo use the format dd/1 mmmm/100 0/1.
However, using gps.php, the first file will get
$second = 0/1
$minute = mmmm/100
$hour = dd/1

while the second file, the result will be
$second = dd/1
$minute = mmmm/100
$hour = 0/1
.

I have no idea about it. I check the EXIF information with exifv, and found no difference for those two files. Maybe somebody can solve it

[DJMaze]

Issue is Big Endian vs Little Endian encoding.

Exif data is always in one endianness but, some software systems screw this up (even camera's) and then the mess starts.
Could you post BOTH images (or look for yourself using a Hex editor)
So there can be checked if the Exif header contains 'MM' (Motorola Big Endian) or 'II' (Intel Little Endian)

If you want to know the difference: http://en.wikipedia.org/wiki/Endianness

[edit]
Never mind, i see you attached 2 images.

So i took a peek and indeed: one file is MM and the other II.
Solution: Get other software because Robogeo has a bug for not maintaining Endian byte order.
[/edit]

[edit2]
Nope, it wasn't a bug in Robogeo.
My parser had an issue with II files and reversing rational values.
So it seems a bug in Exifer
[/edit2]