Q: Photos crashes when Removing Location

Your experience is quite different than mine. Odd. But then, we Photos is an odd beast.

My Lumix ZS40 supports a Home time and a Destination time. I like to adjust the camera's time to the local time at my destination so the time stamps on each picture line up with 'real time' as we tour around.  (IE, that picture was at lunch in Barcelona, that picture was the afternoon walk around Lisbon, etc ). On this particular vacation, we jumped back and forth between GMT+2 and GMT+1 as we traveled from Barcelona to Lisbon to France to London, so I would adjust the camera's timezone accordingly.

Upon return, I removed the SD card, popped it in my rMBP and imported the lot - 756 pictures. The Mac's system time was set to Eastern (GMT-4) since that's where I live.

I have similar examples to yours of pictures taken in close succession, but they aren't adjacent when viewed in Moments. One or more are displaced in the timeline, typically by 2 or 6 hours. I looked closely at the metadata for the 'misplaced' pictures, and found that Photos is inconsistent in the location (and hence timezone) that is assigns to the pictures. (the location/timezone is revealed in the Adjust Date & Time Window).  Some pictures will show the proper location, where the picture was taken (e.g., Barcelona) and thus assume Barcelona's time zone.  Others will have a blank in the Closest City field, and assume GMT.  Others will show Toronto as nearest city and use GMT-4.   When Photos decides how to order my pictures in Moments, I've deduced that it's using the timestamp (hh:mm:ss) together with the timezone that's assigned to each picture.  So two pictures with near-identical hh:mm:ss can be hours apart in the timeline.

That's how I explain the behavior that I've observed. But's it a mystery why pictures taken in close succession with identical GPS coordinates aren't assigned the same Closest City and timezone by Photos. I've noticed that Photos is throwing lots of errors in the Console log, but they are inscrutable to mere mortals...

@Léonie,

Thanks very much for your handy script to extract the GPS values from photos.  Using it, I was able to confirm what I had suspected. My Lumix is writing bogus lat/long values into the EXIF (17056881.853375 for both). Apple's Photos program then gags on the values. It won't let me change the location on such pictures to someplace else, and it crashes when I try to Remove the bad location info.

To verify that this is really a Lumix defect (and not a bug in Photos when it does the import), and did a test a by copying a couple of the affected JPGs directly from the SD card onto my MBP.  Then used a web tool (http://www.viewexifdata.com/index.php) to inspect the EXIF data.  It shows the same bad lat/long values.

To fix the bad GPS values, I might try what Larry suggested: export the affected images from Photos, remove the bad location info with Preview, and then re-import.  Having done that, I'll then be able to manually assign the correct location.  Unfortunately, there are an awful lot of them to fix (hundreds), and fixing each one manually is a lot of work. Alternately, I could fix them on the SD card (or a copy thereof), and re-import.

As I mentioned before, some of the imported photos arrive with no GPS data whatsoever, usually when I had forgotten to turn the Lumix' GPS receiver on.  Your Extract script is also very handy for copying location from one picture and pasting it into another.  So thanks again for that capability:-)

Besides the bad GPS data, the other issue I'm struggling with is the horrendous way that Photos deals with ordering the pictures.  My problem is not due to a mix of still images and movies like you described. All of mine are still images. I have numerous examples where three JPEGs taken in close succession (and imported at the same time) will end up with three different timezones assigned after being imported.  One will have Closest City = Barcelona (where the picture was taken).  Another will have Closest City = <blank>. And another will have Closest City = Toronto (where the import was done).   To determine location on the timeline, Photos applies different timezone offsets based on what it thinks is the closest city: in the example above, one gets GMT+2, one gets GMT, and the last gets GMT-4.   So the three photos, with near identical timestamps and filenames (P1010xxx.JPG) will be scattered all over the timeline.

I've spent most of the weekend going through all 700+ shots and manually adjusting them as required:-(

Léonie, Larry, and other readers who may stumble by,

Armed with knowledge of the bad GPS value that causes Photos to crash (17056881.853375), I asked Ms. Google about it.  Turns out there is a known defect in several models of Lumix cameras, including my ZS-40 (a.k.a. TZ-60).  I found many postings on several photo/camera websites reporting that this value gets written into the EXIF GPS tag when the camera has poor GPS lock, has just been awakened, or entirely at random (i.e. one picture gets good GPS data, the next gets <17056881.853375,17056881.853375>, the next gets good...), even when the camera has a clear view of the sky.   I learned that Apple Photos is not the only photo processing program that crashes when it encounters such lat/long values.

Other owners of the ZS-40 have reported the bug to Panasonic, who dutifully replied that it is 'expected behavior', and that one should turn off the GPS function if you don't want bad data recorded in the EXIF. 

@Larry,

A couple of follow-ups.

1) You had indeed suggested HoudahGeo, which triggered a distant synapse reminding me that I bought it years ago (when I used a GPS logger). So I dusted it off and tried it out.  The 'correct using nearby photo' feature didn't work.   I contacted the developer (Pierre) who was exceedingly helpful.  He added a bit of code to HG that properly deals with the out-of-bounds lat/long values that the Lumix writes to the EXIF. He just released that version today (5.0.2). It can either erase, or overwrite the bad lat/long values.  Unfortunately, once the images (with out-of-bounds values) have been imported into Photos, it's too late to do anything about it.  HoudahGeo has to clean them up before they are imported.

