If you were unable to geocode one or more of your images from a GPS tracklog, from an imported GPX file or from an imported NMEA sentence file, this page will help you diagnose the problem and advise on what corrective actions you must take.

When the program is unable to geocode an image normally or from the nearest trackpoint, it changes the color of the 'Image' column in the main grid to bold red. If it was geocoded from the nearest trackpoint, the color is also changed to red, but with a regular font weight.

More often than not, the cause of this problem isn't simply taking a picture when the GPS wasn't recording a tracklog. It's because of circumstances that causes the program to incorrectly convert the UTC times in the GPS tracklog and/or waypoints to the local times of the photos. GPSs only know UTC time. Digital cameras (usually) only know local time. The program must do this conversion to equate the two.

Are you running the demo version?

The demo version introduces random errors in the latitude and longitude values that can cause locations to be off by as much as a kilometer.

Remedy: Upgrade the demo to registered.

Do your photos have EXIF time stamps?

A photo must have a valid EXIF time stamp in order to georeference it from a GPS tracklog or from an imported GPX file. It it has one, it'll display in the resulting list.

Remedy: Manually geocode the photos or edit the EXIF time.

What do you have specified for the UtcTimeBias option?

If UtcTimeBias is set to -1, it means the program is trying to determine the UTC bias by looking at the computer's time zone information. It could be that the camera's clock was not set to the same time zone as the computer at the time the photos were taken. If it's not set to -1, the value you have entered may be wrong.

Remedy: Change the UtcTimeBias and try again (you can do this automatically if you know the location of one of your photos).

Did you specify UtcTimeBias in minutes?

This is specified in minutes, not hours.

Remedy: Convert your number of hours to minutes.

Did you look at the imported tracklog data?

If you imported a tracklog file, the trackpoint data will be loaded in the table under the main grid's 'Tracklog' tab. Look at this data and pay special attention to the trackpoint times. Note that the trackpoint times, like the photo times, are local - not UTC. Do your photos fall within any two trackpoints within the same tracklog segment?

Remedy: If your trackpoint times are obviously wrong and need adjusting, respecify the UtcTimeBias option and import the tracklog again.

Have you patched your Windows O/S for the Daylight Savings Time bug?

If UtcTimeBias is set to -1 (the default) and if you live in the USA and if you haven't upgraded your O/S and if you try to geocode photos between March 11, 2007 and March 31, 2007, the geocoding will fail. The U.S. Energy Policy Act of 2005, passed by the U.S. Congress July, 2005, extended Daylight Saving Time (DST) in the U.S. and this change may not be known by your O/S.

Remedy: Set the UtcTimeBias preference setting to the actual difference between local time and UTC time or update your Windows O/S.

Do the photo times fall within the time frame of the tracklog?

In order to georeference a photo, its time must fall between the time of two consecutive trackpoints in a given tracklog segment. For example, if the times in your tracklog range continuously from 2pm to 4pm and if a photo's time is 1pm, you won't be able to georeference it.

Remedy: Manually geocode the photos. If the photo or trackpoint times are off by a constant and known amount, you can change the EXIF time of each image of specify a UtcTimeBias to account for the difference.

Were you recording a tracklog at the instant the photo was taken?

You can't georeference images that fall between 2 tracklog segments. For example, assume your GPS has 2 tracklog segments. The first spans from 1pm to 3pm and the other from 5pm to 7pm. An image with a time of 4pm won't be georeferenced because each tracklog segment is treated independently. Note that a Garmin GPS creates new tracklog segments under a variety of conditions like when the recording first begins, when it loses the satellite reception, when you intentionally stop and then restart the recording, when you change the GPS batteries, etc. So, if you're recording a tracklog and lose the satellite signal at 2:21pm, take a picture at 2:22pm, and then reacquire the signal at 2:23pm, that image can't be georeferenced. The thing to keep in mind is to ensure that your GPS is recording a tracklog whenever you take a picture.

Remedy: Set CombineTracklogSegments to True and try again.

Were some images georeferenced while others were not?

It's possible that the GPS unit's reception was lost at the instant you took the photo, so it fell between two tracklog segments.

Remedy: Set CombineTracklogSegments to True and try again.

Were you trying to use a saved tracklog?

When you save a tracklog in a Garmin GPS unit, the trackpoint times are lost. Because of that, you can't use a tracklog that's saved in your GPS unit to georeference images.

Remedy: Manually georeference the photos.

Was your camera's clock accurate when you took the pictures?

Before doing anything, you must ensure that your digital camera's time is accurate. You do that by setting it to the local hours and minutes that the GPS displays. Note, again, that GPSs only know UTC time and when they do anything with local time, like displaying it to a human, it's only for informational purposes. Some older GPSs don't account for daylight savings time, so the time that it displays in the summer may be an hour behind the true local time. That doesn't mean that its clock is inaccurate - it just means that it's not good at interfacing with humans. Only concern yourself with the minutes and seconds that the GPS displays.

