Geotagging using GPX woes

Post Reply
Trashcanmike
Posts: 2
Joined: 04 Apr 17 0:19

Geotagging using GPX woes

Post by Trashcanmike » 04 May 17 12:59

I recently moved to PSU. I am tagging photos using an external GPX files. The results are very inconsistent. Doing them individually seems to work, once I have figured out the time offset (which is totally random as far as I can tell). I live in Australia but the images are from Indonesia (but the camera was set correctly) so there should be no offset. The times on the photos descriptions are correct.

Running the tagging in batch almost never works. I have had some success by closing the program and reopening it but as soon as the GPX is replaced it goes pear shaped again.

Any ideas folks?

Thanks

Mike

Mke
Posts: 256
Joined: 15 Jun 14 15:39

Re: Geotagging using GPX woes

Post by Mke » 04 May 17 21:05

Well I don't have problems tagging in batches myself, however I have just (again) got tangled up with the time offset myself, so I can provide some information on that part.

All GPX files record times in 'Coordinated Universal Time' (UTC) - equivalent for most purposes to Greenwich Mean Time. That's always the case, irrespective of your location or the time settings on your camera. I imagine that it uses the latitude, longitude and GPS signal to calculate the UTC, rather than calculating back from the potentially inaccurate time on your smartphone/GPX recording device.

It's then up to the software you use to calculate the local time (or not). For example:
  • On my Android device, I use GPX Viewer to view my tracks, and that automatically displays the correct local time, with a note showing the adjustment made (UTC +2 hours on my last trip).
  • Google Earth adjusts my last trip to shows the time as UTC + 1 hour (I guess they're choosing to omit the Daylight Saving Time adjustment - strange).
  • PSU doesn't make any automatic adjustment - it just uses the raw UTC value, so it's up to you to make a manual adjustment. If you click on the track's date-time in PSU, a dialog box is displayed allowing you to adjust the time - however having read this post you'll see that the explanation it gives for its necessity is misleading (I guess I should file an enhancement request in Mantis).
So for your photos from Indonesia, you'll need to make a manual adjustment of between 6 and 9 hours, depending on the time zone you were in.

Mke
Posts: 256
Joined: 15 Jun 14 15:39

Re: Geotagging using GPX woes

Post by Mke » 04 May 17 21:57

Filed feature request on Mantis at http://mantis.idimager.com/view.php?id=3162

User avatar
snowman1
Posts: 298
Joined: 01 Jan 07 3:13
Location: UK

Re: Geotagging using GPX woes

Post by snowman1 » 06 May 17 15:37

I have not encountered any issues, so I'm pretty confident it works (but see later). When you say "in batch" I assume you mean using batch processing or using the Geotag panel and selecting >1 image.

Once you have figured out the correct time offset - which I agree can be challenging - it works fine. Mke's excellent advice should set you on your way. (NB There is a bug with reverse geotagging which is discussed on another thread and has an easy workround.)

As Mke says the GPX file should contain UTC, it's explicit in the GPX format specification. Having said that I wouldn't put it past some apps to disregard the spec; but if in doubt simply open the file with a text editor like notepad and check (GPX being a human-readable format, it's basically XML).

I doubt your results are random per se, but perhaps the images have a mixture of different camera time settings. E.g. including or not including either or both of local time (i.e. correct local time for the time zone) and daylight saving times. This gives 4 different possibilities for the camera setting alone, then multiply this by the offset to where and when you are when processing the images with PSU. For example: your camera time may have included DST offset when some images were taken but not when others were taken; to complicate this further the former may include shots taken when DST was not in force - if you forgot to set the camera back - and the latter may include ones taken when DST was in force. And then when you process them with PSU some time later, you may or may not be in a DST period and notwithstanding what Mke says about PSU working in UTC the offset dialogue shows the computer time including any DST offset (being in the UK I can't tell if it includes time zone offsets too). This can be confusing if you are processing in a DST period but the pictures were taken outside a DST period or vice versa. Not to mention that the clock drift on my cameras is something awful, and I can only guess at how far it was out for a picture I took two months ago! All horribly confusing :-)

The geotag functions in PSU have had many bugs in the past - see my entries in Mantis for some of them - and I think there are still bugs. Right now my camera clock is set to GMT, but we are in British Summer Time, i.e. GMT+1 hour. On top of which my camera clock is 12 minutes fast. So at 14:00 local time, my camera reads 13:12. But if I enter this camera time into the PSU offset dialogue, it gives me an offset of +1hour and -12 minutes. In fact the offset I need is the opposite: -1 hour and +12 minutes!

In your situation it is sometimes easiest just to use trial and error - this needn't take long if done systematically.
1. Display a day's worth of shots by setting the navigator panel to "date".
2. Select one image that you know where it was taken, and preferably where you did not linger. If you know when the image was taken so much the better.
3. Open the geotag panel.
4. Load your GPX file.
5. Click on the dates which are now coloured blue and choose an offset you think is approximately correct, or just leave offset at zero.
6. Click on "GPX point" to apply geotag to the image.
7. Now use the map in the Geotag panel, or right-click the image and select "display on map". Has the geotagging placed the image before or after the spot it was actually taken? Adjust the offset by a suitable amount and repeat, using smaller changes in offset as you get closer to the correct spot. Either guess initially depending how far out it was, or start with an hour and work down to changes of 5 minutes.
8. When you get the image "in the right location", i.e. you have zeroed in on the correct offset, go ahead and geotag all of the images (and you can use the same offset for images taken the previous day or the next day etc assuming nothing changed).

Viewing the GPX file in something like Routeconverter while you do this can be helpful, as you can see when you actually were at that spot. Pictures with clocks or someone's watch in them can also be helpful, especially in assessing the amount of camera clock drift.

I leave my camera set on GMT for simplicity. That has the minor incovenience of it not being obvious what local time the shots were taken but it saves a lot of confusion and hassle; I never have to alter it apart from re-setting occasionally because of clock drift. Using local time caused me all sorts of hassle if I forgot, on holiday, to change the camera to local time until half way through the holiday, or forgot to adjust for daylight saving time on the correct date - processing the images weeks or months later was endless fun! As I am UK based and my holidays are normally in Europe the image times am never too far out from the local time they were taken, but I guess this option may be less desirable in your location.

HTH and good luck.
Snowman1
http://www.flickr.com/photos/snowman-1/
--------------------------------------

Stephen
Posts: 515
Joined: 01 Oct 14 10:15

Re: Geotagging using GPX woes

Post by Stephen » 06 May 17 19:20

You are both ahead of me because I don't use geotagging. However, as I often change time zones, the first photo I take on arrival in any new country is a shot of my wristwatch. It sometimes helps sorting things later as we usually adjust our watches sooner than the camera clock(s).
Never say never change, but using Mac since 2005. Photo Supreme 3.3.0.2589. I stand behind the interoperability of files between applications and systems.

Post Reply