Before you can correlate any photos with GPS data, you first have to have some photos and some GPS data. This generally involves walking/driving/going somewhere, taking photos, and taking a GPS or smartphone tracking app with you.
Just about all smartphones these days have GPS built-in and it just takes an tracking app to do the job. There are a multitude of apps for all popular smartphone platforms, including good free ones. They often store a track in GPX format that you can download to your computer and use directly. Some will upload your track to a cloud service that you can download easily from a web site.
Another option is a ruggedized standalone GPS unit. Most of these have a "tracklog" facility that record where you have been. The resolution of these tracks is widely variable - my old Garmin eTrex GPS records up to 1600 data points, at around 20 metres between each point. This works out to travelling about 500 kilometres (by car) or 50 kilometres (on foot) before you run out of memory. (These numbers vary very much depending on many factors.)
Other GPS devices will vary in their capacity. If you are using a GPS device made only for a computer, or have attached your GPS device to a computer, you may wish to log the data on the computer. In this case, you will probably end up logging the one second fixes, which results in a fair bit of data (nothing excessive), but very accurate results.
As to taking the photos? Not too many digital cameras add GPS data to the photos themselves - although they do exist. If you have one, then you don't need this program!
Besides that, take photos as you normally would. The correlation program matches photos to GPS data by their timestamp, so it would be a good idea to synchronise the cameras time to the time from the GPS before you start taking photos. (Not the other way around: the GPS gets its time from the satellites, which means that it is probably correct... and most GPSs will not allow you to set their time, anyway).
The photos will have to be tagged with "EXIF tags", which describe metadata about each photo, including the date and time it was taken. These tags are embedded in the photos themselves. That is pretty much standard for digital cameras nowadays, however, some very very very old digital cameras (like the ancient floppy-disk Sony Mavica that a family member owns) don't store EXIF tags. These will not work with this program. There are probably ways around this, though - but they are outside what I am talking about here. (Give me half a second, and I'd start talking about writing a script to grab... no, better stop there...)
When you are finished the photo shoot, download the photos as normal and get ready. Mind that any permanent rotations or editing you do do not remove the EXIF tags.
The GPS correlate program accepts GPS data in the GPX format: an open XML format. The format is quite arbitrary, and, naturally, everyone has their own GPS file format. So, in that way, this program is no exception. But, since that's the only format it supports, you'll have to arrange that your track information is made available in a GPX file.
A smartphone app might have an export or share function to create a track file. Once you do that, you attach your phone to a computer and browse to the location with the file. Or, the app might upload your tracks to a cloud service (automatically or on request). In that case, you'll need to log in to the web site on your computer and use the download function.
Exactly how you will get the GPS data from a discrete device is very much device dependant. Many devices have USB cables cables to download the data (although the USB cables are often glorified USB-to-serial converters). What format it will turn out as is also the big question. I personally recommend GPSBabel, which can convert between many formats (thus translating from whatever strange one your downloading method/program produces) and can also download from Garmin and Magellan GPS devices directly (so you can download straight to GPX and retain lots of useful metadata, like track segments).
If you logged the GPS data with a computer... well, it could be any format, depending on how it is logged. One trick would be to log the NMEA sentences as they came from the GPS directly into a file. Once the logging is done, GPSBabel can convert these NMEA sentences directly into GPX format. Usually these are one second fixes, so this would yield very good results - however, lugging around a laptop to log the data might not be convenient.
The other thing to know about GPX is that is stores data quite cleverly, separating tracks into "track segments". This can be explained quite simply with an example. When I drive through a tunnel with my GPS, it has no reception in the tunnel. My GPS records this lack of signal on the map by not showing a track between the points where I was in the tunnel. GPSBabel correctly reads this and enters this in the GPX file by separating the segments with "track segments".
Prior to version 1.1, this program ignored track segments and just hauled out points and considered them to be a single track. So if a photo was taken in between the time where there was no GPS data, you would not get a correct answer (depending on the situation). In current versions, the program will not match a photo between track segments. You can, however, choose to revert this behaviour. If the track was segmented during a period of steady, linear movement (like driving through a straight tunnel), then the interpolated position between segments will still end up being pretty accurate. Also, some apps will stop logging the position if you stay still for a while. The end of one segment will then be the same location as the beginning of the next. In those cases it makes sense to interpolate between segments.
To correlate, you need photos and GPS data. I assume the last two steps would have resulted in a series of JPEG files with EXIF tags, and a GPX file with a "tracklog" of where you have been when you took the photos.
The last thing you need to know is the timezone that the camera is set to. GPS data is always in UTC, so when we correlate the photos, we need to know how much to add or subtract to the photos time to make the photo's time UTC. Just "know" this value; there are places to enter this in in the program.
(This also assumes that the camera is set for local time where you are taking the photos. It is really arbitrary, so long as you know the difference between your camera's time and UTC. If you really wanted, just set the camera to UTC and be done with it... although that's not so friendly when you try to use the EXIF data for other things. Up to you.)
As an example, here in Perth, Western Australia, the timezone is +8:00. So that is the value that I use when correlating the photos. But since version 2.0, you usually don't need to worry about time zones. The program will automatically choose one by assuming that the camera's time is the same as the computer's time. This breaks down when you go on vacation in another time zone and change the camera's time to match, then go home and correlate your photos. You'll be using the wrong time zone offset and correlation won't work properly. Just disable automatic time zone selection in this case and give the offset yourself.
There is an option to add an offset to the photo time to make it match up with GPS data. An example case is where you forget to set the camera clock so you take a photo of your GPS screen showing the current time. You can use this to calculate the difference between the GPS' time and the photos time.
Example calculations:
GPS Time in Photo: 10:10:10 Timestamp on Photo: 10:09:30 GPS - Photo: +40 GPS Time in Photo: 10:10:10 Timestamp on Photo: 10:11:30 GPS - Photo: -80
The value determined in the above examples becomes the "Photo offset" time, in seconds, which is added to the photo's timestamp before the correlation is performed.
Time to correlate! Exactly how this is performed depends on whether or not you use the GUI version (prettier) or the command line version (scriptable).
Now there are a few options to consider when deciding how to allow the program to determine exactly the location at which the photo was taken. The program works down to the second. If you have one second GPS fixes available, then the photos will be matched exactly with a point having exactly the same timestamp. As this is the accuracy of the camera, and the accuracy of the GPS - you can not get much more accurate than this with the given equipment.
When there is less than one second data rate available, there are a few options available to make the results more accurate. By default, if the program finds photos between points, it will linearly interpolate between the points to determine the correct location of the photo.
You may not wish to allow the interpolation, for whatever reason. If you disable interpolation, then the program will instead "round" to the nearest point. That means that the photo will be set to have the location that is the recorded closest fix in time (rounding down if you manage to exactly center it).
The final major setting has many names, of which I can not decide the best one for. Sometimes I call this "feather time", and other times I call this "max distance". In any event, this setting, specified in seconds, defines the furthest time from any recorded GPS point that a photo will be matched. For example, if two GPS data points are 15 minutes apart, and you took a photo in the middle, you may not wish to match this, as the camera might well have been somewhere else. In this case, set the "max distance" to the maximum time from a recorded point that you want a photo matched. In the above example, you might set it to 60 seconds, if you know how often your GPS is likely to take another data point. Some GPS trackers stop recording location points if you stop moving, in which case you can still get accurate correlation results even with a very large "max distance".