Consider execution option to ouput GPS Position in Google Maps compatible format

[Serenity]

Sorry if this already has been mentioned, but I didn't find it in a search.
It would be super handy if there was an option that could be added onto the -k, that would cause the GPS Position output to be displayed in the format that is needed for Google Maps, so it could easily be swiped, and pasted in.

Also, I wrote a crude little script (below) to perform that conversion.  I have several iterations of Linux-capable components on my Windows desktop, so I was lazy, and wrote it in BASH.  Bottom line, it represents the necessary editing to convert the current output to something that Google Maps will eat.  Also, if you think anyone else might make use of the script (if you decide not to implement an option), feel free to post it as a "tool".

Side story.... I rafted the Colorado River thru the Grand Canyon a decade ago, and shot a lot of footage with a Sony camera that had a GPS receiver.  Recently, I was reviewing that footage, and dropped the various clips onto exiftool, where it obviously coughed up the coordinates (and was the reason I wrote the script).  It was cool to be able to just drop those coordinates into Google Maps, and have it jump straight to the location on the river, where each video was shot.  (What was even more bizarre was that Google has "street viewed" the entire river, so I could use that to get a 360 degree view of the location, where I'd shot my footage.)  Anyway, I would not have been able to do any of that without your tool, so THANKS again for all of your efforts!!


#!/bin/bash
#
# gps
# Version 1.0
#
# Nov 13, 2018

# The purpose of this script is to eat one (or more) GPS coordinates,
#  generated by Phil Harvey's the exiftool utility, and cough up a
#  string that can be pasted directly into the "address" field of
#  maps.google.com.
# If GPS information exists in a media file, the -k output of ExifTool
#  will generate both multiline output of GPS coordinates, as well as
#  a single line (combined) entry.  It is that later entry that should
#  be copy/pasted as input into "gps".
#
# Usage: Simply execute "gps", i.e. ./gps
#  It will immediately request an input line.  Just paste in the
#    ExifTool content, and it will spit out the restructured output
#    needed for Google Maps.
#  You can paste in (and convert) additional lines, and simply Ctrl-c
#    when done, to terminate the utility.

# Admittedly being a bit lazy, and unelegant in the coding, but this
#  allows a more readable view of what is being done.
while read line            # Read lines, indefinitately
do
  line=${line// deg /°}    # Replace with degree character
  line=${line// /}         # Kill all spaces
  line=${line/,/}          # Remove the comma
  line=${line/+/}          # Kill northern hemisphere notation
  len1=${#line}            # Capture string length
  line=${line/-/}          # Kill southern hemisphere notation
  len2=${#line}            # Capture new length

  # If there was a trailing 'minus', insert it at the front!
  [ ${len1} -ne ${len2} ] && line=${line/#/-}
  echo "${line}"
done < "${1:-/dev/stdin}"

[StarGeek]

There are already a variety of options.  You could make a shortcut (see the note under running in Windows) with  exiftool (-k -GPSPosition# -s3) that would pop up a window with only the gps coordinates which you could copy/paste into Google maps.  It returns raw numeric data (for example 40.6892 -74.0445) which google maps accepts directly.

But for an even better drag/drop solution, create a bat file with this line
exiftool -GPSPosition# -s3 %* |clip

Then, when you drag/drop a file onto the bat file, the gps coordinates are automatically copied to the clipboard.

[Serenity]

Thanks.  That does seem like an acceptable/better work-around (especially the auto-copy to the clipboard), although (for anyone else who might adopt it) I had a massive bit of unpleasantness attempting to implement it.

There is some sort of nasty buglet that currently (i.e. the date of this post) exists in Windows 10.  I was, almost literally, pulling my hair out trying to get this to work, making all sorts of adjustments to the script that I was coding (my exiftool directory is not in the standard PATH, so the example provided above would not work for me).  I kept thinking that I'd made some sort of typo, but I couldn't get the script to execute properly, no matter what I did.

Finally... I realized that it was something more insidious.  Specifically, that it wasn't something wrong in my script, it was the fact that when I dropped my file on my script, it was NOT even executing the script.  I.E. that drag-and-drop wasn't functioning at all.

I did some digging (... always remember ... "Google is your friend"), and found the following page, where they discuss the fact that this "bug" exists, and how to work around it when it crops up (basically, it involves "killing Windows explorer", and executing a new iteration), which should take all of about 10 seconds, if you do it right.  Obviously, a clean reboot would achieve the same result, but this work-around avoids having to close all your apps, shutdown, reboot, etc., and more importantly, because the problem will likely recur, it lets you "fix it", quickly, as often as the bug crops up.

The drag-and-drop "quick work-around": https://howtoremove.guide/windows-10-drag-and-drop-not-working/


So, THANKS AGAIN, for passing along the command string necessary to generate the GPS output, and pop it into the clipboard.  That works really well!

[StarGeek]

(my exiftool directory is not in the standard PATH, so the example provided above would not work for me)

I hadn't heard of the bug, but you can always use the full path in a bat file
c:\Path\To\exiftool -GPSPosition# -s3 %* |clip

[Serenity]

Oh yeah, I am spent my life in an IT universe, so that wasn't an issue, but I'd never played with drag and drop (or, at least, certainly not into a BAT/CMD file), so when that didn't work, I just spent a lot of (wasted) time starting to question anything and everything, even things that I knew shouldn't have had any impact.  It didn't help that drag and drop onto an EXE worked fine, hence I never really suspected a problem with D-and-D.  But, as the mentioned web page discusses, the bug only manifests when the target of the D-and-D is a script.

Anyway, again... it was a frustrating debugging effort, courtesy of someone in the MS development team.

Thanks again for your time, and totally cool solution.