Geo-tagging - A User's Guide

[snowman1]

Geotagging in PSU has always caused me a lot of problems. This is for a variety of reasons, as will become clear (I hope). Some of these are caused by my cameras and my tracking app, but some of it is PSU; and a combination of these issues makes confusing scenarios. Having got a little way in understanding the issues I am sharing in case it is useful to others.

This should be viewed as complimentary to the PSU help document Help>quick manual – Geotagging (PDF). It tells you things that doesn’t.
If you are not having issues then that’s great - your apps are probably better than mine and you don’t need to read this. But if you are having issues, these posts may help.

For those who may be new to this, in the first post I will describe what geo-tagging is and why you may want it. Then in the next post I shall explain in detail how to geotag in PSU.

What is geo-tagging?
• Geo-tagging is the process of assigning a geographical location to an image. This location (normally) denotes where the image was taken. Whilst this can be done manually, here I am really talking about using a GPX file from a tracking app to apply a location.

How does it work?
• If the picture was taken with a smartphone or GPS-enabled camera then the data will already include the latitude and longitude (subject to your settings and to the device picking up strong enough satellite signals). The majority of “normal” cameras don’t have this capability but using PSU and a tracking app you can still geo-tag.
• A GPS “tracker” application on a smartphone or dedicated GPS device can record your location and movements over a period (based on signals received from GPS satellites).
• There are many such tracker applications / devices available, both free and paid for.
• PSU can take the file generated by the tracker application and uses the time a picture was taken to match it to the location you - and the camera - were at that time; then it writes that information to the PSU catalog and the image file (if you have PSU set to write metadata).
• There are different file formats but the one to go for is GPX format.  This is a human-readable (XML format file) consisting of a list of data points, where each point contains a time and a lat/long grid reference (and often other info such as speed or altitude). This is the only format PSU can read.
• Generally trackers take a reading every few seconds, so there are lot of data points in a typical file.

Why do this?
• It’s great to see on a map or aerial view where a picture is taken. Once a picture has location information embedded in it, software and web sites can then read and use that data. For example if you upload a picture to Flickr that has been geotagged then Flickr will display a map showing where the picture was taken. PSU has several options to view the location on a map – more of this in the next post.
• It enriches the metadata.
• It allows other people to see where the image was taken.
• I like to do it because my pictures are often taken when I’m out walking, at home or on holiday, and if I don’t geotag then after a few years I often have no idea where any particular picture was taken!
• If I am walking or skiing I like to record my track anyway, so that later I can see where I went on a map as well as other stats like distance covered, vertical drop, speed. O it’s a logical extension to geotag my pictures from the day.

What are the things to watch out for when geotagging?
• watch out for timezones, daylight saving time, and camera clock drift. This is all expained in the next post.

