Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

GPS-tracks timezone bug workaround?

Hi,

I know that AP does not respect the daylight saving time offset. The problem seems to be a bit more complicated. When I go to the "edit track timezone" menu the default is set to "Africa/Cueta". This one isn't even in its own list, nor in the preferences: where did that come from? Ok, then I choose "Amsterdam (GMT+2)", which results in GMT+1. So the menu still knows all about DST, it just ignores it later-on. Only after selecting GMT+2 for the timezone directly will the track show the correct times along the segments, and can the photos be assigned.

Now the weird thing is that after quitting and restarting AP the timezone of the track is back in Africa again, and the segment times are back at square one. To my relieve, the photos stay put, but my fear is that this might be "fixed" in the future, or after a rebuild or restore of the database.

Is there a way to freeze the GPS location in the masters from within AP, so as to be independent from future improvements?

I like the UI and the ability to visually compensate for the time difference between the camera and the GPS. Also, I prefer to import directly into AP and not through some third party program (definitely not a Garmin program). Has someone found a workaround from within Aperture? Or is there a track file format that allows local time (instead of GMT), and would that trick AP?

By the way, has anyone found a way to let AP read the elevation data? It does not work from a GPX file, but maybe a different track file format?

Mac Pro (1,1) 4 x 2.66GHz 12GB HD4870, Macbook Pro 15" 2.8Ghz 4GB, Mac OS X (10.6.3)

Posted on May 17, 2010 5:35 AM

Reply
5 replies

May 26, 2010 5:41 AM in response to MacRicco

I'm just importing my first large dataset since daylight savings came into effect and running across the same problems. I need to experiment more to figure out how to get Aperture to place my photos on the correct spots on the track. Overall, Aperture's handling of time offsets is pretty horrid. I usually keep my camera set to local time when I travel. But when I come home, I need to remember to change the time zone on my computer to the time zone I was in at the time the photo was taken. Otherwise, the time on my photos is screwed up no matter what options I've set on the import settings.

Anyway, just replying to your message to say that Aperture also ignores altitude data in a NMEA track file. I suspect it just always ignores it, and there is no way to add it. At least other tools that ignored the altitude data in track logs gave you the option of looking it up on Google maps. Not perfect, but better that nothing.

Aug 22, 2010 6:46 AM in response to Bean

There is a neat work-around to both of these problems (time zone and altitude). Go to

http://www.ubermind.com/products/maperture.php

and download Maperture, the free add-on that works within Aperture. It allows one to match the photo timestamps with imported tracks without errors related to DST, etc. AND will also automatically fetch the altitude information from Google maps.

I initially began using it because it places the location/altitude information into the master file (something Aperture does not do) but now use it for photo location from tracks as well. I don't bother with the built-in Places function any more.

Hope this helps.

Cheers!

Aug 22, 2010 9:10 AM in response to MacRicco

There are a lot of things that bother me about places - this is one of them but...

To be fair the track that you are importing might not have time zones in it in the first place, I have seen this with a lot of GPS devices. I cannot explain why the set time zone is not sticky after you restart Aperture but as long as it worked and the images are placed correctly it looks like you have found "the work-around'.

For a lot of reasons I have started to merge my GPS tracks with master images prior to importing into Aperture, it is far far easier and all of the places functionality works fine.

As for maperture - arrrrrrr. don't even get me started on the woes that this has caused a lot of my friends that I had to figure out how to "fix". The issue has been that other metadata get's trampled in the process of Aperture re-reading the new GPS info from the master - this has gotten better in Aperture 3 but still has some kinks. To be blunt I personally think it is easier to merge the GPS into your masters prior to import and it gets you to the same place for free.

RB

GPS-tracks timezone bug workaround?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.