The user wants a bash script that: 1. Uses `exiftool` (they wrote "exiftools" but meant `exiftool`) to scan a directory of photos 2. Extracts GPS coordinates from the EXIF data 3. Outputs the results as GeoJSON format Let me think about how GPS coordinates are stored in EXIF data: - `GPSLatitude` and `GPSLongitude` - these are in DMS (degrees, minutes, seconds) format - `GPSLatitudeRef` and `GPSLongitudeRef` - N/S and E/W indicators - `GPSAltitude` - altitude - `GPSPosition` - this is a convenient tag that gives decimal degrees directly For maximum precision, I should use the raw GPS coordinate values. `exiftool` can output coordinates in various formats. The most precise approach would be to use the raw rational values, but a simpler approach that still gives high precision is to use `-n` (numerical) output combined with specific GPS tags. Let me think about the best approach: 1. Use `exiftool -n` to get numerical output for GPS tags 2. Or use `exiftool -c "%.10f"` to get high-precision decimal format3. Or parse the DMS values directly The `-n` flag makes exiftool output numerical values. With `-c` we can control decimal precision. Actually, the simplest high-precision approach: - `exiftool -n -GPSLatitude -GPSLongitude` gives decimal degrees directly- Or `exiftool -c "%.10f" -GPSLatitude -GPSLongitude` Let me also consider `GPSLatitudeRef` and `GPSLongitudeRef` for the sign. When using `-n` (numerical), `GPSLatitude` and `GPSLongitude` are output as decimal degrees with the correct sign based on the ref. Wait, actually I need to check - does `-n` handle the ref automatically? With `-n` (numerical) flag: - GPSLatitude is output as a decimal number (positive) - GPSLatitudeRef is output as a string "N" or "S" - We need to handle the sign ourselves Actually, let me reconsider. There's a `GPSPosition` tag that gives both lat and lon. And there's `GPSLatitude` and `GPSLongitude`. Let me write a robust script: ```bash #!/bin/bash # Scan a directory of photos and extract GPS coordinates as GeoJSON if [ -z "$1" ]; then echo "Usage: $0 " exit 1 fi DIRECTORY="$1" # Start GeoJSON FeatureCollection echo '{' echo ' "type": "FeatureCollection",' echo ' "features": [' first=true # Find all files and process with exiftool exiftool -n -filename -GPSLatitude -GPSLongitude -GPSAltitude -GPSLatitudeRef -GPSLongitudeRef -r "$DIRECTORY" | # Process the exiftool output ... ``` Hmm, this approach of parsing exiftool's grouped output is tricky. Let me think of a better approach. A better approach is to use `exiftool -json` to get JSON output, then process it with `jq`. Or, I can use `exiftool` with `-n -csv` or `-n` with careful parsing. Let me use the `-json` output approach since it's cleaner: ```bash exiftool -n -json -r "$DIRECTORY" | jq '...' ``` Wait, but the user asked for a bash script. Let me think about whether to use jq or pure bash. Using jq would be the cleanest approach. Let me use both exiftool and jq. Actually, let me think about a pure bash approach too. But parsing exiftool's output reliably in pure bash is messy. Let me use a hybrid approach - use exiftool to extract data per file, then format as GeoJSON. Let me go with a bash script that uses exiftool's `-n` flag to get numerical GPS data, processes it file by file, and builds the GeoJSON. I'll also offer a jq-based approach as an alternative. Actually, let me think about this more carefully. The `-n` flag with exiftool: For `-GPSLatitude -n`, exiftool outputs the latitude as a signed decimal number... wait, no. Let me check. With `-n`: - GPSLatitude comes out as a decimal number (positive) - GPSLatitudeRef comes out as "North" or "South" (or just "N"/"S" with -n?) Actually with `-n`, GPSLatitudeRef is output as a string like "North" or "South". Hmm, actually I think it might just be the character. Let me just test my knowledge: - `-n` makes numeric tags output as numbers - For GPSLatitude with `-n`, it outputs the decimal degrees as a positive number - GPSLatitudeRef with `-n` outputs "North" or "South" Wait, I think with `-n`, the Ref tags are still strings. Let me just handle both cases. Actually, the cleanest approach is to use `-c "%.10f"` which controls the decimal precision of coordinates, and then handle the N/S E/W refs. Hmm, but there's an even simpler way. Let me use `exiftool` with the `-p` (print) option to format the output exactly how I want per file: ```bash exiftool -p '${filename},${GPSLatitude},${GPSLongitude},${GPSLatitudeRef},${GPSLongitudeRef},${GPSAltitude}' -n -r "$DIRECTORY" ``` Wait, with `-n`, the template variables for GPS would already be numerical. But the Ref would still be a string. Actually, I just recalled: when you use `-p` with GPSLatitude and `-n`, it gives you the unsigned decimal value. You need to handle the sign with the Ref. Let me write a practical script: ```bash #!/bin/bash if [ -z "$1" ]; then echo "Usage: $0 " >&2 exit 1 fi DIRECTORY="$1" FEATURES="" FIRST=true while IFS= read -r -d '' file; do # Extract GPS data gps_data=$(exiftool -n -p '${GPSLatitude; $_ = abs} ${GPSLatitudeRef} ${GPSLongitude; $_ = abs} ${GPSLongitudeRef} ${GPSAltitude}' "$file" 2>/dev/null) if [ -z "$gps_data" ]; then continue fi ... done < <(find "$DIRECTORY" -type f $ -iname '*.jpg' -o -iname '*.jpeg' ... $ -print0) ``` Hmm, this is getting complex. Let me think about the exiftool print format more carefully. With `exiftool -p`: - `${GPSLatitude}` with `-n` flag gives the unsigned decimal value - `${GPSLatitudeRef}` gives "North" or "South" Actually wait - without `-n`, `${GPSLatitude}` in a print format gives something like "51 deg 30' 12.00\" N" and with `-n` it gives "51.5033333333" (unsigned).Hmm, but there might be an issue. Let me think about what the raw GPS values look like. The EXIF GPS coordinates are stored as rational numbers (degree/1, minute/1, second*100/100 or similar). The precision depends on the camera. For maximum precision, I should extract the raw values. Using `-n` with `-p` format should give me the full precision that exiftool can read. Let me also think about using the `-c` flag: `exiftool -c "%.8f"` controls the format of coordinate values. OK let me just write a practical, well-documented script. I'll use a combination of `exiftool` for extraction and build the GeoJSON in bash. I'll also provide a note about using jq as an alternative. Here's my plan: ```bash #!/usr/bin/env bash # gps_to_geojson.sh # Scans a directory of photos and extracts GPS coordinates into GeoJSON format. # Requires: exiftool (libimage-exiftool-perl) set -euo pipefail if [[ $# -lt 1 ]]; then echo "Usage: $0 [output.geojson]" >&2 exit 1 fi DIR="$1" OUT="${2:-/dev/stdout}" if [[ ! -d "$DIR" ]]; then echo "Error: '$DIR' is not a directory." >&2 exit 1 fi # Use exiftool with -json output and process with a here-doc approach # Or use -csv and process # Let me go with the per-file approach for reliability``` Actually, you know what, let me use the exiftool `-json` output combined with jq. It's much cleaner and more reliable than trying to parse line-by-line output. ```bash #!/usr/bin/env bash # gps_to_geojson.sh exiftool -json -n -r -ext jpg -ext jpeg -ext tiff -ext png \ -filename -GPSLatitude -GPSLongitude -GPSAltitude \ -GPSLatitudeRef -GPSLongitudeRef \ "$1" | jq '...' ``` But wait - with `-json` and `-n`, what does the output look like? With `-json -n`, each file becomes a JSON object. GPSLatitude would be a number (unsigned). GPSLatitudeRef would be a string. Actually, I just realized something. With `-n` (numeric output mode), the GPS latitude and longitude might be output as signed or unsigned depending on whether Ref is also present. Let me think... In `-n` mode: - `GPSLatitude` is unsigned decimal degrees- `GPSLatitudeRef` is "North" or "South" So I need to apply the sign myself. But wait, there's another approach: without `-n`, and with `-c "%.10f"`, `GPSLatitude` might include the hemisphere indicator. Hmm, but then it would be a string with "N" or "S" appended. OK, I think the cleanest approach for the script is: 1. Use `exiftool` to extract data per file in a tabular/parseable format 2. Process each line in bash 3. Build GeoJSON output Or use the JSON approach with jq. Let me write both approaches and go with the one that's cleaner. I'll go with a bash script that processes files one at a time. Actually, let me reconsider. The user said "bash script that uses exiftool". The simplest, most robust approach that stays in bash: ```bash #!/usr/bin/env bash # Process each image file with exiftool, extracting GPS coordinates # Use -n for numeric output, parse the results, and build GeoJSON find "$DIR" -type f $ -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.tiff' -o -iname '*.png' -o -iname '*.heic' -o -iname '*.heif' -o -iname '*.webp' -o -iname '*.dng' -o -iname '*.cr2' -o -iname '*.nef' $ -print0 | while IFS= read -r -d '' file; do # Get GPS data lat=$(exiftool -n -p '$GPSLatitude' "$file" 2>/dev/null) lon=$(exiftool -n -p '$GPSLongitude' "$file" 2>/dev/null) latref=$(exiftool -n -p '$GPSLatitudeRef' "$file" 2>/dev/null) lonref=$(exiftool -n -p '$GPSLongitudeRef' "$file" 2>/dev/null) if [[ -z "$lat" || -z "$lon" ]]; then continue fi # Apply hemisphere [[ "$latref" == "South" ]] && lat="-${lat}" [[ "$lonref" == "West" ]] && lon="-${lon}" ... done ``` Wait, running exiftool 4 times per file is inefficient. Let me use `-p` with a combined format: ```bash result=$(exiftool -n -p '${GPSLatitude} ${GPSLatitudeRef} ${GPSLongitude} ${GPSLongitudeRef} ${GPSAltitude} ${filename}' "$file" 2>/dev/null) ``` Then parse the result. But the issue is that GPSLatitudeRef with -n outputs "North" or "South" as full words. The template variable `${GPSLatitudeRef}` with -n... hmm. Actually, without `-n`, `${GPSLatitudeRef}` would give "North" or "South". With `-n`, it might still give the same thing since it's a string field, not a number. Let me just test with what I know and write a robust script. Let me go with a cleaner approach: use `exiftool -json` and then process with a simple Python or awk script. But the user wants a bash script... OK, here's my final approach. I'll write a clean bash script that: 1. Uses `exiftool` to extract GPS data per file 2. Builds GeoJSON output For efficiency, I'll use `exiftool -json` to process all files at once, then parse the JSON. For parsing JSON in bash, I'll use `jq` since it's commonly available. If `jq` isn't available, I'll mention it. Actually, let me provide a comprehensive script that uses `exiftool` with its `-p` (print) format to get exactly what we need in a easily parseable format, then builds GeoJSON. Let me write the definitive version: ```bash #!/usr/bin/env bash # # gps_to_geojson.sh - Extract GPS coordinates from photos and output GeoJSON # # Usage: ./gps_to_geojson.sh [output_file] # # Dependencies: exiftool, jq (optional but recommended) # set -euo pipefail DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" if [[ ! -d "$DIR" ]]; then echo "Error: '$DIR' is not a directory." >&2 exit 1 fi # Image extensions to scan EXTENSIONS=(-ext jpg -ext jpeg -ext tiff -ext tif -ext png -ext heic -ext heif -ext webp -ext dng -ext cr2 -ext cr3 -ext nef -ext arw -ext rw2) # Use exiftool to extract GPS data as JSON # -n: numeric output (decimal degrees for coordinates) # -r: recursive GPS_JSON=$(exiftool -json -n -r "${EXTENSIONS[@]}" \ -GPSLatitude -GPSLongitude -GPSAltitude \ -GPSLatitudeRef -GPSLongitudeRef \ -filename -Directory \ "$DIR" 2>/dev/null) # Now process with jq to build GeoJSON echo "$GPS_JSON" | jq '{ type: "FeatureCollection", features: [ .[] | select(.GPSLatitude != null and .GPSLongitude != null) | { type: "Feature", geometry: { type: "Point", coordinates: [ (if .GPSLongitudeRef == "West" then -.GPSLongitude else .GPSLongitude end), (if .GPSLatitudeRef == "South" then -.GPSLatitude else .GPSLatitude end), (.GPSAltitude // empty) ] }, properties: { filename: .FileName, path: (.Directory + "/" + .FileName) } } ] }' > "$OUTPUT" ``` Wait, but with `-n`, the GPSLatitudeRef... let me think. Actually, I'm not 100% sure what `GPSLatitudeRef` outputs with `-n` in JSON mode. It might be "North"/"South" or "N"/"S" or even just a number. Hmm, let me think about this differently. Maybe I should NOT use `-n` and instead use a different approach. Without `-n`, in JSON output: - `GPSLatitude` might be a string like "51 deg 30' 12.00\" N" - `GPSLatitudeRef` might be "North" With `-n`, in JSON output: - `GPSLatitude` would be a number like 51.503333333 - `GPSLatitudeRef` might be "North" (it's a string type, not numeric) Actually, I just recalled that in exiftool's JSON output with `-n`: - `GPSLatitude` is a floating point number (always positive, unsigned) - `GPSLatitudeRef` is a string like "North" or "South" So the script above should work. But let me also consider that some photos might have the sign already embedded in the coordinate (some implementations do this). To be safe, I'll check both the Ref and the sign. Hmm, but actually there's another approach that avoids the sign issue entirely. I can use the exiftool `-c` flag and the `GPSPosition` tag, or I can use `-n` and derive the sign. Wait, I just thought of something else. The `GPSLatitude` with `-n` might actually include the sign if the latitude is south. Let me check... In the EXIF spec, GPS coordinates are always stored as unsigned values with a separate reference (N/S, E/W). Exiftool with `-n` outputs them as unsigned, and the Ref separately. So I need to handle the sign. OK here's another concern: with `-json`, exiftool might not include keys for GPSLatitudeRef if it's absent, which would cause issues with the jq filter. The `//` operator in jq handles null, but the key might be missing entirely. Actually, jq handles missing keys by returning null, so `//` should work. But wait, the GPSLatitudeRef is pretty much always present when GPSLatitude is present. They come as a pair in EXIF. Let me also think about altitude. GPSAltitude is stored as a rational number and with `-n` gives a float. It might be absent, so I need to handle that in the GeoJSON. According to GeoJSON spec, coordinates can be [lon, lat] or [lon, lat, alt]. So I'll include altitude only if present. OK let me also think about whether I should use `jq` at all. The user asked for a "bash script". Using `jq` is a common and practical approach. But I could also write it in pure bash. Let me provide the `jq` version as the primary approach, and mention a pure-bash alternative. Actually, let me think about what the output of `exiftool -json -n` looks like more carefully. When using `exiftool -json -n` on a photo with GPS data, it outputs an array of objects. Each object has all the tags that were requested. For a file without GPS data, the GPS tags would simply not be present in the object. So my jq filter with `select(.GPSLatitude != null and .GPSLongitude != null)` would correctly skip files without GPS data. For the altitude: `(.GPSAltitude // empty)` in jq would omit the third coordinate if altitude is null. This is correct per GeoJSON spec. Let me also think about the path properties. The `SourceFile` field in exiftool's JSON output gives the full path. Let me use that instead of concatenating Directory and FileName. Here's another consideration: the `-n` flag changes how `GPSLatitudeRef` is output. Without `-n`, it's "North" or "South". With `-n`... I think it might still be a string. Let me just check both "North"/"South" and "N"/"S" in the jq filter to be safe. Actually wait, I just realized there might be an issue. Let me reconsider using exiftool differently. There's a convenient exiftool tag called `GPSPosition` which gives the latitude and longitude combined. But it's typically output as a string like "51.5033, -0.1275" in DMS format without `-n`, and as two numbers with `-n`. Hmm, but in `-n` mode with JSON, `GPSPosition` might not be well-structured. OK, I think my approach is sound. Let me finalize the script. One more thing: I want maximum precision. With `-n`, exiftool outputs GPS coordinates with the full available precision from the EXIF data (typically stored as rational numbers with4 decimal places of seconds, giving ~1cm precision). The `-c` flag can be used to control the number of decimal places. By default, exiftool uses `%f` format which gives 6 decimal places. For maximum precision, I could use `-c "%.10f"` or more. Wait, I should be more careful here. The `-c` flag affects how exiftool formats coordinate values in its output. With `-n`, coordinates are already numbers, and the `-c` flag might not apply. Let me think... Actually, `-c` sets the format for printing coordinates. With `-n`, the coordinates are output as numbers and the `-c` format still applies. So `-c "%.10f"` would give10 decimal places. But wait - the actual precision is limited by the EXIF data. GPS coordinates in EXIF are stored as DMS with rational numbers (numerator/denominator). The typical precision is: - Degrees: integer - Minutes: integer - Seconds: stored as a rational, e.g., 1234/100 = 12.34 seconds 12.34 seconds =12.34/3600 degrees =0.003428 degrees 0.000001 degrees ≈ 0.11 meters So 6 decimal places of degrees gives about 11cm precision, which should be sufficient.8 decimal places would give ~1mm precision, which is more than the GPS data typically provides. For "as high precision as possible", I should use enough decimal places to not lose any precision from the stored data. Using `-c "%.10f"` should be more than enough. But with `-n` in JSON mode, the numbers are floating point. The precision depends on how exiftool serializes them. JSON numbers can have arbitrary precision, so exiftool should output the full precision available. Hmm, actually, I realize the `-c` flag may not affect JSON output. JSON numbers are just numbers. Exiftool might serialize them as full-precision floats in JSON mode. Let me just go with `-json -n` and not worry about `-c`. OK here's my final script. Let me also add some nice features like handling of the case where jq is not available. Actually, let me provide TWO approaches: 1. One using `exiftool -json` + `jq` (cleaner) 2. One using pure bash with `exiftool -p` (no jq dependency) Let me write the primary one with jq and include a fallback. Hmm, on second thought, let me just write one good script with jq since it's a very common tool, and mention the dependency clearly. Here's my final approach: ```bash #!/usr/bin/env bash # # photo_gps_to_geojson.sh # Scans a directory of photos and extracts GPS coordinates into GeoJSON. # # Usage: ./photo_gps_to_geojson.sh [output.geojson] # # Dependencies: exiftool, jq # set -euo pipefail # --- Argument handling --- DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" if [[ ! -d "$DIR" ]]; then echo "Error: '$DIR' is not a valid directory." >&2 exit 1 fi # Check dependencies for cmd in exiftool jq; do if ! command -v "$cmd" &>/dev/null; then echo "Error: '$cmd' is required but not found. Install it first." >&2 exit 1 fi done # --- Extract GPS data --- # exiftool flags: # -json Output as JSON # -n Numerical output (coordinates as decimal degrees) # -r Recursive scan # -ext File extensions to include# # For maximum precision, we extract the raw GPS rational values. # exiftool -n outputs GPS latitude/longitude as decimal degrees. exiftool -json -n -r \ -ext jpg -ext jpeg -ext tiff -ext tif -ext png \ -ext heic -ext heif -ext webp \ -ext dng -ext cr2 -ext cr3 -ext nef -ext arw -ext rw2 -ext raf \ -GPSLatitude -GPSLongitude -GPSAltitude -GPSAltitudeRef \ -GPSLatitudeRef -GPSLongitudeRef \ -filename \ "$DIR" 2>/dev/null | \ jq --arg dir "$DIR" '{ type: "FeatureCollection", features: [ .[] | select(.GPSLatitude != null and .GPSLongitude != null) | # Determine sign from hemisphere reference (if (.GPSLatitudeRef // "") == "South" then -1 else 1 end) as $lat_sign | (if (.GPSLongitudeRef // "") == "West" then -1 else 1 end) as $lon_sign | { type: "Feature", geometry: { type: "Point", coordinates: [ .GPSLongitude * $lon_sign, .GPSLatitude * $lat_sign ] + (if .GPSAltitude then [.GPSAltitude] else [] end) }, properties: { file: .SourceFile, filename: .FileName, altitude: .GPSAltitude, altitude_ref: (.GPSAltitudeRef // null) } } ] }' > "$OUTPUT" echo "GeoJSON written to: $OUTPUT" >&2 ``` Wait, there's an issue. When using `exiftool -json`, the output for each file is an object, and the key for the file path is `SourceFile`. But I'm not requesting `SourceFile` explicitly - does it come automatically? Yes, `SourceFile` is always included in `-json` output. But I'm requesting `-filename` which gives `FileName`. `SourceFile` gives the full path. Both should be available. Actually, wait. I didn't include `-SourceFile` in the exiftool command. Let me check - is `SourceFile` always present in `-json` output regardless? Yes, it's always included as a standard field in the JSON output. Hmm, but if I request specific tags, does exiftool still include SourceFile? Let me think... yes, SourceFile is a special tag that's always included in JSON output mode. Actually, I'm second-guessing myself. To be safe, let me not rely on SourceFile and instead construct the path from Directory and FileName. Or better yet, let me request it explicitly. But actually I think SourceFile is always there in JSON mode. OK let me also reconsider the jq filter. When using `(.GPSLatitudeRef // "")`, if the key is missing from the JSON object, jq returns null, and `// ""` gives "". So `(.GPSLatitudeRef // "") == "South"` would be false, and the sign would be +1. This is safe. For coordinates without Ref (shouldn't happen but just in case), defaulting to positive is the right thing. Let me also think about the altitude. `GPSAltitude` is typically positive (above sea level) and `GPSAltitudeRef` is typically0 (above sea level) or 1 (below sea level). For underwater or Dead Sea photos, it could be negative. But this is rare and I should handle it. Hmm, but the altitude is not usually critical for GeoJSON. Let me include it if available but not over-complicate things. Also, I realize there's a subtle issue with the `coordinates` array construction in jq: ``` [.GPSLongitude * $lon_sign, .GPSLatitude * $lat_sign] + (if .GPSAltitude then [.GPSAltitude] else [] end) ``` This should work in jq to conditionally include altitude. Let me finalize and clean up the script. I'll also add comments explaining the precision. One more thing about precision: `exiftool -n` for GPS coordinates... Let me think about what precision this actually gives. The GPS EXIF tags store coordinates as: - GPSLatitude: array of 3 rational values [degrees, minutes, seconds] - Each rational value is stored as numerator (unsigned long) / denominator (unsigned long) Typical cameras store seconds as something like45678/1000 = 45.678 seconds. This gives precision of0.001 seconds = 0.001/3600 degrees ≈ 0.0000003 degrees ≈ 0.03 meters Exiftool converts this to decimal degrees with `-n`. The precision in the output depends on the number format used. In JSON, it should preserve the full double-precision floating point representation, which has about 15-17 significant digits - more than enough to represent the EXIF data without loss. But some newer cameras and smartphones store coordinates with higher precision. For example, DJI drones store GPS with much higher precision. Exiftool handles these correctly with `-n`. So using `-json -n` should give us the maximum precision available in the EXIF data. One more thing: I should also extract `GPSHPositioningError` if available (newer tags), and `GPSDateTime` or `GPSDateStamp`/`GPSTimeStamp` for the timestamp. Let me add these as optional properties. Actually, let me keep it focused on what the user asked for - coordinates as GeoJSON. I'll add a few useful metadata properties but not go overboard. Let me write the final version: ```bash #!/usr/bin/env bash # # photo_gps_to_geojson.sh # # Scans a directory of photo files using exiftool, extracts embedded GPS # coordinates, and outputs a GeoJSON FeatureCollection. # # Coordinates are extracted at the full precision stored in EXIF/XMP/GPS tags. # Typical smartphone GPS precision: ~1cm (6+ decimal places of degrees). # # Usage: # ./photo_gps_to_geojson.sh [output.geojson] # # Dependencies: # - exiftool (install: sudo apt install libimage-exiftool-perl) # - jq (install: sudo apt install jq) # set -euo pipefail # ── Validate arguments ──────────────────────────────────────────────PHOTO_DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" if [[ ! -d "$PHOTO_DIR" ]]; then echo "Error: '$PHOTO_DIR' is not a valid directory." >&2 exit 1 fi # ── Check dependencies ────────────────────────────────────────────── for cmd in exiftool jq; do command -v "$cmd" &>/dev/null || { echo "Error: Required command '$cmd' not found." >&2 exit 1 } done # ── Extract GPS data and build GeoJSON ────────────────────────────── # # exiftool flags: # -n Numeric mode: coordinates as signed decimal degrees # -json Output a JSON array (one object per file) # -r Recurse into subdirectories # # GPS tags extracted: # GPSLatitude / GPSLatitudeRef → latitude with hemisphere # GPSLongitude / GPSLongitudeRef → longitude with hemisphere # GPSAltitude → altitude in meters # # The -n flag causes exiftool to output coordinates as decimal-degree # floats (not DMS strings), preserving full EXIF rational precision. exiftool -json -n -r \ -ext jpg -ext jpeg -ext jpe \ -ext tiff -ext tif \ -ext png \ -ext heic -ext heif \ -ext webp \ -ext dng -ext cr2 -ext cr3 \ -ext nef -ext arw -ext sr2 -ext rw2 -ext raf \ -ext orf -ext raw \ -GPSLatitude -GPSLatitudeRef \ -GPSLongitude -GPSLongitudeRef \ -GPSAltitude -GPSAltitudeRef \ "$PHOTO_DIR" 2>/dev/null | jq '{ type: "FeatureCollection", features: [ .[] | select(.GPSLatitude != null and .GPSLongitude != null) | ( if (.GPSLatitudeRef // "N") == "South" then -1 else 1 end ) as $ls | ( if (.GPSLongitudeRef // "E") == "West" then -1 else 1 end ) as $ws | { type: "Feature", geometry: { type: "Point", coordinates: [ .GPSLongitude * $ws, .GPSLatitude * $ls ] + ( [ .GPSAltitude // empty ] ) }, properties: { file: .SourceFile, filename: .FileName, latitude: (.GPSLatitude * $ls), longitude: (.GPSLongitude * $ws), altitude: .GPSAltitude } } ] }' > "$OUTPUT" ``` Hmm wait, I have a concern. Does `SourceFile` appear in the JSON output when I explicitly specify tags? Let me think... When you use `exiftool -json -tag1 -tag2 file.jpg`, the output includes all specified tags plus `SourceFile`. `SourceFile` is always included in JSON output as a metadata key. Yes, I'm confident about this. Also, `[ .GPSAltitude // empty ]` in jq: if GPSAltitude is null, `empty` produces nothing, so the array is `[]`. If GPSAltitude is a number, the array is `[number]`. Then `+` concatenates the coordinate pair with this optional altitude. This is correct GeoJSON behavior. Let me also consider: what if `GPSLatitudeRef` is present but has a different value than "North"/"South"? Some implementations might use "N"/"S" or even0/1. With `-n`, I believe exiftool normalizes these to "North"/"South". But to be safe, let me also check for "S": Actually, let me just check if the Ref starts with "S" or "W": ``` ( if ((.GPSLatitudeRef // "") | test("^S")) then -1 else 1 end ) as $ls ``` Hmm, this is getting complicated. Let me keep it simple with exact match "South"/"West" since that's what exiftool outputs. Actually wait, I just want to double-check: with `-n` flag and `-json`, does `GPSLatitudeRef` come out as "North"/"South" or as the raw value? In EXIF, GPSLatitudeRef is stored as a single ASCII byte: "N" or "S". Exiftool, by default (without `-n`), would display the tag value as-is. With `-n`, for string-type tags, it should also display as-is. So it would be "N" or "S", not "North"/"South". Hmm, but I'm not sure. Exiftool might expand the single-letter ref to the full word. Let me handle both cases. Actually, you know what, let me test this logic differently. In the EXIF specification: - GPSLatitudeRef: ASCII "N" or "S" (2 bytes including null) - GPSLongitudeRef: ASCII "E" or "W" (2 bytes including null) When exiftool reads this with `-n`, in JSON mode, the value would be the string as read from the file. So it should be "N" or "S" for latitude ref and "E" or "W" for longitude ref. But exiftool might have a "print conversion" that expands these. Without `-n`, print conversion is enabled by default. With `-n`, print conversion is disabled for numeric tags but might still apply to string tags. OK, I think I'm overthinking this. Let me just handle both "N"/"South" and "S"/"South" cases. Or better yet, let me check if the Ref starts with "S" or "W": ```jq ( if (.GPSLatitudeRef // "N" | test("^[Ss]")) then -1 else 1 end ) as $ls ``` Or even simpler, I can check if it's NOT "North" or "N": ```jq ( if ((.GPSLatitudeRef // "") | ascii_downcase | startswith("s")) then -1 else 1 end ) as $ls ``` Hmm, `startswith` doesn't exist in jq. Let me use `test`: ```jq ( if ((.GPSLatitudeRef // "") | test("^[Ss]")) then -1 else 1 end ) as $ls ``` This would match "S", "South", "south", etc. This is more robust. Similarly for longitude: ```jq ( if ((.GPSLongitudeRef // "") | test("^[Ww]")) then -1 else 1 end ) as $ws ``` OK let me finalize with this approach. Let me also handle the edge case where the latitude/longitude itself is already negative (shouldn't happen with correct EXIF data but defensive programming is good). Actually no, with `-n`, exiftool always outputs unsigned values for GPS lat/lon since the sign is determined by the Ref. So I don't need to worry about double-negation. Actually wait, I should double-check. There's a possibility that some non-standard implementations embed the sign in the coordinate value itself. In that case, my script would double-negate. But this would be a malformed EXIF file, so I'll not worry about it. Let me finalize the script now. Actually, I want to also mention one more important thing about precision. The `-n` flag outputs GPS coordinates as decimal degrees. The precision depends on the numerator/denominator ratio stored in EXIF: For a typical camera storing seconds as 12345/100 = 123.45 seconds: - This is123.45 / 3600 = 0.034291667 degrees - In decimal: the latitude would be something like 51.5034291667 - That's 10 decimal places of precision Exiftool converts the rational values to floating-point doubles, which have ~15 significant digits. This is more than enough to represent the original EXIF data without loss. Some cameras (especially smartphones) store coordinates from their GPS chip with even higher precision. The rational format allows for this. So `-n` with JSON output gives us the maximum precision available in the EXIF data.One more thought: should I also use `-G` (group names) to distinguish between EXIF and XMP GPS data? Some photos might have GPS in both IFD and XMP. `-n` already extracts the most specific data. I think this is fine. OK, final script. Let me also handle the case where there are no GPS-tagged photos: ```jq if (.features | length) == 0 then { type: "FeatureCollection", features: [], warning: "No photos with GPS data found" } else { type: "FeatureCollection", features: .features } end ``` Actually, a GeoJSON FeatureCollection with an empty features array is perfectly valid. No need for special handling. Let me also think about whether to include timestamp information. The user asked specifically for coordinates, but having a timestamp would be useful for the GeoJSON. Let me add GPSDateStamp and GPSTimeStamp as optional properties. Hmm, but the user specifically asked for coordinates. Let me keep it focused but mention in comments that additional tags can be added. OK here's my truly final script: Actually, one more issue. When exiftool processes files with `-json`, it outputs ALL files in the array, even those without GPS data. The jq filter `select(.GPSLatitude != null ...)` handles this correctly by filtering them out. Good. But for large directories, this means exiftool processes every file and outputs a potentially huge JSON array. This might be slow. An alternative would be to use exiftool's `-if` option to only process files with GPS data: ``` exiftool -json -n -r -if '$GPSLatitude' ... ``` This would only include files that have GPSLatitude in the output. This is more efficient! Wait, but `-if` with `-json` might still include empty objects... actually no, `-if` conditionally processes files, so files without GPSLatitude would be excluded entirely from the output. Let me use this approach. But wait, the `-if` flag syntax: `-if '$GPSLatitude'` checks if the GPSLatitude tag exists and is non-zero. For coordinates at 0° latitude (which would be near the equator/Gulf of Guinea), this would be false! Better to use: `-if 'defined $GPSLatitude'` which checks if the tag exists regardless of its value. Or even: `-if '$GPSLatitude ne ""'` to check for non-empty. Hmm, but with `-n`, GPSLatitude is a number, not a string. Let me use `-if 'defined $GPSLatitude'`. Let me include this optimization. OK, TRULY final script now: ```bash #!/usr/bin/env bash # # photo_gps_to_geojson.sh # # Scans a directory of photos with exiftool, extracts GPS coordinates # at full EXIF precision, and outputs GeoJSON (RFC 7946). # # Usage: # ./photo_gps_to_geojson.sh [output.geojson] # ./photo_gps_to_geojson.sh ~/Pictures > map.geojson # # Dependencies: exiftool, jq set -euo pipefail # ── Args ───────────────────────────────────────────────────────────── PHOTO_DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" [[ -d "$PHOTO_DIR" ]] || { echo "Error: not a directory: $PHOTO_DIR" >&2; exit 1; } for cmd in exiftool jq; do command -v "$cmd" &>/dev/null || { echo "Error: '$cmd' not found in PATH" >&2; exit 1; } done # ── Build GeoJSON ──────────────────────────────────────────────────── # # exiftool notes: # -n Numeric output: GPS tags as decimal-degree floats # -r Recurse into subdirectories # -json Output one JSON object per file # -if 'defined ...' Skip files that lack the tag (much faster) # # Precision: # EXIF GPS stores coordinates as DMS with rational (fractional) values. # Typical rational precision: 1/100 s → ~0.3 m. # exiftool converts to IEEE 754 doubles (~15 significant digits), # preserving every bit of the original EXIF data. # # GeoJSON coordinates: [longitude, latitude] per RFC 7946 §3.1.1 exiftool -json -n -r \ -if 'defined $GPSLatitude' \ -ext jpg -ext jpeg -ext jpe \ -ext tiff -ext tif -ext png \ -ext heic -ext heif -ext webp \ -ext dng -ext cr2 -ext cr3 -ext crw \ -ext nef -ext nrw -ext arw -ext sr2 \ -ext rw2 -ext raf -ext orf -ext raw \ -ext pef -ext srw -ext x3f \ -GPSLatitude -GPSLatitudeRef \ -GPSLongitude -GPSLongitudeRef \ -GPSAltitude -GPSAltitudeRef \ -GPSDateTime -GPSDateStamp -GPSTimeStamp \ "$PHOTO_DIR" 2>/dev/null | jq ' # Resolve hemisphere sign. Handles both "N"/"S" and "North"/"South". def sign(ref; negative_prefix): if ((ref // "") | test("^\(negative_prefix)")) then -1 else 1 end; { type: "FeatureCollection", features: [ .[] | { type: "Feature", geometry: { type: "Point", coordinates: ( [ .GPSLongitude * sign(.GPSLongitudeRef; "W"), .GPSLatitude * sign(.GPSLatitudeRef; "S") ] + if .GPSAltitude then [.GPSAltitude] else [] end ) }, properties: { file: .SourceFile, filename: .FileName, latitude: (.GPSLatitude * sign(.GPSLatitudeRef; "S")), longitude: (.GPSLongitude * sign(.GPSLongitudeRef; "W")), altitude_m: .GPSAltitude, timestamp: (.GPSDateTime // .GPSDateStamp // null) } } ] }' > "$OUTPUT" echo "✓ $(jq '.features | length' "$OUTPUT" 2>/dev/null || echo '?') geotagged photos → $OUTPUT" >&2 ``` Wait, there's a problem with the jq function definition. In jq, `def sign(ref; negative_prefix):` takes parameters, but using it like `sign(.GPSLatitudeRef; "S")` means `ref` and `negative_prefix` are the arguments. But inside the def, I'm using `ref` which would be the value of `.GPSLatitudeRef` at that point, and `negative_prefix` which would be "S". The `test` function call with string interpolation might be tricky. Let me simplify. Instead of a function, let me just use inline expressions: ```jq ( if ((.GPSLatitudeRef // "") | test("^[Ss]")) then -1 else 1 end ) as $lat_sign | ( if ((.GPSLongitudeRef // "") | test("^[Ww]")) then -1 else 1 end ) as $lon_sign | ``` This is cleaner and avoids the function definition complexity. Let me also reconsider: is the `timestamp` property worth adding? The user asked specifically for coordinates. Let me include it as a bonus but keep the focus on coordinates. Also, I included `-GPSDateTime -GPSDateStamp -GPSTimeStamp` in the exiftool command. These are useful metadata but add complexity. Let me keep them for completeness. Actually, I just realized I should also extract `GPSHPositioningError` (horizontal positioning error in meters) if available. This tells you how accurate the GPS fix is. But this is a less common tag and I don't want to overcomplicate things. Let me skip it. Let me write the absolute final version now. I'll keep it clean, well-commented, and focused. Oh wait, one more thing. The exiftool `-if` condition `defined $GPSLatitude` - does this work with the `-json` flag? Let me think... `-if` is a file-level filter. Files that don't match the condition are skipped entirely. In JSON mode, they simply don't appear in the output array. This should work correctly. But actually, I realize there might be an issue. When using `-if 'defined $GPSLatitude'`, exiftool evaluates this condition for each file. If a file has GPSLatitude defined, it's included. The `-json` flag then outputs only the matching files. This is correct and efficient. However, I just thought of something: the `defined` function in exiftool's `-if` expressions checks if the tag exists in the file's metadata. This is the correct way to check. OK, I'm confident the script is correct. Let me write it out cleanly. Hmm, actually let me reconsider whether to include timestamp tags. Adding more tags to the exiftool command means more data to parse, but it doesn't significantly impact performance. And having timestamps in the GeoJSON properties is genuinely useful. Let me keep them. Let me also add the `GPSHPositioningError` tag since newer phones report it: No, let me not. The user asked for coordinates. I'll add a comment about how to extend the script. Final version: ```bash #!/usr/bin/env bash #───────────────────────────────────────────────────────────────────── # photo_gps_to_geojson.sh # # Scans a directory of photos, extracts GPS coordinates at full EXIF # precision using exiftool, and writes a GeoJSON FeatureCollection. # # Usage # ./photo_gps_to_geojson.sh [output.geojson] # ./photo_gps_to_geojson.sh ~/Pictures/2024 vacation.geojson # # The output file defaults to stdout when omitted. # ───────────────────────────────────────────────────────────────────── set -euo pipefail PHOTO_DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" [[ -d "$PHOTO_DIR" ]] || { echo "Error: not a directory: $PHOTO_DIR" >&2; exit 1; } for cmd in exiftool jq; do command -v "$cmd" &>/dev/null || { echo "Error: '$cmd' is required but not found." >&2; exit 1; } done # ── Extract & transform ───────────────────────────────────────────── # exiftool flags: # -n numeric output (decimal degrees, not DMS strings) # -r recurse into subdirectories # -json emit a JSON array of per-file tag objects # -if 'defined $GPSLatitude' skip non-geotagged files (fast path) # # Precision note: # EXIF GPS coordinates are stored as DMS rational numbers. # exiftool -n converts them to IEEE 754 doubles (~15 sig. digits), # preserving every bit of the original data. For a typical camera # that stores seconds to 1/100, that's roughly ±0.3 m; many phones # and drones store more. # # GeoJSON (RFC 7946) coordinate order: [longitude, latitude, altitude] exiftool -json -n -r \ -if 'defined $GPSLatitude' \ -ext jpg -ext jpeg -ext jpe \ -ext tiff -ext tif -ext png \ -ext heic -ext heif -ext webp \ -ext dng -ext cr2 -ext cr3 \ -ext nef -ext arw -ext rw2 \ -ext raf -ext orf -ext pef \ -ext raw -ext sr2 -ext srw \ -GPSLatitude -GPSLatitudeRef \ -GPSLongitude -GPSLongitudeRef \ -GPSAltitude \ "$PHOTO_DIR" 2>/dev/null | jq '{ type: "FeatureCollection", features: [ .[] # Derive sign from hemisphere reference # (handles both "N"/"S" and "North"/"South" formats) | (if (.GPSLatitudeRef // "" | test("^[Ss]")) then -1 else 1 end) as $lat_s | (if (.GPSLongitudeRef // "" | test("^[Ww]")) then -1 else 1 end) as $lon_s | { type: "Feature", geometry: { type: "Point", coordinates: [ .GPSLongitude * $lon_s, .GPSLatitude * $lat_s ] + if .GPSAltitude then [.GPSAltitude] else [] end }, properties: { file: .SourceFile, filename: .FileName, latitude: (.GPSLatitude * $lat_s), longitude: (.GPSLongitude * $lon_s), altitude_m: (.GPSAltitude // null) } } ] }' > "$OUTPUT" # ── Summary ────────────────────────────────────────────────────────── count=$(jq '.features | length' "$OUTPUT" 2>/dev/null) echo "✓ $count geotagged photo(s) → $OUTPUT" >&2 ``` This looks good. Let me review it one more time... One issue: the `count` line at the end reads from `$OUTPUT` which might be `/dev/stdout`. If we already wrote to stdout, reading from it again won't work. Let me fix this: If `$OUTPUT` is `/dev/stdout`, we can't re-read it. So the summary should only work when output is a file. Let me handle this: ```bash if [[ "$OUTPUT" != "/dev/stdout" ]]; then count=$(jq '.features | length' "$OUTPUT" 2>/dev/null) echo "✓ $count geotagged photo(s) → $OUTPUT" >&2 else echo "✓ GeoJSON written to stdout" >&2 fi ``` Actually, this is getting complicated. Let me simplify. I can count the features during the jq processing and output the count to stderr. Or I can just remove the summary line. Or I can use a tee-like approach. Simplest: remove the summary or use a different approach. Let me redirect the jq output to a temporary variable or file, then read from it. Or: use process substitution. Or: count in jq and output the count to stderr. Actually, the cleanest approach: output the count as part of the jq processing, or use a separate counter. Let me just simplify and remove the summary line, or make it conditional: ```bash if [[ -f "$OUTPUT" ]]; then count=$(jq '.features | length' "$OUTPUT") echo "✓ $count geotagged photo(s) → $OUTPUT" >&2 fi ``` This is good enough. If output goes to stdout (not a file), we skip the summary. If it goes to a file, we show the count. Actually, wait. The `-f` test checks if the file exists and is a regular file. After writing to `$OUTPUT` with `>`, the file should exist. But what if `$OUTPUT` is `/dev/stdout`? `/dev/stdout` exists but is not a regular file. So `-f` would return false for `/dev/stdout`. So: ```bash if [[ -f "$OUTPUT" ]]; then count=$(jq '.features | length' "$OUTPUT") echo "✓ $count geotagged photo(s) → $OUTPUT" >&2 else echo "✓ GeoJSON written to stdout" >&2 fi ``` This works. Let me include this in the final script. Wait, but now I realize there might be a more subtle issue. If the user provides an output path but the file doesn't exist yet (it gets created by the `>` redirect), does `-f` check the newly created file? After the `jq ... > "$OUTPUT"` command completes, the file should exist. So yes, `-f` should work. OK, let me finalize now. Here's the complete script: Actually, let me reconsider one more time whether to include the altitude in the coordinates array conditionally. The GeoJSON spec (RFC 7946) says: > A position is an array of numbers. There MUST be two or more elements. The first two elements are longitude and latitude, or easting and northing, precisely in that order and using decimal numbers. Altitude or elevation MAY be included as an optional third element. So including altitude as an optional third element is perfectly valid. My approach of: ``` [.GPSLongitude * $lon_s, .GPSLatitude * $lat_s] + if .GPSAltitude then [.GPSAltitude] else [] end ``` is correct. One edge case: what if `GPSAltitude` is 0? In jq, `if 0 then ... else ... end` is false (0 is falsy in jq). So a photo taken at exactly sea level would NOT include altitude. This is technically a bug, but in practice, photos at exactly 0m altitude are rare, and the altitude being absent is acceptable. For robustness, I could use `if .GPSAltitude != null then [.GPSAltitude] else [] end`: ``` + if .GPSAltitude != null then [.GPSAltitude] else [] end ``` This is better. Let me use this. Actually, wait. The `.GPSAltitude` for a file that doesn't have GPSAltitude would be null (the key would be missing, which jq treats as null). And `null != null` is false, so it would correctly produce `[]`. For a file that has GPSAltitude = 0, `0 != null` is true, so it would correctly produce `[0]`. OK, now truly final version. Let me also add a `-h` / `--help` option for good measure. Actually no, let me keep it simple. The usage comment at the top is enough. Let me also reconsider whether to recommend specific installation methods. Different distros have different package names: - Debian/Ubuntu: `sudo apt install libimage-exiftool-perl jq` - macOS: `brew install exiftool jq` - Fedora: `sudo dnf install perl-Image-ExifTool jq` I'll mention this in the header comment. Final final final script: ```bash #!/usr/bin/env bash # ═══════════════════════════════════════════════════════════════════════ # photo_gps_to_geojson.sh # # Scans a directory of photos using exiftool, extracts embedded GPS # coordinates at full EXIF precision, and writes a GeoJSON # FeatureCollection (RFC 7946). # # Usage: # ./photo_gps_to_geojson.sh [output.geojson] # # Examples: # ./photo_gps_to_geojson.sh ~/vacation-photos/ # ./photo_gps_to_geojson.sh ./pics result.geojson # # Dependencies: # exiftool — https://exiftool.org # Debian/Ubuntu : sudo apt install libimage-exiftool-perl # macOS (Homebrew): brew install exiftool # Fedora/RHEL : sudo dnf install perl-Image-ExifTool # jq — lightweight command-line JSON processor # Debian/Ubuntu : sudo apt install jq # macOS : brew install jq # Fedora/RHEL : sudo dnf install jq # # How precision works: # EXIF GPS coordinates are stored as degrees/minutes/seconds using # unsigned rational numbers (e.g. 3000/100 = 30.00 seconds). # exiftool's -n flag converts these to IEEE 754 double-precision # floats (~15 significant digits), which preserves every bit of # the original EXIF data. For a camera that stores seconds to # 1/100 s, that's≈0.3 m precision; phones/drones may be finer. # ═══════════════════════════════════════════════════════════════════════ set -euo pipefail # ── Argument handling ──────────────────────────────────────────────── PHOTO_DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" [[ -d "$PHOTO_DIR" ]] || { echo "Error: '$PHOTO_DIR' is not a directory." >&2 exit 1 } # ── Dependency check ──────────────────────────────────────────────── for cmd in exiftool jq; do command -v "$cmd" &>/dev/null || { echo "Error: '$cmd' is required but not found in PATH." >&2 exit 1 } done # ── Supported image extensions ────────────────────────────────────── # Common RAW, raster, and mobile formats. EXTENSIONS=( -ext jpg -ext jpeg -ext jpe -ext tiff -ext tif -ext png -ext heic -ext heif -ext webp -ext dng -ext cr2 -ext cr3 -ext crw -ext nef -ext nrw -ext arw -ext sr2 -ext rw2 -ext raf -ext orf -ext raw -ext pef -ext srw -ext x3f ) # ── Extract GPS data & build GeoJSON ──────────────────────────────── # # exiftool flags used: # -n Numeric mode (decimal degrees, not DMS) # -r Recurse into sub-directories # -json Emit a JSON array (one object per file) # -if 'defined $GPSLatitude' Fast-skip non-geotagged files # # GeoJSON coordinate order (RFC 7946 §3.1.1): # [longitude, latitude] or [longitude, latitude, altitude] exiftool "${EXTENSIONS[@]}" -json -n -r \ -if 'defined $GPSLatitude' \ -GPSLatitude -GPSLatitudeRef \ -GPSLongitude -GPSLongitudeRef \ -GPSAltitude \ "$PHOTO_DIR" 2>/dev/null | jq ' { type: "FeatureCollection", features: [ .[] # Derive sign from hemisphere reference. # Matches both "N"/"S" and "North"/"South" (and lowercase). | (if (.GPSLatitudeRef // "" | test("^[Ss]")) then -1 else 1 end) as $lat_s | (if (.GPSLongitudeRef // "" | test("^[Ww]")) then -1 else 1 end) as $lon_s | { type: "Feature", geometry: { type: "Point", coordinates: [ .GPSLongitude * $lon_s, .GPSLatitude * $lat_s ] + (if .GPSAltitude != null then [.GPSAltitude] else [] end) }, properties: { file: .SourceFile, filename: .FileName, latitude: (.GPSLatitude * $lat_s), longitude: (.GPSLongitude * $lon_s), altitude_m: (.GPSAltitude // null) } } ] } ' > "$OUTPUT" # ── Summary ────────────────────────────────────────────────────────── if [[ -f "$OUTPUT" ]]; then n=$(jq '.features | length' "$OUTPUT") echo "✓ $n geotagged photo(s) written to $OUTPUT" >&2 else echo "✓ GeoJSON written to stdout" >&2 fi ``` This looks clean and comprehensive. Let me do a final review: 1. ✅ Uses exiftool 2. ✅ Scans a directory of photos 3. ✅ Extracts coordinates at maximum precision (-n flag) 4. ✅ Formats as GeoJSON 5. ✅ Handles N/S and E/W hemisphere references6. ✅ Includes altitude when available 7. ✅ Recursive scanning 8. ✅ Fast-skip of non-geotagged files 9. ✅ Supports many image formats including RAW 10. ✅ Good error handling 11. ✅ Well-documented I'm satisfied with this script. Let me present it to the user with some explanation. ```bash #!/usr/bin/env bash # ═══════════════════════════════════════════════════════════════════════ # photo_gps_to_geojson.sh # # Scans a directory of photos using exiftool, extracts embedded GPS # coordinates at full EXIF precision, and writes a GeoJSON # FeatureCollection (RFC 7946). # # Usage: # ./photo_gps_to_geojson.sh [output.geojson] # # Examples: # ./photo_gps_to_geojson.sh ~/vacation-photos/ # ./photo_gps_to_geojson.sh ./pics result.geojson # # Dependencies: # exiftool — https://exiftool.org # Debian/Ubuntu : sudo apt install libimage-exiftool-perl # macOS (brew) : brew install exiftool # Fedora/RHEL : sudo dnf install perl-Image-ExifTool # jq — lightweight command-line JSON processor # Debian/Ubuntu : sudo apt install jq # macOS : brew install jq # Fedora/RHEL : sudo dnf install jq # # How precision works: # EXIF GPS data is stored as degrees/minutes/seconds using unsigned # rational numbers (e.g. 3456/100 = 34.56 seconds). exiftool's -n # flag converts these to IEEE 754 doubles (~15 significant digits), # preserving every bit of the original EXIF data. A camera storing # seconds to 1/100 s gives ≈0.3 m precision; phones/drones can be # finer. # ═══════════════════════════════════════════════════════════════════════ set -euo pipefail # ── Argument handling ──────────────────────────────────────────────── PHOTO_DIR="${1:?Usage: $0 [output_file]}" OUTPUT="${2:-/dev/stdout}" [[ -d "$PHOTO_DIR" ]] || { echo "Error: '$PHOTO_DIR' is not a directory." >&2 exit 1 } # ── Dependency check ──────────────────────────────────────────────── for cmd in exiftool jq; do command -v "$cmd" &>/dev/null || { echo "Error: '$cmd' is required but not found in PATH." >&2 exit 1 } done # ── Supported image extensions ────────────────────────────────────── EXTENSIONS=( -ext jpg -ext jpeg -ext jpe -ext tiff -ext tif -ext png -ext heic -ext heif -ext webp -ext dng -ext cr2 -ext cr3 -ext crw -ext nef -ext nrw -ext arw -ext sr2 -ext rw2 -ext raf -ext orf -ext raw -ext pef -ext srw -ext x3f ) # ── Extract GPS data & build GeoJSON ──────────────────────────────── # # exiftool flags: # -n Numeric mode (decimal degrees, not DMS) # -r Recurse into sub-directories # -json Emit a JSON array (one object per file) # -if 'defined $GPSLatitude' Fast-skip non-geotagged files # # GeoJSON coordinate order per RFC 7946 §3.1.1: # [longitude, latitude] or [longitude, latitude, altitude] exiftool "${EXTENSIONS[@]}" -json -n -r \ -if 'defined $GPSLatitude' \ -GPSLatitude -GPSLatitudeRef \ -GPSLongitude -GPSLongitudeRef \ -GPSAltitude \ "$PHOTO_DIR" 2>/dev/null | jq ' { type: "FeatureCollection", features: [ .[] # Derive sign from hemisphere reference. # Matches both "N"/"S" and "North"/"South" (and lowercase). | (if (.GPSLatitudeRef // "" | test("^[Ss]")) then -1 else 1 end) as $lat_s | (if (.GPSLongitudeRef // "" | test("^[Ww]")) then -1 else 1 end) as $lon_s | { type: "Feature", geometry: { type: "Point", coordinates: [ .GPSLongitude * $lon_s, .GPSLatitude * $lat_s ] + (if .GPSAltitude != null then [.GPSAltitude] else [] end) }, properties: { file: .SourceFile, filename: .FileName, latitude: (.GPSLatitude * $lat_s), longitude: (.GPSLongitude * $lon_s), altitude_m: (.GPSAltitude // null) } } ] } ' > "$OUTPUT" # ── Summary ────────────────────────────────────────────────────────── if [[ -f "$OUTPUT" ]]; then n=$(jq '.features | length' "$OUTPUT") echo "✓ $n geotagged photo(s) → $OUTPUT" >&2 else echo "✓ GeoJSON written to stdout" >&2 fi ``` ## What it does | Step | Detail | |---|---| | **Scanning** | `exiftool -r` recurses through the directory; `-if 'defined $GPSLatitude'` fast-skips any file without GPS data (no empty objects in the output). | | **Precision** | `-n` tells exiftool to output GPS coordinates as raw decimal-degree floats instead of DMS strings. EXIF stores these as rational numbers (e.g. `34567/1000`); the conversion to IEEE 754 doubles (~15 significant digits) preserves **every bit** of the original data—typically **±0.3 m** for consumer cameras, finer for phones/drones. | | **Hemisphere sign** | EXIF stores coordinates as unsigned values + a separate N/S, E/W reference. The `jq` filter checks `GPSLatitudeRef` / `GPSLongitudeRef` (handles both `"S"` and `"South"`) and negates accordingly. | | **Altitude** | Included as the optional third coordinate **only when present** (per RFC 7946 §3.1.1). | ## Example output ```json { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Point", "coordinates": [-0.1275510, 51.5073510, 11.0] }, "properties": { "file": "/home/me/Pics/london.jpg", "filename": "london.jpg", "latitude": 51.5073510, "longitude": -0.1275510, "altitude_m": 11.0 } } ] } ``` > **Tip:** To load this in a map viewer, save to a `.geojson` file and open it in [geojson.io](https://geojson.io), QGIS, Google Earth, etc.

Geospatial bash prompt