IMatch 2017 Map Panel - now with Track Log Support!

[Mario]

I'm working at all ends to get IMatch 2017 "round and ready" for shipping.
One of the key features is the All New Map Panel (see related posts here: https://www.photools.com/community/index.php?board=128.0).

The new Map Panel is built using the latest OpenLayers and Google Maps versions, uses IMWS to communicate with the IMatch database and is just great. Fast, responsive, nice to look at. And it has some awesome new features that have been often requested and were now possible to do.

As a final touch, I yesterday decided to look into how hard it could be to implement an import function for GPX track log files.
After studying the official documentation, I was able to create a small JavaScript class which can import data from GPX files! This was the easy part.

My class supports track logs, routes and waypoints!
Both standard GPX and modern GPX formats are supported.
If you have track logs in other formats, there are plenty of free on-line tools which can convert them for you.

Today I've implemented the routines which can render the imported GPX data on the map to show the track log. I've also tested my import class with all track logs I have here, and some I've created on-line just for testing.

Right now I'm writing code that can figure out (by the timestamp) which images in the current scope (file window contents) match the track log and then assigns the GPS coordinates from the track log to these files. This will make it super easy to geo-code your files if you work with an external tracker. I know that this will be very welcome for many users.

One of the obstacles I had to overcome where the time formats. Sigh. Again.
GPX files use UTC timestamps - good.
But EXIF/XMP metadata may use UTC or local time zones. And different notations for the offsets. While working with sample files I have collected over time I found many different date and time formats in the metadata. Aah, that again. So I had to sit back and learn about all this, and learn about the moment.js JavaScript library written by the cool Mr. Iskren Ivov Chernev.

All this took 5 times as long as writing a JavaScript class that can import a GPX file. Figures. It always like this in programming. It's the (apparently) easy parts who take most of the time.
Anyway, I now have routines who can convert and match a wide range of different timestamp formats, and this will be used to figure out which images in the scope fall on which track point. I will look into this Monday or so.

This is how an imported GPX track looks in the IMatch 2017 Map panel:



Performance is awesome (5000 points processed in 2 seconds).

[jch2103]

As a final touch, I yesterday decided to look into how hard it could be to implement an import function for GPX track log files.
After studying the official documentation, I was able to create a small JavaScript class which can import data from GPX files! This was the easy part.

My class supports track logs, routes and waypoints!
Both standard GPX and modern GPX formats are supported.
If you have track logs in other formats, there are plenty of free on-line tools which can convert them for you.

Today I've implemented the routines which can render the imported GPX data on the map to show the track log. I've also tested my import class with all track logs I have here, and some I've created on-line just for testing.

Excellent!! This is a feature I (and I expect many others) have been waiting for. Thank you!!

[Menace]

Excellent!! This is a feature I (and I expect many others) have been waiting for. Thank you!!

+1

[pajaro]

Excellent!! This is a feature I (and I expect many others) have been waiting for. Thank you!!

+1

[Lincoln]

+!  That news just made my day!!!

[Frank]

+1 I am looking forward this release.

[Mario]

I would need some more real-life EXAMPLES.

If possible, send me (in a ZIP) a few images (5 - 10) and a matching GPX file.
You can resize the images or even black them, as long as the embedded EXIF/XMP metadata remains intact. This is needed for matching the track log.

[axel.hennig]

Hi Mario,

please find attached some *.jpg and *.gpx files. I made them a little bit more anonymous, but GeoSetter still has no problems to match every file (interpolation activated).

Hope this is what you wanted.

[Mario]

Thanks, Axel. I will check them out.

My GPS loeader handles the files well, and my code seems to match them. Need to check the details.
Why do you have so many separate GPX files? Does the tracker / software you use split each track into a separate flle? Very inconvenient. GPX files can contain any number of tracks, and IMatch handles that. I have no plans to support loading / mapping more than one file at a time. This would over-complicate things.

But if you use GeoSetter, you won't need this feature in the Map Panel anyway. GeoSetter is a much more refined software for this purpose and I do not intent to implement the same level of functionality. I will match or exceed Lr, but not GS. People seriously working with GPS data are encouraged to use GS. It's good and its free.

[axel.hennig]

Hi Mario,

Why do you have so many separate GPX files? Does the tracker / software you use split each track into a separate flle? Very inconvenient.

I used (for the first time) Geotracker (Google Play Store) for GPS-tracking. This app saves every "start tracking" -> "stop tracking" in a separate file. My "normal" GPS-tracker (not Smartphone based) saves everything in one file.

I don't think that it is necessary to load more than one gps-file. Gpx-files can be easily merged, for example with gpsbabel or with a simple text-editor.

[Mario]

Yes, GBPBabel is cool. I will only support standard GPX files and if users have one of more esoteric formats, GPBBabel will allow them to convert to GPX easily.

[Mario]

@Axel

I had problems with some of the files in your set.
My code did not match them to the track (4 out of 37).
After some analysis I found out that these files were taken before the start of the track.

For example, the file pic_28.jpg was taken about 160 seconds before the track start.
I seems GeoSetter just rolls this file forward to the start of the track and assigns the coordinates.

I'm not sure if this is the proper handling. What if the file was taken 2, 5, 20, 60 minutes before the track start?
Where to draw a border? Maybe something like a +- 5 minute grace period will be OK...

[axel.hennig]

Hi Mario,

I checked my GeoSetter settings and (I think) GeoSetter is making the following: You can configure a "Maximum Time Difference between Taken Dates and Trackpoints [seconds]" (see screenshot). This setting also holds true for the first and last record in the gpx-file.

- When I enter 158 no GPS-coordinates for pic_28.jpg are found.
- When I enter 159 (this is the time difference to the gpx-file) the GPS-coordinates for pic_28.jpg are found.

[Mario]

I thought as much. I have added a 5 minute before/after threshold and this works.

I wonder if I should make this an option.

Adobe Lr has no options at all. And there is no info about toerances they use, interpolation they perform etc. The documentation of the Lr Map panel is not very informative at all.
Still, millions of people seem to be able to work with Lr. I see a number of questions in the Lr forums, but most seem to be answered by "Did you set the time zone correctly to match your iPhone?"...

I think I will also add (silent) interpolation (If I figure out the math, that is).

Consider a file taken at 12:00:20.
The file falls between point A (12:00:00) and B (12:00:50) which have a time difference of 50 seconds and 10 meters.
Assigning point A to the file would not be correct. Same for point B.
The file should get the coordinate that matches a line between A and B, and then 20 seconds "in" that line.
I think this is what GeoSetter means with interpolation. ExifTool seems to do the same, although there is no info around.
But it makes sense to me. More precise that way.
This won't work for altitude of course. For that I can only use the median value between B.alt and A.alt.

Thank good I'm mostly shooting in the same buildings. Only a few set of coordinates, easily managed by a few map panel locations 

[axel.hennig]

I agree with the interpolation of point A and B (I think linear interpolation - easy math).

But I don't understand why you can't do the same for the altitude? Why do you have to use the median (which is for two data points the same as the arithmetic mean)?

[jch2103]

Here's a link to a set of small jpg files (exported from NEF via DxO Pro) and a GPX file for the same date: https://www.sugarsync.com/pf/D3370663_08694034_884806. These were all taken while traveling in Tasmania, Australia. I originally geocoded them with the ECP command

Code Select Expand

-overwrite_original_in_place
-geotag={File.Path}20170416.gpx
-v3
-geosync=-16:00:00
{File.FullName}

My camera was on local time (Australian Eastern Daylight Time), my laptop was still on Mountain Daylight Time.
[Note: Actually, 1. that's not the correct GPX file for these photos and 2. that ECP code was what I used in Queensland, which doesn't observe DST; therefore, the code should be corrected by an hour to reflect what I used for the Tasmania photos. As you've observed, this time zone stuff is complicated and confusing...)

For purposes of this exercise, I deleted all GPS data from the files before zipping the set.

Here's a second link to files that I had originally geocoded with ECP. (These were processed with DxO Pro from original NEF files that I had geocoded; these are the jpg exports which I then shrank via the Export module): https://www.sugarsync.com/pf/D3370663_08694034_884964

Let me know if you have questions.

[Mario]

I agree with the interpolation of point A and B (I think linear interpolation - easy math).

But I don't understand why you can't do the same for the altitude? Why do you have to use the median (which is for two data points the same as the arithmetic mean)?

You can't do it correctly.

A time diff of six minutes between two points can mean six meter altitude change or 300 meters or none, with a 100m peak in-between - depending on whether you traveled by foot, bike, motor cycle, plane or UFO (shhhh).
A is at 600m. B at 900m. Time diff 6 minutes. Image taken at 2 minutes. What would the altitude be? 700m? (900-600)/3 => alt should be 700m. But it could also be more like 1000 or 860m. It's all guess work and averaging. Or, interpolation. Besides, the math is not that simple, depending on how precise you want to be and whether or not you consider the earth a sphere or an ellipsoid. And how many points your track contains, the distance between the points, the absolute and relative distance between the clock in the camera and the clock in the tracker. In the end, it's only photos. You can always grab and shift a file marker on the map to 'correct' it. Or, do the right thing, and connect a GPS device to your camera or use a camera with a built-in GPS. Modern cameras are smart phones with better optics anyway... 

[axel.hennig]

Hi Mario,

I agree, that it can't be done correctly, but the same holds true for GPS-interpolation.

You said that you would take the median of the altitude of point A and B. This is also an interpolation, but you would omit information which you have, namely the time-difference to point A and B.

Example (not very realistic): your are making a tour to a mountain summit
- point A: time=0, altitude=5000 meter (base camp), your GPS-tracker saves this point (first point)
- point B: time=10 seconds, altitude=unknown, you take a photo (you start hiking)
- point C: time=6 hours, altitude=7000 meter (summit), your GPS-tracker saves this point (second point)

For the picture taken at point B you would use linear interpolation for the GPS coordinates. The result would be that the GPS coordinates of the picture would be much nearer to point A than to point C. But for the altitude you would use the median which would result in 6000 meter. I think much more realistic would be 5000 meter or 5010 meter or so, what would be the result with linear interpolation.

With the median you just use the altitudes, but with the linear interpolation you would use the additional information of the time (same as for the GPS coordinates).

This is all not really important to me, since I will still use GeoSetter. I just wanted to mention.

[Mario]

And GeoSetter would calculate what, for your example?

[sinus]

I agree with the interpolation of point A and B (I think linear interpolation - easy math).

But I don't understand why you can't do the same for the altitude? Why do you have to use the median (which is for two data points the same as the arithmetic mean)?

You can't do it correctly.

A time diff of six minutes between two points can mean six meter altitude change or 300 meters or none, with a 100m peak in-between - depending on whether you traveled by foot, bike, motor cycle, plane or UFO (shhhh).

Or a drone.  OK, you can see a drone as a UFO 

[Mario]

Good point.
But all non-toy drones I know of have built-in precise GPS gear anyway. They need it for tracking and positioning. So you always get GPS data with your images.
For videos, Phantom drones and similar produce SRT files (or similar), which can be uses similart to GPX files for still images.

The track log import feature is only for users who work with hand-held GPS trackers or who use a smart phone app for that purpose.

[sinus]

You are correct, Mario.

I have a Phantom, and the GPS - datas are per image and fine.

[Mario]

Can you send me a sample file (with metadata intact) for my test library?

[axel.hennig]

And GeoSetter would calculate what, for your example?

GeoSetter makes linear interpolation (see attached *.zip and screenshot).

[Mario]

I use the same algorithm I use for the lat/lon calculation also for alt. Works nicely and is fast.
The proper solution would be to lookup the point in GeoNames or Google or Bing and then use the real altitude at that point. But that's a lot more advanced, requires a Google API key or a GeoNames user name etc. Probably overkill. If somebody needs to do such things, a dedicated GIS application is better suited.

[Mario]

Here's a link to a set of small jpg files

Thanks. The GPX file loads just fine. I'm still working on the mapping right now.

This is what the ANMP (All New Map Panel) shows in IMatch 2017 when I open the configuration dialog (you also see your track on the map):

(Click to zoom)



I show the earliest and latest timestamp of the files in the current file window (these are the files that will be mapped).
When a track log has been loaded, I also show the earliest and latest timestamp in the log.
This makes it easy for the user to adjust the time zone as needed (I think).

[jch2103]

This is what the ANMP (All New Map Panel) shows in IMatch 2017 when I open the configuration dialog (you also see your track on the map):
...
I show the earliest and latest timestamp of the files in the current file window (these are the files that will be mapped).
When a track log has been loaded, I also show the earliest and latest timestamp in the log.
This makes it easy for the user to adjust the time zone as needed (I think).

For additional testing of time zones, here's a link to small jpg images and a GPX file in Colorado: https://www.sugarsync.com/pf/D3370663_08694034_897546

[lnh]

+1 GREAT DEVELOPMENT!!!

I'll send you several pictures from different brand cameras and tracks in the next several days. I use a Garmin Fenix 3 for recording tracks which only records in the Garmin .FIT format. I'll convert the .FIT files to GPX using 2 different on-line systems - Garmin Connect and SportTracks. Hopefully the GPX conversions will be consistent.

[Mario]

For additional testing of time zones, here's a link to small jpg images and a GPX file in Colorado: https://www.sugarsync.com/pf/D3370663_08694034_897546

Thanks for the additional samples.

For your first file set, I had to dial in an offset of 9 hours to match the files. The timestamps in your images contain no time zone offset so IMatch assumes them to be in the local time zone when converting them to UTC to match the time stamps in the track log (which are always UTC).

Mapping/shifting time stamps can be confusing, depending on how far the time stamps are off in the files, whatever local time zone you are in, whether or not daylight saving is in effect etc.
I tried several layouts for the settings dialog box where you can dial in the offset. I settled (for now) on this design:


The dialog pops up and analyses the files in the current scope (file window) to find the earliest and latest time stamps. It shows them in local time and UTC. It shows the date as well, because the timestamps may need shifting to the previous or next day as.

If a track log is loaded, it also analyses the track log and shows the earliest and latest timestamp in UTC.

When you change the time zone offset ("Hours") the time stamps in the Local Track display change accordingly. If you have matched the file time stamps with the track time stamps you can close the dialog and run the command that maps the files to the track. Very interactive and easy to understand I hope.

[sinus]

Can you send me a sample file (with metadata intact) for my test library?

Here is the link for 4 images from a phantom 3.
Problem is, they went trough IMatch, I do not know, if it helps you, because they are not native.
If I fine a native one, I will send it also.

http://www.sinusbild.com/holen/sinus-phantom.zip

[Mario]

Here is the link for 4 images from a phantom 3.

Thanks. Metadata and GPS are fine. Added to my sample/test library.

[Mario]

For additional testing of time zones, here's a link to small jpg images and a GPX file in Colorado: https://www.sugarsync.com/pf/D3370663_08694034_897546

This is difficult. There seem to be two sets of files in this ZIP.

Two files with dates (UTC)
2017-03-10 15:45:20 and
2017-03-10 15:58:10

the other files starting on
2017-03-11 06:38:47 (next day, 15 hours later).

The track log runs between
2017-03-11 14:12:38
2017-03-12 00:09:29

I can never match all files to the track log...?

[sinus]

Sorry for asking a stupid question.

For what is this tracking stuff? 

Say, I have an event in the mountains.
I take 50 images on different places.
Each image has its own coordinates.

Must I then have a special software to create a kind of "tracking file", so that IMatch creates a track?

And what, if the images comes from a drone with different altitude? I guess, in this case, the altitude is not viewable?

Or is is something else?
I tried to seach google, but did not find really an answer for my lacking of knowledge.

Would be nice, if someone could explain it here in simple words. 

[jch2103]

Sorry for asking a stupid question.

For what is this tracking stuff? 

If your images already have gps coordinates, you don't need any of this. The tool is for folks who have a track log from a gps (via a dedicated gpx, smartphone app, gps watch, etc.) to allow them to geocode images taken during the same time period.

[sinus]

Hi John

Thanks for your answer.
Hm, and I found this new stuff from Mario so cool! 

[Mario]

The Map Panel is cool. And you can use it for your files.

This thread was only for one of the features of the new Map Panel. The import of GPX files created by external tracker devices.
If your files already have GPS data, you don't need this.

[jch2103]

For additional testing of time zones, here's a link to small jpg images and a GPX file in Colorado: https://www.sugarsync.com/pf/D3370663_08694034_897546

This is difficult. There seem to be two sets of files in this ZIP.

Two files with dates (UTC)
2017-03-10 15:45:20 and
2017-03-10 15:58:10

the other files starting on
2017-03-11 06:38:47 (next day, 15 hours later).

The track log runs between
2017-03-11 14:12:38
2017-03-12 00:09:29

I can never match all files to the track log...?

"This is difficult." --> Indeed! The gpx track(s) were recorded with an Android app, GPSLogger (which is designed to be very battery-efficient). I started and stopped recording several times (in GeoSetter they show up as three segments). If I recall correctly, I used the ECP command

-overwrite_original_in_place
-geotag={File.Path}20170311.gpx
{File.FullName}

to successfully geocode  photos.

The photos were taken in Colorado, with camera time set to local time. The time zone is contained in the tag Nikon::WorldTime\0\TimeZone\0 as -07:00. I suspect that proprietary metadata fields probably aren't practical to incorporate into an application for a wide range of camera models (I'm not even sure Nikon uses this tag consistently across all their models).

Looking back at the photos, I recall that I didn't actually start using GPSLogger until the second day (i.e., photo _DSC3141 in your set); instead, I used the excellent IMatch Map panel to geocode the first day's photos. Which would explain why you couldn't match the first two photos to the gpx track; my apologies!

[axel.hennig]

The gpx track(s) were recorded with an Android app, GPSLogger (which is designed to be very battery-efficient)

Hi  jch2103,

could you provide a link to GooglePlayStore to the "GPSLogger" app (just searching for "GPSLogger" doesn't give a unique result). I'm asking, because I also use an Android app for GPS logging (Geo Tracker), but a battery-efficient app would be interesting.

Thanks,
Axel

[jch2103]

could you provide a link to GooglePlayStore to the "GPSLogger" app (just searching for "GPSLogger" doesn't give a unique result). I'm asking, because I also use an Android app for GPS logging (Geo Tracker), but a battery-efficient app would be interesting.

The app I use is 'GPS Logger for Android' by Mendhak. (You're right, there are a lot with very similar names.) This one has worked pretty well for me. Some of the places I hike have no mobile reception (which really drains the battery), so I put my phone in Airplane mode, but GPSLogger nevertheless grabs gps fixes and still respects batterh life. You can set the logging interval, etc., and there are also several choices for uploading the logs.

[sinus]

Looking back at the photos, I recall that I didn't actually start using GPSLogger until the second day (i.e., photo _DSC3141 in your set); instead, I used the excellent IMatch Map panel to geocode the first day's photos. Which would explain why you couldn't match the first two photos to the gpx track; my apologies!

John, this is what I do, geocoding with IMatch Map.

For my understanding, what is the advantage of an externam gpx-tracker? If I make a "mountain-tour" I see the advantage, but do you also use the tracker for a "normal" photo-session, where you are mostly in the same location?

[jch2103]

For my understanding, what is the advantage of an externam gpx-tracker? If I make a "mountain-tour" I see the advantage, but do you also use the tracker for a "normal" photo-session, where you are mostly in the same location?

The big advantage of using an external gps tracker is for a series of photos taken in different locations; examples would be for photos taken during hiking or traveling. As an example, on returning from a trip to New Zealand, I was having trouble figuring out where I'd taken many photos, until I remembered that my Garmin car gps records tracks. I was able to geocode the photos to get a good idea of at least where the car was when I took the photos.

On the other hand, if all the photos are taken in one or two known locations (or where exact location isn't important), just using the IMatch Map module is quicker/easier. And for some kinds of photos (e.g., family photos esp. with young kids) I don't use gps coordinates at all, just xmp location fields (country/state/city/and sometimes location).

I just acquired a Garmin gps watch; that should make it easier to record gpx tracks when needed.

[Mario]

I just acquired a Garmin gps watch; that should make it easier to record gpx tracks when needed.

There are also small GPS units you can put into the hotshoe of your camera. I think Nikon/Canon/... even make ones which automatically embed the position in the EXIF data. The GPS apps you get for smart phones also work reasonably well, although having a spare battery for the smart phone may prove helpful  One of the reasons I only buy smart phones with exchangeable batteries! And use Lineage OS.

[Jingo]

I just acquired a Garmin gps watch; that should make it easier to record gpx tracks when needed.

There are also small GPS units you can put into the hotshoe of your camera. I think Nikon/Canon/... even make ones which automatically embed the position in the EXIF data. The GPS apps you get for smart phones also work reasonably well, although having a spare battery for the smart phone may prove helpful  One of the reasons I only buy smart phones with exchangeable batteries! And use Lineage OS.

The biggest issues with the hotshoe GPS units are:  they are incredibly inaccurate and unreliable in terms of acquiring GPS satellite fixes and they eat through your camera batteries.. I went with a pocket GPS and though it is a bit of a pain to setup and sync clocks with all the cameras I use.. they work well, have long lasting batteries and are generally accurate with multiple satellite connections.

[jch2103]

The biggest issues with the hotshoe GPS units are:  they are incredibly inaccurate and unreliable in terms of acquiring GPS satellite fixes and they eat through your camera batteries.. I went with a pocket GPS and though it is a bit of a pain to setup and sync clocks with all the cameras I use.. they work well, have long lasting batteries and are generally accurate with multiple satellite connections.

I've had good experience with accuracy on my Promote GPS hot shoe unit (it can also sync the camera clock to UTC time). However, it can take several minutes to get an initial cold fix, and it's true that it reduces battery life (it's possible that newer, more efficient GPS units could improve this, but suspect those are all going to smartphone companies...). One of my cameras can't use a hot shoe unit, so I'm also pretty familiar with the standalone GPS alternative.

[sinus]

Quite interesting, thanks for all inputs.

If I am in the studio: no need for GPS 

On location: mostly I am on one place, does not matter for me, if 50 Meter more left or right, for me and my clients the correct GPS is not so important (mostly it is even not used).

[pmbvw]

The biggest issues with the hotshoe GPS units are:  they are incredibly inaccurate and unreliable in terms of acquiring GPS satellite fixes and they eat through your camera batteries.. I went with a pocket GPS and though it is a bit of a pain to setup and sync clocks with all the cameras I use.. they work well, have long lasting batteries and are generally accurate with multiple satellite connections.

Not all hotshoe GPS units are incredible inaccurate.
I have a Canon 5D MK III and a GPS EP-2 hot shoe GPS unit. This combination is very reliable and it produces accurate EXIF GPS data and also log and kmz tracks.

[Jingo]

Not all hotshoe GPS units are incredible inaccurate.
I have a Canon 5D MK III and a GPS EP-2 hot shoe GPS unit. This combination is very reliable and it produces accurate EXIF GPS data and also log and kmz tracks.

Interesting to hear you've had good luck with it.. my own experience is more akin to this: https://www.martinbaileyphotography.com/2012/05/14/podcast-335-canon-gps-receiver-gp-e2-review/

I think the biggest issue I run into is tall buildings.. while using units (this model [Canon GP-E2] and Nikon's GP-1A) in a town like Toledo with its narrow streets and tall-ish buildings - I was forever getting dropped signal and / or coordinates 3-4 blocks away.  In wide open fields it certainly fairs well.. but for urban use -  it wasn't all that accurate.

I moved to a Holex standalone and was quite happy with the results.  Satellite capture in about 10 seconds (compared to nearly 60 with the camera units).  20+ hour battery life... all in the size of a pocket lighter.  Throw it in the backpack and forget about it..

Good that there are lots of options for everyone!

[lnh]

I just acquired a Garmin gps watch; that should make it easier to record gpx tracks when needed.

I've been using a Garmin Fenix 3 for this use as well. Created a new photography "sport" with screens setup for the appropriate information (pretty minimal). It works well, and I use it daily anyways for cycling, Nordic skiing, hiking and other sports. You can also set a sport to use your set normal GPS recording method (1 second interval, Smart which reduces file size by not recording unless there is enough movement, and UltraTrac which shuts down GPS between ~1 minute recording intervals). For the watch itself you can set GLONASS on/off. Better battery life if it's off but nice to have the option if it's needed. For sports use I've set it to 1 second recording and have been playing around with UltraTrac for photo use. UltraTrac sacrifices some detail and accuracy for very long run times in the 50 hour range. The other day I sent Mario a track derived from the Garmin which was running for 3.5 hours in UltraTrac mode along with several pictures. He was able to handle the track and pictures in his test environment once getting the correct time offsets. I like not having to rely on my phone along with the extra battery drain for this use.

[jch2103]

I've been using a Garmin Fenix 3 for this use as well. Created a new photography "sport" with screens setup for the appropriate information (pretty minimal). It works well, and I use it daily anyways for cycling, Nordic skiing, hiking and other sports. You can also set a sport to use your set normal GPS recording method (1 second interval, Smart which reduces file size by not recording unless there is enough movement, and UltraTrac which shuts down GPS between ~1 minute recording intervals). For the watch itself you can set GLONASS on/off. Better battery life if it's off but nice to have the option if it's needed. For sports use I've set it to 1 second recording and have been playing around with UltraTrac for photo use.

Thanks for the tips. I'm still setting up my new Forerunner 935, so this is very helpful.

[lnh]

Thanks for the tips. I'm still setting up my new Forerunner 935, so this is very helpful.

Nice one! The 935 has WiFi built-in as well. One of my favorite features of the Fenix 3. Don't have to bother with Bluetooth to Phone to Internet; just connect to WiFi and your tracks appear instantly in Garmin Connect. From there you can export to GPX in the detailed view of your activity. It's also possible to use the cradle and from your PC copy the FIT file and use whatever conversion program you'd like, but the auto upload to Garmin Connect is simple. I've also found their telephone tech support excellent when I've needed assistance.