Remedy: You need to determine what the actual offset was when you took the pictures. Specify that offset in the program options, then import the tracklog file (you can do this automatically if you know the location of one of your photos).

Was your camera's time set to the same time zone as the computer?

If UtcTimeBias is set to -1, your digital camera's time must be set to the same time zone as the computer where you'll be running the program. The accuracy of the computer's clock doesn't matter - only that it's using the same time zone as the camera. So, if you go on a trip, don't reset the camera's time to the local time of your destination. If you do, you'll have to change your computer's time zone to that of your trip destination before using the program. It doesn't matter what time zone is used, only that they are the same.

Remedy: Either temporarily change the computer's time zone settings to that of the camera or change UtcTimeBias to the proper value.

Did Daylight Savings Time Change Since the Photos were Taken?

If daylight savings time changed between the time you took the pictures and the time when the program was used to georeference them, you'll need to account for that difference by specifying an offset. The program can't automatically determine if DST is in effect at a given time because that varies throughout the world.

Remedy: Set UtcTimeBias to the time difference of when the photos were taken and try again.

Have you specified a camera offset in the program when one isn't needed?

You may have a camera offset specified when one isn't needed.

Remedy: Specify an offset that applies for the images you're trying to process. Specify 0 if the camera's time was accurate.

When you view the exported tracklog, are the UTC times obviously inaccurate?

If everything is in order, the UTC should be accurate. If not, they're probably off by a consistent amount - usually 1 hour ahead or 1 hour behind where they should be. This can happen, for example, if the camera's clock was set to a time of GMT(-5 hrs) while the computer is set to GMT(-4 hrs).

Remedy: Specify an offset that accounts for the difference.

If importing a tracklog file, does all of the required information exist?

Latitude, longitude, and timestamps must exist for each trackpoint in an imported tracklog file. Note that it's possible to export a tracklog from DNR Garmin without timestamps, so make sure you're not doing that.

Remedy: Manually edit the import file or re-export it.

Is the UseDiskDateAsTimeStamp preference set to True?

This should normally be False. When True, the program uses the image's disk date instead of the EXIF time.

Remedy: Set UseDiskDateAsTimeStamp to False and try again.

Are you trying to regeocode some photos with SkipPreviouslyGeocodedPhotos set to True?

When SkipPreviouslyGeocodedPhotos is True, previously geocoded photos are skipped.

Remedy: Set SkipPreviouslyGeocodedPhotos to False and try again.

Does your tracklog have more than 1,048,576 trackpoints?

The combined number of trackpoints in an imported tracklog file cannot exceed 1,048,576.

Remedy: Manually break the file up into smaller segments. If you need to import multiple tracklogs, import them one at a time after loading the images.

Do the GPX waypoints have timestamps?

If you're importing a GPX waypoint file, the waypoints must have timestamps and those timestamps must exist in <time> child elements. Note that some Garmin models place a timestamp in the comment field when you save a waypoint. This timestamp is for human eyes only and RoboGEO does not use it because it's prohibited by the Garmin Protocol. There are also technical reasons why it's not used, like the fact that it's not formatted as a true date and that it's written in whatever language you have configured for the unit. It may also be written in local time which makes no sense with respect to GPSs.

Remedy: Manually associate the waypoints with the photos.

Do the appropriate NMEA sentences exist in the import file?

If you're importing a NMEA sentence file, note that the program obtains location data from the sentence that begins with $GPRMC. Without that sentence, the program cannot geocode the images.

Remedy: Manually geocode the images.

Do you have the MaxTracklogTimeDifference preference option set?

This could be causing the problem if the time difference between the geocoded photo and the nearest trackpoint exceeds the value that you specified.

Remedy: Increase the MaxTracklogTimeDifference value or set it back to the default value of -1.

Are you trying to geocode images from the IPTC headers?

It's possible that the remote server is down, that your connection to the internet is down, that your image(s) do not contain IPTC location data, that one or more of the search terms was not found (an AND operater is used in the query), that one of your search terms has a misspelling, that the country name is not spelled properly, or that there simply was no data associated with your search query.

Remedy: Perform a less restrictive search by specifing fewer search terms (like just the city) or wait until the internet connection is reestablished.

Did you import the correct Garmin TCX file?

If you're importing Garmin Training Center Database files, make sure you're importing the correct one. Import the 'activity history' files, not the 'directory files'. If you're unsure, load them into notepad.exe and look for the latitude and longitude tags - the ones that have them are the ones you need to import.

Remedy: Look at the file using notepad.exe and confirm that you're opening the correct TCX file.