Can I view or edit the GPX file?
• If you want to, yes. You can simply use a text editor but there are many specialist applications that make it easier, most which will show your track on a map. I use routeconverter (http://www.routeconverter.com/downloads/en) to view and edit trackfiles but there are various websites and apps that allow viewing and/or editing of a track. (NB Because Google have started requiring credit cards to be entered, as has been discussed in these forums, Routeconverter’s development has recently been paused indefinitely and it may no longer be as good a choice as it was).

[snowman1]

This post will explain how to geotag images with PSU using GPX files, and how to avoid the “gotchas”.

I have included a glossary of abbreviations at the end.

Some context

First, some scene setting. The only reason why the process has been troublesome is quirks, bugs and features of the software and hardware involved. It should be easy, but seems to cause me issues whenever I geotag.

PSU in early versions had a number of bugs in the geotag panel. Fortunately the main ones have now been fixed, via Mantis, but some quirky behaviour remains. I have made a list of these near the end.

One of my camera bodies has a clock that runs significantly fast, and the drift can become large over time. This is one of my complications. If your camera clock is acurate, you were moving slowly, or you do not need high accuracy in your location then you will not need to worry about this and can skip all the instructions below regarding drift!

I use a tracking app called Run the Map (RTM) on a windows phone (I know, I know…) to generate my GPX files. This has a bug as I will describe below. Your tracking app may be better and that will remove another complication!

My instructions are a little lengthy because they explain how to deal with all these complications. They probably won’t all apply to you.

Lastly, I am UK based, where winter time = Universal Coordinated Time (UTC) however the instructions below should still apply regardless of your timezone.

Camera settings.

I keep my camera bodies set to UTC time permanently, no matter where I am or what the season is. In theory this should avoid a number of geotagging issues – though as we shall see, that’s not the case!

Why do I do this?
i. Because I believe it’s preferable to keep the camera on a constant time rather than risk forgetting to adjust it for daylight saving time, or for time zone when I travel. I would never know, a few months afterwards, if the camera time had been adjusted or not – or whether I’d adjusted the time half-way through a holiday! A recipe for chaos and never being able to trust your image’s timestamp.
ii. Because it’s easier - you don’t need to do anything, or remember to adjust the cam!
iii. Because it should, as mentioned, avoid complications when geotagging later.
If you choose not to keep your camera clock at UTC you will need to take this into account when calculating the offsets, a process explained below.

“Synchronising” camera time and GPX time.

Because geotagging relies on matching the image timestamp to the data points in the GPX file, the times of both need to agree with each other. Any mismatch can mean an incorrect location being assigned, or none at all.

There are three factors that could cause a mismatch.
i. Daylight saving time (DST)
ii. Time zones (TZ)
iii. Camera clock being fast or slow (I’ll refer to this as camera clock drift but can also be caused by being incorrectly set)

PSU allows you to enter an offset to compensate for these factors and to “synchronise” the image’s time to the GPX time (in fact it alters the GPX time as we shall see).

• TZ & DST offsets will – normally - be integers - whole units of hours.
• Drift offsets will be small, minutes and seconds.
• Calculate TZ & DST separately from camera drift - do not try to do both together – calculate in separate steps.

The process is:
1. Calculate the compensation – the offset - for DST and TZ, including allowances for bugs in the various software;
2. Calculate the offset for any camera clock drift. This can be regarded as optional because it may not be large enough to cause any significant error in the geotagging.
3. Apply both offsets to PSU when geotagging – see below.

Calculating Camera Drift Offsets.

• Drift offsets will be small - a matter of minutes or seconds - and unlikely to be significant unless you want high accuracy.
• Because drift offsets are small, if you don't know what the drift was at the time the picture was taken, guestimate it based on current camera clock drift or simply ignore it.
• Each camera body has a different drift, so if using more than one camera you will need to filter your images by camera body at the point when you apply the corresponding offset.
• I highly recommend taking a pic of an accurate clock – say your mobile phone clock - on each holiday or important shoot, with each camera body. (Try to catch the clock at 00 seconds - it makes life easier later!)

TZ & DST Offsets – impact of software bugs

As I keep my cameras at UTC, and the GPX file should also be in UTC (aka Z time) in theory no offset should be necessary! Unfortunately each bit of software in the chain makes assumptions that it shouldn't or has bugs or other "design features".

PSU: PSU uses the "date taken" EXIF timestamp. Unfortunately PSU automatically applies a DST offset when it comes to geotagging. It assumes that you reset your camera to summer time. It ignores TZ. As my cams are always set to UTC, this means that in summer PSU subtracts an unnecessary hour from the image time. Therefore, for my settings, in winter “PSU times” represent UTC but in summer “PSU times” represent UTC - 1h (image time and image time -1h respectively).

Tracking Apps: My tracking app RunTheMap (RTM) uses the time from the satellite signals, which are atomic clock based and supremely accurate. Now GPX files should always give times in UTC. It’s in the standards that govern GPX files. So RTM should be giving UTC times (UTC). It even has the Z suffix on times that indicate UTC. But it isn't. It's using local time for that timezone, albeit without any DST included. Therefore in winter, RTM time = local time. In summer it is local time -1h.

GPX editor/viewer apps: I use Routeconverter (RC). RC has preferences that allow it to add offsets to the times as it displays them, so what it displays may not be what is in the raw text file – so take this into account when looking at the file in RC! Other editors may do something similar.

Calculating TZ and DST offsets

The easiest way to calculate TZ/DST offset is to use UTC as a reference point for image time as calculated by PSU and GPX time as recorded by your tracker app, and see how far off UTC each side is.

• Calculate how much off from UTC the PSU time is. As discussed above, because I keep my cams on UTC this will be 0 in winter and -1 in summer.
• If you are unsure whether PSU is applying a correction, there is one great trick for finding out. Using the geotag panel, open a GPX file – any file. For this trick we want the file to NOT include the time the image was taken. If it does, apply an offset of a year in PSU to ensure it won’t. Now select a single image and click the GPX point button. You will get an error message saying PSU cannot find that image in the file - the error message will contain the image time PSU was looking for in the file. Compare the time in the error message with that in the timestamps to see if they are the same.
• Calculate how much off from UTC the GPX times are. As discussed above, with a GPX file from RTM this will equal the time difference between local time and UK time (assuming both include no or the same amount of DST)
• Use the difference between these two figures to calculate the amount of offset required to go from GPX time to PSU image time. E.g. for me, using RunTheMap:
◦ in summer in Greece, PSU is UTC-1h and RTM GPX is UTC+2h, so the offset is -3h (apply -3h to the GPX time gives you PSU time).
◦ in summer in Austria, PSU is UTC-1h and RTM GPX is UTC+1h, so the offset is -2h (apply -2h to the GPX time gives you PSU time).
◦ in winter in Austria, PSU is UTC and RTM GPX isUTC +1h, so the offset is -1h.
◦ in summer in the UK, PSU is UTC-1h and RTM GPX is UTC, so the offset is -1h.
◦ in winter in the UK, PSU is UTC and RTM GPX is UTC, so the offset is 0.

Re-dating images to compensate for camera drift

There are two ways of handling camera drift in PSU: (a) re-date the images before you geotag or (b) include the drift offset when you geotag the images. Both methods have pros and cons.

Re-dating is my preferred method. Re-dating the images means:
◦ you only have to do it once, then you can forget about it.
◦ If you redate first, you can play about with TZ/DST offsets without worrying about the minutes & seconds.
◦ If you redate, the image timestamp in EXIF will now be accurate (though remember the difference is only a matter of minutes anyway).
◦ If you include the date/time in your filenames or folder names that will no longer match the EXIF time if you redate. It could even throw the image the other side of midnight, but in practice this is unlikely to be an issue.
◦ On the downside, as you have a separate re-date step and geotag step the process will take a little longer
◦ IF YOU HAVE MORE THAN ONE CAMERA BODY then filter the images by camera body when first as each body will have a different drift. I tell you how to do this below.
◦ If you ever notice that an image filename time does not match its EXIF time, it probably means it's been redated!
◦ I don’t currently do this, but it may make sense to apply a time-zone (TZ) and DST correction at the same time, as it will simplify the geotagging step. Your choice.
To redate images, select them, right click > operations > redate file.

Geotagging

Now, finally, we can geotag!
• Open the Geotag panel.
• Load the required file by clicking on the GPX Track button.
• Observe that the times of the first and last data points are displayed.
• Enter an offset by clicking on the times – this opens the “correct geotimes” dialogue.
• Once an offset has been applied, this will be reflected in the times displayed.
• Always set the offset to zero before loading a new gpx file. You can also do this by exiting and re-entering the geotag panel which quits any currently loaded file and resets the offset. Otherwise PSU will incorrectly apply the last offset.
• The way PSU works is that any offset is applied to the GPX times. This may be initially counter-intuitive, as it is the times on the image that are wrong (drift) or not in UTC, but it is simpler for PSU this way.
• If the offset is correct then the GPX times will have been offset to exactly match the image time. A negative offset brings the track time backwards to match a slow camera clock. A positive offset brings the track time forward to match a fast camera clock.
• Apply the TZ/DST offset, normally a whole number of hours.
• Unless you have already redated the files, also apply the drift offset, in minutes and seconds. Remember to filter by camera body if more than one is involved. Remember -
◦ If the camera clock is fast, the offset is positive.
◦ If the camera clock is slow, the offset is negative.
• It’s perfectly ok for the hours, minutes and seconds to have any combination of positive and negative. PSU adds them together perfectly. So you can have +3h, -3m giving a total offset of +2h57m. Or -3h, +5m, -10s giving a total offset of -2:55:10
• Having entered the offset, select all the required images and click on the GPX point button. This will apply the locations to the images, for images whose times fall within the corrected range covered by the GPX file. You will see the lat and long fields will be populated and the little map will display the locations.
• Because of all the complications it is always a good idea to check the locations to make sure they are correct. In fact I often do just one image first to check all is ok. I pick an image that I know the location of, and that I wasn’t there for very long. If the map does not show the correct location then something has gone wrong!

You are done!

Optionally, having geotagged the images you can use “Reverse lookup” to set location names: select all pics, right click > operations > reverse geo lookup (for single images you can use the reverse lookup button). Note that following recent changes by Google valid API keys must be registered with Google for this to work.

How to filter images by camera body

If you need to correct for camera drift and you are using more than one camera you will need to filter by camera before applying a correction as each camera clock could be different.

If your camera bodies are the same model then I don’t know how to do this as I cannot find anyway of selecting by serial number; you might be able to do it by lens if you didn’t swap lenses.

If, like me, your bodies are different, then:
• select “details” in the list that runs along the top line of the PSU window.
• In the left hand pane expand the “technical” section.
• Expand the camera body section.
• Select the body required and drag this to the favourites section at the bottom.
• Now click on the filter button (the funnel) – it will turn blue to indicate images are being filtered.
• Click on the “filter” dropdown below and to the left of the filter button. You will now see the camera body in the list so you can filter on it.

Quirks and bugs in PSU geotagging behaviour; and other misc notes

• Reverse lookup button only works on one image at a time. Hert has stated this is intentional, but I believe it to be counter-intuitive and unnecessary. To reverse lookup multiple images, select them, right-click > operations > geo reverse lookup.
• The validate button on the offset dialogue seems to serve no purpose.
• The GPX point button’s design and tooltip imply one can hold the button down for a combined find and reverse lookup. Holding the button down has never worked for me.
• The apply button on the geotag panel seems redundant for most operations, which are automatically written to the catalog.
• Although I have trawled the exif , I still do not understand how PSU decides when to apply an automatic DST offset to an image’s timestamp. Perhaps the camera applies a timezone that I cannot see but PSU does. Perhaps I simply don’t understand the subtleties.
• I don’t think PSU should apply ANY DST correction. It is assuming that the camera time has been adjusted for DST. It should not make such assumptions.
• PSU does not cancel any offset when a new GPX file is opened. This can lead to the offset being double-applied. This is a bug.
• There seems to be a quirk in the timestamps displayed on the details panel – or again perhaps I simply don’t understand the subtleties. In the details panel there is a dropdown on the right hand end of each timestamp field. Clicking this dropdown, if PSU is applying its automatic correction for DST, this will display “GMT +01:00”. So far so good. But when no DST correction is being applied, a small-font “-02” is shown (without minutes). In the latter case I don’t understand what the -02 signifies, nor why no minutes are shown.
• There are several ways of displaying an image’’s location on a map and they have slightly different outcomes.
-- The location is automatically displayed on the little map at the top of the geotag panel with a pushpin. Pushpin only displayed for single images, multiple selections do not display a pin. You can click on the Google logo on this map - this opens Google maps in a browser window (always internet explorer )and without showing a pushpin.
-- Right-click on an image > show on map. This opens a bigger map pane in PSU; pushpins are displayed, including for multiple images. Clicking on the Google logo on this bigger map has the same effect as on the little map.
-- Click on the map button at bottom right of geopanel screen. This opens Google maps in your default browser even if this is not internet explorer. Pushpin is displayed, albeit only for single images. This is possibly the most useful option.
• A little off topic but note that if a location – a lat and long reference – is copied from a browser, including from bing maps and google maps, it can be pasted onto an image in PSU by clicking the paste button on the geotag panel. This can be very useful when setting locations manually.
• Also worth noting is a detail about how a location is assigned. When taking pictures with a mobile phone, if the phone cannot pick up a good GPS satellite signal then it may use its last known position to geotag any pictures taken with it. When using PSU and a GPX file, PSU is able to go one better. If an image falls outside of the time range covered by the GPX file then no location is applied to the image by PSU. If an image falls between two data points in the GPX file, PSU will assign a position based on where where the image is, timewise, between the points. So if GPX data point 1 is timed at 12:00:00 at location A, and data point 2 is 12:00:45 at location B, an image taken at 12:00:30 will be geo-tagged at 2/3 of the way along a straight line between A and B. This normally gives excellent results for dropouts in satellite signal but once it a while it may throw up odd results and is worth being aware of (see later posts in this thread for an example).
• For any user that doesn't wish to use PSU for geotagging, free software (Windows only) called geosetter (http://www.geosetter.de/en/main-en/) can also be used to geotag images. However I'd recommend using PSU as that avoids having to import metadata added by other software.

Glossary:

DST: Daylight Saving Time. Used here to mean the offset to local time applied in summer. This is generally +1h in summer and I've assumed this in the discussion above.
Geotag: Using a GPX file to assign a location to an image (in its EXIF metadata) by matching the time of the image to the time in the GPX file.
GPS: Global Positioning Satelite (or System). In this context, the signals produced by the satelites, including a supremely accurate timestamp, that your tracking device uses to calculate its location at that time.
GPX file: A file in the GPX format: a human readable (XML type) file, that contains a list of data points that include time and location .
PSU: PhotoSupreme. Image handling software product. The software I use to geotag my images.
RC: Routeconverter: A software product for viewing and editing GPX files.
RTM: RunThe Map. The GPS tracking software I use on my phone, and which produces a GPX file I subsequently use to geotag my images.
TZ: Timezone. Used here to mean the offset required from local time to UTC (ignoring DST).
UTC: Universal Co-ordinated Time. Same as Z time. Same as GMT (i.e. local time in UK in winter).
Z time: Same as UTC. Same as GMT (i.e. local time in UK in winter).

[edited 15/2/2019 to include suggestions from Ralf, see posts below]

[Hert]

Great summary. Thank you for sharing this with the community.

[Username]

Wow. Thank you!

[Ralf]

that's great and helps a lot. Thank you for the effort.

Maybe it's interesting to mention that the cameras or mobile phones often have the following behaviors that affect a result.
If there is no SAT reception, often the last position is taken (usually with cameras or photos of mobile phones) which is stored in the photos. I often experience this in the mountains / glaciers. When tracking through a software that is rather negligible.

I often take a GPS reference photo of my phone which always has the correct time by the provider. I use that later to sync and compare with the camera clock. If the camera goes too fast or slow, I take several reference photos a day. So I almost always have the right time.
Sometimes I also use the program Geosetter in addition.

Maybe you can still use that in your guide.
greeting Ralf

[george]

Thanks to snowman1 for the terrific geo-tagging guide!

I also use the methods in Ralf's tip to sync data between my camera and mobile phone.

[snowman1]

Thanks for the kind words guys, glad it's useful.

Ralf, thanks for your input. I used to use geosetter before idimager / PSU had geo capability, excellent piece of free software. But for PSU, that was one of the best enhancements IMO - thanks Hert!

Interesting point about phones using the last position. The case with PSU and a track file is similar but slightly different: if an image falls outside of the time range covered then no position is applied. If an image falls between two data points in the GPX file, PSU will assign a position based on where where the image is, timewise, between the points. So if GPX data point 1 is timed at 12:00:00 at location A, and data point 2 is 12:00:45 at location B, an image taken at 12:00:30 will be 2/3 of the way along a straight line between A and B.

Usually this goes on in the background unnoticed, and GPX datapoints are very close together in time, but it gave me a big headache a while ago. My locations were miles from where they should have been. I was convinced either I'd got my offsets wrong or my understanding of the process was wrong after all - I was dejected!

Then I realised. My journey had included a lengthy coach journey, and as a vehicle is something of a Faraday cage, I hadn't got GPS sat signal on the journey. Fair enough. But the tracker didn't start picking up sat signals until half an hour after I'd disembarked and been walking round and taking pictures. The pictures I'd taken in that half an hour had been allocated locations along a line from the coach journey start to where reception re-started - many miles away from their true location. Pictures taken minutes apart were shown as miles apart, as PSU inferred I'd been moving at near-vehicle speed: ((journey length miles)/journeytime+30m) mph!

Happy to add this and all your other points to the instructions. So I understand correctly, when you mention taking GPS reference photos, is that the same as I had with "taking a pic of an accurate clock – say your mobile phone clock - on each holiday or important shoot", or are you doing something slightly different?

Sorry all these posts are so long - it's a difficult process to describe in a few words!

[Ralf]

that's perfectly okay with the many words;)
otherwise that's not really possible with the topic. If it helps then so much the better.

Yes, the reference photo I make of the phone clock because that compares with the providers, so an accurate clock.
On holiday I do this every day before my tours or excursions. If I'm traveling a lot I do a little break even at lunchtime or in the afternoon to avoid another shift due to slow or faster camera clocks
Ralf

[snowman1]

Cheers Ralf, I'll edit the main post accordingly.

[Mke]

Very comprehensive Snowman!

A couple of personal tips + Android apps that may be of interest:

1) I also take a reference photo of my mobile phone time (using the DigitalClock app by Light Dot Net) as the basis for time correction, but never worry about trying to hit 00 seconds. Instead, I use another app (tCalc by Sergei Munovarov) to easily calculate the time difference without errors.