2) Further investigation of the problem (using exiftool) revealed that the Lumix ZS40 writes bad values <17056881.666667> to the lat & long tags when it does not have sat lock, but it also writes the value "V" ( for Void) to the GPSStatus tag.   It puts the value "A" (for Active) in GPSStatus when it has sat lock (and hence has obtained legitimate lat/long values).   In other words, it's telling the world that the values in the lat/long tags are not relevant. Unfortunately, Photos ignores the setting of GPSStatus. The new version of HoudahGeo also changes the GPSStatus flag to "A" when it geo-codes image files. (it didn't prior to 5.0.2.

3) I reported two bugs to Apple via their /feedback page (the crashes and the out-of-order issue). Yesterday, I received two e-mails from Apple following up. They've requested crash logs and other diagnostic reports so they can investigate. Perhaps a new version of Photos will be forthcoming.

Previously I wrote:

Other owners of the ZS-40 have reported the bug to Panasonic, who dutifully replied that it is 'expected behavior', and that one should turn off the GPS function if you don't want bad data recorded in the EXIF.

Further research into this reveals that the behavior of the Panasonic Lumix ZS-40 is actually within spec.  When its GPS receiver does not have good location information (no 'lock' on a sufficient number of GPS satellites),  it writes out-of-bounds values (17056881.853375) into the lat and long tags in the EXIF. However, it also writes the value "V" (for void) into the GPSStatus tag, indicating that the lat/long values are not relevant. 

However, I did uncover a genuine bug in the Lumix ZS-40 firmware. A fair number of my images have incorrect values in the GPS Date and Time fields. The bad date in affected images is always 5 days later than it should be. The bad timestamp will be based on the camera's local time, not UTC.  (all GPS satellites broadcast date and time signals, the time value being in UTC).   The Lumix is supposed to be writing absolute (UTC) time into the GPS Time tag, but sometimes, it screws up.  These incorrect date & time values seem to occur on the first picture taken just after the camera has been turned on (within a few seconds).  Some geo-processing programs (HoudahGeo, for one) use the values in the GPS Date and Time tags to do some intelligent processing on the information in the EXIF.

This tidbit actually has nothing to do with the topic of this thread. I've posted it here so that Ms. Google will index it for the benefit of other owners of the Panasonic Lumix ZS40 (a.k.a. TZ60) who may someday come across this post.