2) For added accuracy, better reception and (probably) better mobile phone battery life, when on the move I normally use a separate Garmin GLO GPS (& GLONASS) receiver and link to it using the Bluetooth GPS app (from GG MobLab).

3) Route logging is done using GPSLogger by Mendhak.

[bwbecker]

Hi -- Just downloaded Photo Supreme to evaluate and was surprised that I need a Google API key to enable geotagging -- and that there is a cost. Can anyone provide estimates on the cost for personal use?

[jtk]

Thank you, snowman, for your informations.

Allow me to add my method: I use GPS4CAM. This app runs on a iPhone (AFAIK a Android version exists) and traces the way like other programs. But now comes the difference: after the photo shoot the app can give you something like a QRcode which you can photograph with all your cameras you used. The second step is to start a separate app on your Mac (Windows too) and this app analyses the photo files and the photographed barcode files, calculates the time from the photo time of the barcode and the in the QRcode embedded GPS time and uses the traced way with the calculated time difference to set the GPS data in the photo files.
One thing in snowman's info alerted me a bit, the time drift of the camera. But as I normally change the cards in the camera daily I hope that the time drift of the camera is not so much.

I hope my explanations are understandable because I'm not an native English speaker. And they may help someone.

Greetings from Germany
Thomas

[peterpix]

When I click into the GEO tag tab I get a brief glimpse of a bird's eye view of what might be New York before the map disappears and instead I get an error message: "Oops something went wrong! This page didn't load Google Maps correctly. See the JavaScript console for technical details."

Even if I knew where to find the JavaScript console I suspect that I would not know what to do with the information that it reveals. Can anyone help me with what might be happening and where to start to fix it?

EDIT: I have a Google api installed in Preferences which works for AI purposes. Also I have longitude and latitude in place for the image concerned.

Peter

[peterpix]

Fixed it by enabling the Maps Javascript api on Google Cloud.

[peterpix]

Oops, now I've tried the GEO tag lookup and I'm getting an error message: This API project is not authorised to use this API. Status: REQUEST_DENIED. I have the following apis enabled at Google: Maps Javascript, Geo-Location, GEO-coding, and Places.

Any ideas how to fix this one anyone?