Map page is blank, was working earlier

[rgry]

First, Thank you for a great hack! Even though I think Adobe should have fixed it in the first place....

I had you fix running on my mac for over a year now, but not it does not work any more? Just for testing I installed LR6 on my windows and gone through the steps and it does not work here either? Map page is kind of blank? Not showing any errors?

I'm I the only one? or did Adobe/Google change something? Where do I look for a log?

[astuder]

adrianstuder

done

Thanks! I replaced the .lua files with yours, and the map still doesn't work. :(

Can you check in your Google Cloud Console if you see API calls around 14:50 PDT (UTC-7)?

[cyr06]

My log is empty and I sent you the data of my console

[Tibashoult]

OK, the lua file should be in setting folder, but the log are in Documents folder. Attached my files. AgGPSLocationSupport.log LocationContentQueries.log LocationSelectionController.log LocationUndoActions.log LocationViewController.log

[astuder]

Careful with posting logs. I didn't see any API keys, but you never know without going through them in detail.

[Tibashoult]

Thanks, I had checked before to post the files

[jbd7]

@astuder Coming here after maps stop showing in LR. I had patched my Location.lrmodule a long time ago and it helped very well so far, thanks!

Since this month, the Map view is empty but it only looks like the Display is off: looking for a location seem to work (searching for Berlin returns "Berlin, Germany", a black overlay popup looks like it's centering the map on it.) I. the Google console, I get hits on the Geocoding API, but 0 on Maps Javascript API.

I enabled the logging with

-- BEGIN
loggers["AgReverseGeocodeService"] = {
    logLevel = 'trace',
    action = 'logfile',
}

loggers["Location"] = {
  logLevel = 'trace',
  action = 'logfile',
}
-- END

and can see these files being generated:

23/03/2023  14:01           271,842 AgGPSLocationSupport.log
23/03/2023  14:02         1,908,336 AgReverseGeocodeService.log
23/03/2023  14:05             1,148 LocationContentQueries.log
23/03/2023  14:08           552,474 LocationMapView.log
23/03/2023  14:05             2,910 LocationSelectionController.log
23/03/2023  14:05             2,902 LocationViewController.log

My AgGPSLocationSupport.log looks like the one posted by @Tibashoult 3 days ago. I think the most interesting one is LocationMapView.log, it gains ~1 KB per second wile LR is open, and populates with these same 2 blocks:

03/23/2023 14:03:11 TRACE   CALLBACK: clearJSResults 
03/23/2023 14:03:13 TRACE   callScript   bounceMarker 
03/23/2023 14:03:13 TRACE   {
    var markerId = "";

    if ( bouncingMarker ) {
        if ( bouncingMarker.setAnimation )
            bouncingMarker.setAnimation( null );
        bouncingMarker = null;
    }

    if ( markerId && markerId != "" && markersMap[ markerId ] ) {
        bouncingMarker = markersMap[ markerId ];
        if ( bouncingMarker && bouncingMarker.setAnimation && google.maps.Animation ) {
            bouncingMarker.setAnimation( google.maps.Animation.BOUNCE );
        }
    }
}

03/23/2023 14:03:13 TRACE   CALLBACK: clearJSResults 

and

03/23/2023 14:11:32 TRACE   CALLBACK: clearJSResults 
03/23/2023 14:11:33 TRACE   callScript    
03/23/2023 14:11:33 TRACE   if ( map != null ) {
    var result = map.getBounds();
    if( result != null ) {
        var ne = result.getNorthEast();
        var sw = result.getSouthWest();
        callCallback( "sendJSResults", "012345F-4A64-42D1-B295-ABC123ABC123", ne.lat(), ne.lng(), sw.lat(), sw.lng() );
    }
}

I didn't see any API key in the logs. I did a fair amount of geoencoding on the first week of Feb, didn't use the Maps module until yesterday, didn't modify my LR6 install, so I would guess something has changed on the Google API side in the past 6 weeks (possibly one of these changes: https://developers.google.com/maps/documentation/javascript/releases). I only see green ticks, no red flags, in my Google Console billing section. I updated my CC there (the Primary one was no longer active, but Google didn't seem to have noticed) and the monthly invoice a few cents (within free quota), but it didn't impact Lightroom.

Let me know if I can help further. I attach here the log from LocationMapView.log collected during the 10 seconds of the boot of LR6 directly into the Maps module, which remains empty.

LocationMapView - bootsequence.log

[jbd7]

OK, I fixed mine! 😀

It seems the March 2023 deprecation of some properties by Google was responsible: https://developers.google.com/maps/documentation/javascript/releases#3.52.5

Instead of playing with the LUA file to figure out how to update it and make it compatible with the new Maps API, I actually forced it to use the version from February 2023 (v3.51) instead. This is probably not meant to last (even less than the current fixes) but at least it buys us time until someone else does a "proper" fix, if relevant :)

Steps to follow:

• Open the great tutorial on https://github.com/astuder/lightroom-map-fix
• Follow or re-follow the same steps, and at Step 6, when patching the LOCATIONMAPVIEW.LUA resource, add the following replacement: patchluastr.exe LOCATIONMAPVIEWpatched.LUA "sensor=false" "sensor=false&v=3.51" -o LOCATIONMAPVIEWpatchedandversioned.bin . What this does is: look for calls to googleapis, and add a version parameter in the URL. I figured out "sensor=false" was there in the 3 URLs. I am not sure the 3 replacements are necessary.

In my case, on Windows, I patched the LUA resource that was already patched from @astuder 's previous instructions. The output of patchluastr.exe is:

Processing LOCATIONMAPVIEWpatched.LUA.bin
Lua 5.1 detected
Lua settings: endian 1, int 4, size_t 8, instruction 4, number 4
119494 bytes read from file
Found 'sensor=false' at 10484
Found 'sensor=false' at 21170
Found 'sensor=false' at 21478
Updated 3 strings
119515 bytes written to LOCATIONMAPVIEWpatchedandversioned.bin

After replacing that repatched LUA resource in the Location.lrmodule, and restarting LR, my Map re-appeared.

Happy patching!

Warning: I just did it, and didn't thoroughly test all other geo features.

[Tibashoult]

JDB7 many thanks guy.

I confirm, it's works. Just a precision of your procedure, you should copy your file LOCATIONMAPVIEW.bin to LOCATIONMAPVIEWpatched.LUA and not use your (non patched) LOCATIONMAPVIEW.LUA to LOCATIONMAPVIEWpatchedLUA.

Just now to chekc how long this patched will be works (version 3.51 can be desactivated by google later ?).

[astuder]

Thanks @jbd7 !!

I played with the version number earlier, using the one from the GeoSetter thread. But I didn't think about using that new of an API version. I guess Google serves up the latest version if the requested version is too old.

There's Lua code that sets the preferred API version:

L33_1.last_stable = "3.12"
L33_1.latest_nightly = ""
L34_1 = L33_1.last_stable
L32_1.PREFERRED_API_VERSION = L34_1
L34_1 = L7_1.LocationModule_api_version
if not L34_1 then
  L34_1 = L0_1.locationModule
  L34_1 = L34_1.api_version
  if not L34_1 then
    L34_1 = L32_1.PREFERRED_API_VERSION
  end
end

Which leads me to this new patch, which also works: python patchluastr.py LOCATIONMAPVIEW.bin "3.12" "3.51" -o LOCATIONMAPVIEW-version.bin

Your patch works, probably because your version field comes first in the final URL, but I think this alternative is a bit cleaner.

[jbd7]

Your patch works, probably because your version field comes first in the final URL, but I think this alternative is a bit cleaner.

Absolutely! I had not noticed there was a placeholder for the preferred API version.

I would also think that it could be possible to create a patch that doesn't force Location.lrmodule to use v3.51, which is bound to fail at some time (well, v3.12 was from 2013, so if we get another 10y out of this patch, it's still a small victory)(I would still recommend to move along with software releases, if you can :) ).

The breaking change introduced by v3.52.5 can be understood by looking at the code difference of the JS files (v3.51 vs v3.52.5). I've only spent an hour in the LocationMapView LUA resource, @astuder you would probably be able to tell how feasible it is. The breaking change seems to be about removing some features, including NEIGHBORHOOD, which appears in the LUA module at line 1601 in var darkStyle declaration, 4 lines before making a call to the API with new google.maps.StyledMapType( darkStyle, styledMapOptions ). I couldn't remove that line without rendering the resource file corrupt.

What does it matter? Only the last 4 versions are supported (12 months worth of updates), former ones are retired and if the requested version is not available, Google will serve the latest version. Source: https://groups.google.com/g/google-maps-js-api-v3-notify/c/3YkbMM9FWZ4. It means that this patch may fail as soon as May 2024. If we stay in McGyver mode, we could try to host this v3.51 version publicly and patch the LUA module to fetch it instead of from Google servers, but it could make it fail in another way.

[astuder]

The breaking change seems to be about removing some features, including NEIGHBORHOOD, which appears in the LUA module at line 1601 in var darkStyle declaration, 4 lines before making a call to the API with new google.maps.StyledMapType( darkStyle, styledMapOptions ). I couldn't remove that line without rendering the resource file corrupt.

Good sleuthing!

To fix that it's probably easier to use the patch file option (-p). Something along these lines should work to remove the offending property:

< { featureType: "administrative.province", elementType: "all", stylers: [ { lightness: -27 } ] },
> { featureType: "administrative.province", elementType: "all", stylers: [ { lightness: -27 } ] }
< { featureType: "administrative.neighborhood", elementType: "all", stylers: [ { lightness: -67 }, { gamma: 1.26 } ] }
>  

See hacks section in the README for examples of how to use a patch file.

[jbd7]

The breaking change seems to be about removing some features, including NEIGHBORHOOD, which appears in the LUA module at line 1601 in var darkStyle declaration, 4 lines before making a call to the API with new google.maps.StyledMapType( darkStyle, styledMapOptions ). I couldn't remove that line without rendering the resource file corrupt.

Good sleuthing!

To fix that it's probably easier to use the patch file option (-p). Something along these lines should work to remove the offending property:

< { featureType: "administrative.province", elementType: "all", stylers: [ { lightness: -27 } ] },
> { featureType: "administrative.province", elementType: "all", stylers: [ { lightness: -27 } ] }
< { featureType: "administrative.neighborhood", elementType: "all", stylers: [ { lightness: -67 }, { gamma: 1.26 } ] }
>  

See hacks section in the README for examples of how to use a patch file.

I just gave it a try. I didn't want to install Python on windows and realized that because a trailing comma in this array is still valid Javascript, I could just escape double quotes and replace that line with "", using your small patchluastr.exe.

Unfortunately it's not that simple and doesn't work.

There are mentions of the deprecated features (administrative_area_level_2 etc) elsewhere in the LUA resource, but surrounded by binary data in Notead++. How do you get to see clean LUA code as in your snippet on https://github.com/astuder/lightroom-map-fix/issues/41#issuecomment-1481751224 ? Is that somewhat editable and repackageable?

[astuder]

There are mentions of the deprecated features (administrative_area_level_2 etc) elsewhere in the LUA resource, but surrounded by binary data in Notead++. How do you get to see clean LUA code as in your snippet on #41 (comment) ? Is that somewhat editable and repackageable?

Sorry, missed your question.

I used unluac to decompile the Lua files. Unfortunately, they don't directly recompile due to some broken syntax (goto not supported by Lua 5.1). Without that, I don't know if its as simple as recompiling and replacing the resource.

For your reference, below the decompiled output for LOCATIONMAPVIEW. LOCATIONMAPVIEW.LUA.txt

[astuder]

I didn't want to install Python on windows

patchluastr.exe also supports the -p option, no need to install Python.

[jbd7]

Thanks!

I did a few more tries and managed to get the Map module to work (for me) without forcing the Maps API version to 3.51. It would mean that it has a higher chance to survive the year 2024:

From your decompiled module TXT file, without inserting 3.51 in the API URL or at line 142, I did:

• Removed line 2651, components.district = result.address_components[ comp ].long_name;
• Removed line 2657, components.level3 = result.address_components[ comp ].long_name;
• Removed line 5536, { featureType: "administrative.neighborhood", elementType: "all", stylers: [ { lightness: -67 }, { gamma: 1.26 } ] }

I incrementally removed lines, therefore these 3 removals may not all be required.

[astuder]

Great work!

As the patching procedure is getting more complex, I guess it's time to update patchluastr to do all the necessary steps in one go with just a patch file and the Google API key as command line parameters.

[jbd7]

That's a good idea, especially if you can leave the existing options allowing anyone to use the EXE file for custom patches.

Also, note that I've only tested the Map module loading on my machine once, it may be worth testing a bit more, for example on Mac, and within a tagging/editing Lightroom session, etc.

[Reinhard-S58]

Hi guys, I am very impressed about the work you have done. I have less experience about the work you have done but I want to use the LR6 map module further.

In November 2020 I changed the location.lrmodule as described in the great tutorial on https://github.com/astuder/lightroom-map-fix, therefore I have an own API-key. But now I am a little confused what I have to do to reanimate the map modul once more.

Please help me ....

[rgry]

Following this worked for me: https://github.com/astuder/lightroom-map-fix/issues/41#issuecomment-1481313640

[Reinhard-S58]

Thanks a lot, the job is done and the map module runs :-)

[diabWH3]

Great work!

As the patching procedure is getting more complex, I guess it's time to update patchluastr to do all the necessary steps in one go with just a patch file and the Google API key as command line parameters.

Has this been done? I've got Lightroom patched with the current lightroom-map-fix, but am having the blank map issues caused by the change in Google Maps API mentioned in this thread. It's been a long time since I did the original fix and am not confident in my use of Python. Is it possible to update the .exe to help make this process more dummy-resistant? :)

EDIT: I didn't use the patchluastr.exe when applying this fix a few years ago. However, I just read up on it and tried it with great success (cue: Borat GIF). Thanks a ton to this community for helping to keep this software limping along so many years after Adobe abandoned us for more cash.

[Peter-MI]

OK, I fixed mine! 😀

It seems the March 2023 deprecation of some properties by Google was responsible: https://developers.google.com/maps/documentation/javascript/releases#3.52.5

Instead of playing with the LUA file to figure out how to update it and make it compatible with the new Maps API, I actually forced it to use the version from February 2023 (v3.51) instead. This is probably not meant to last (even less than the current fixes) but at least it buys us time until someone else does a "proper" fix, if relevant :)

Steps to follow:

* Open the great tutorial on https://github.com/astuder/lightroom-map-fix

* Follow or re-follow the same steps, and at Step 6, when patching the LOCATIONMAPVIEW.LUA resource, add the following replacement:
  `patchluastr.exe LOCATIONMAPVIEWpatched.LUA "sensor=false" "sensor=false&v=3.51" -o LOCATIONMAPVIEWpatchedandversioned.bin` . What this does is: look for calls to googleapis, and add a version parameter in the URL. I figured out "sensor=false" was there in the 3 URLs. I am not sure the 3 replacements are necessary.

In my case, on Windows, I patched the LUA resource that was already patched from @astuder 's previous instructions. The output of patchluastr.exe is:

Processing LOCATIONMAPVIEWpatched.LUA.bin
Lua 5.1 detected
Lua settings: endian 1, int 4, size_t 8, instruction 4, number 4
119494 bytes read from file
Found 'sensor=false' at 10484
Found 'sensor=false' at 21170
Found 'sensor=false' at 21478
Updated 3 strings
119515 bytes written to LOCATIONMAPVIEWpatchedandversioned.bin

After replacing that repatched LUA resource in the Location.lrmodule, and restarting LR, my Map re-appeared.

Happy patching!

Warning: I just did it, and didn't thoroughly test all other geo features.

Great job! I also did on the already patched location.lrmodule - worked like a charm! Thank you very much!

[doobes]

Hoot!

Thanks to all who provided this fix.

I'm thinking about transitioning from LR to DigiKam and wanted to get all my metadata cleaned up before jumping into that mix.

chris

[teskeyn]

Thanks again for the March update( patchluastr.exe LOCATIONMAPVIEW.LUA "3.12" "3.51" -o LOCATIONMAPVIEW.bin) which I applied and got the Map back and working. but a couple of days ago it stopped working. Is the 3.51 fix still working for others?

[teskeyn]

Just seen https://developers.google.com/maps/documentation/javascript/versions which indicates that the oldest version supported in Nov 2023 is 3.52 and that will be gone by Feb 2024 :-(

[diabWH3]

Thanks again for the March update( patchluastr.exe LOCATIONMAPVIEW.LUA "3.12" "3.51" -o LOCATIONMAPVIEW.bin) which I applied and got the Map back and working. but a couple of days ago it stopped working. Is the 3.51 fix still working for others?

My map stopped working a few days ago as well. :(

[diabWH3]

Great work!

As the patching procedure is getting more complex, I guess it's time to update patchluastr to do all the necessary steps in one go with just a patch file and the Google API key as command line parameters.

Would love this option for users like myself that are relative novices when it comes to coding!

[astuder]

That's unfortunate... I hoped to procrastinate on this until at least February 2024 :(

I tried removing the deprecated attributes as @jbd7 did above. Unfortunately, that didn't fix it for me. Even when forcing the version to the one active in early 2023 (tried 3.52 and 3.52.1).

I see in the release notes of the Google Maps JavaScript API, that more attributes were removed later on, but I hoped to circumvent that with selecting the older version.

@jbd7 does your map module still work?

Attached the patch file implementing the (non-working) changes discussed above. jbd7.patch

[astuder]

One thing that's curious is, that the map module displays the night view with a spinning wheel and the message "Map is Offline". I think that's different from previous symptoms (blank page) and may point to a failure before locationmapview gets loaded.

[astuder]

There is a checkMapServerAvailability Lua function that seems to fail.

Output in LocationViewController.log:

11/21/2023 23:20:21 TRACE   updatePhotoMarkers: called from selectedImages   0 
11/21/2023 23:20:21 TRACE   updateAddressPanelFromSelectionChange() 
11/21/2023 23:20:21 TRACE   updatePhotoMarkers: called from availableImages      0 
11/21/2023 23:20:22 DEBUG   checkMapServerAvailability 
11/21/2023 23:20:24 DEBUG   Checking online status... 
11/21/2023 23:20:24 DEBUG   Map is going OFFLINE 
11/21/2023 23:20:24 DEBUG   checkMapServerAvailability 
11/21/2023 23:20:25 DEBUG   Checking online status... 
11/21/2023 23:20:25 DEBUG   Still offline, continue checking... 
11/21/2023 23:20:25 DEBUG   checkMapServerAvailability 
11/21/2023 23:20:26 DEBUG   Checking online status... 
11/21/2023 23:20:26 DEBUG   Still offline, continue checking... 
11/21/2023 23:20:26 DEBUG   checkMapServerAvailability 
11/21/2023 23:20:27 DEBUG   stopCheckMapServerAvailability 
11/21/2023 23:20:27 TRACE   updatePhotoMarkers: called from selectedImages   0 
11/21/2023 23:20:27 TRACE   updateAddressPanelFromSelectionChange() 
11/21/2023 23:20:27 TRACE   updatePhotoMarkers: called from availableImages      0 
11/21/2023 23:20:32 TRACE   updatePhotoMarkers: called from selectedImages   0 
11/21/2023 23:20:32 TRACE   updateAddressPanelFromSelectionChange() 
11/21/2023 23:20:32 TRACE   updatePhotoMarkers: called from availableImages      0 

The same log in March:

03/20/2023 14:48:38 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/20/2023 14:48:38 TRACE   updateAddressPanelFromSelectionChange() 
03/20/2023 14:48:38 TRACE   updatePhotoMarkers: called from availableImages      0 
03/20/2023 14:48:38 DEBUG   checkMapServerAvailability 
03/20/2023 14:48:39 TRACE   updatePhotoMarkers: called from availableImages      0 
03/20/2023 14:48:39 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/20/2023 14:48:39 TRACE   updateAddressPanelFromSelectionChange() 
03/20/2023 14:48:39 DEBUG   Checking online status... 
03/20/2023 14:48:40 DEBUG   Online, no need to continue checking 
03/20/2023 14:48:40 DEBUG   stopCheckMapServerAvailability 
03/20/2023 14:48:40 TRACE   updatePhotoMarkers: called from availableImages      0 
03/20/2023 14:48:40 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/20/2023 14:48:40 TRACE   updateAddressPanelFromSelectionChange() 
03/20/2023 14:48:44 DEBUG   stopCheckMapServerAvailability 
03/20/2023 14:48:44 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/20/2023 14:48:44 TRACE   updateAddressPanelFromSelectionChange() 
03/20/2023 14:48:44 TRACE   updatePhotoMarkers: called from availableImages      0 
03/23/2023 11:46:47 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/23/2023 11:46:47 TRACE   updateAddressPanelFromSelectionChange() 
03/23/2023 11:46:47 TRACE   updatePhotoMarkers: called from availableImages      0 
03/23/2023 11:46:48 DEBUG   checkMapServerAvailability 
03/23/2023 11:46:49 TRACE   updatePhotoMarkers: called from availableImages      0 
03/23/2023 11:46:49 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/23/2023 11:46:49 TRACE   updateAddressPanelFromSelectionChange() 
03/23/2023 11:46:50 DEBUG   Checking online status... 
03/23/2023 11:46:50 DEBUG   Online, no need to continue checking 
03/23/2023 11:46:50 DEBUG   stopCheckMapServerAvailability 
03/23/2023 11:46:50 TRACE   updatePhotoMarkers: called from availableImages      0 
03/23/2023 11:46:50 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/23/2023 11:46:50 TRACE   updateAddressPanelFromSelectionChange() 
03/23/2023 11:46:56 DEBUG   performing reverse geocoding 
03/23/2023 11:46:57 DEBUG   checkMapServerAvailability 
03/23/2023 11:46:57 DEBUG   Map is going offline, because of reverse geocoding response status   INVALID_REQUEST 
03/23/2023 11:46:58 DEBUG   Checking online status... 
03/23/2023 11:46:58 DEBUG   Map is coming ONLINE 
03/23/2023 11:46:58 DEBUG   stopCheckMapServerAvailability 
03/23/2023 11:47:04 TRACE   updatePhotoMarkers: called from selectedImages   0 
03/23/2023 11:47:04 TRACE   updateAddressPanelFromSelectionChange() 
...

It's getting late for me, but for those who want to dig deeper, here's the decompiled LUA code that generates the Checking online status log message: LOCATIONVIEWCONTROLLER.LUA.txt

[diabWH3]

One thing that's curious is, that the map module displays the night view with a spinning wheel and the message "Map is Offline". I think that's different from previous symptoms (blank page) and may point to a failure before locationmapview gets loaded.

I think I'm getting the blank page and no spinning wheel. I'll try to remember to get a screenshot sometime this weekend.

[adriancbogdan]

I'm seeing a blank page with no wheel, same as last time this broke.

[astuder]

Ok, not sure what I broke. But rolling back to the state before yesterday night also gives me just a blank page.

[astuder]

For those into reverse-engineering, I started publishing my notes here: https://github.com/astuder/lightroom-map-fix/blob/master/notes.md

Current status: I'm still trying to get better log output to find out where/why things break. So far, I managed to enable a verbose log and a debug console for the Chromium browser embedded in Lightroom. Unfortunately, without much useful to see.

[jbd7]

@jbd7 does your map module still work?

I finally moved on from Win8.1 and had to upgrade my whole setup, I am now with LR12. Sorry, I don't need to play with LUA hacks anymore ... I can only encourage you to try making the Map module work. I don't do anything in LR12 that I couldn't do in LR6, apart from occasional AI-powered background/subject selection, and the Dehaze slider needing less clicks than the old version as a plugin.

[astuder]

Is it just me again, or did the map module now change from the blank page to displaying the offline screen?

[teskeyn]

I still get the blank page as before.

[jhamp99]

I support the observation that it still displays only the blank page. I would appreciate it very much, if we could get the Map module functional again as it is fantastic feature that I liked using in Lightroom a lot.

[cyr06]

you are right , the page seems to be offline now. prettu sure it was blank 2 weeks ago

---

De : Adrian Studer @.> Envoyé : dimanche 3 décembre 2023 00:38 À : astuder/lightroom-map-fix @.> Cc : cyr06 @.>; Mention @.> Objet : Re: [astuder/lightroom-map-fix] Map page is blank, was working earlier (Issue #41)

Is it just me again, or did the map module now change from the blank page to displaying the offline screen?

— Reply to this email directly, view it on GitHubhttps://github.com/astuder/lightroom-map-fix/issues/41#issuecomment-1837293391, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKXK2K5T5YUIZOVFOCGG4MLYHPCYTAVCNFSM6AAAAAAVH352GWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGI4TGMZZGE. You are receiving this because you were mentioned.Message ID: @.***>

[diabWH3]

Still a blank screen for me.

[cyr06]

Hi all, I still can't have the map module working and google is still changing is API... is someone optimistic about the issue ? Thanks to @astuder we have been able to play several years with our old LR but maybe it's time to say goodbye ?

[diabWH3]

Wish I had the technical know-how to help troubleshoot the current API issues and formulate a fix! Definitely loving the support from astuder and everyone else over the years.

As a work-around, I currently use Google Maps in the browser or the Google Earth app to find GPS coordinates and copy/paste them manually into the metadata fields.

Jeffrey Fiedl makes a TON of really wonderful "donationware" plugins that also help with various tasks within Lightroom, including geoencoding tasks (I especially like being able to assign GPS data based on a track file for hiking trips). His page is here (http://regex.info/blog/lightroom-goodies) and the specific "Geoencoding Support" plugin is here ( http://regex.info/blog/lightroom-goodies/gps).

On Tue, Feb 20, 2024 at 2:40 AM cyr06 @.***> wrote:

Hi all, I still can't have the map module working and google is still changing is API... is someone optimistic about the issue ? Thanks to @astuder https://github.com/astuder we have been able to play several years with our old LR but maybe it's time to say goodbye ?

— Reply to this email directly, view it on GitHub https://github.com/astuder/lightroom-map-fix/issues/41#issuecomment-1953931417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AL2VMANPYXIF5JOKJ424ASDYUR4RRAVCNFSM6AAAAAAVH352GWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJTHEZTCNBRG4 . You are receiving this because you commented.Message ID: @.***>

[Cassiopeiaaa]

Kudos to Astruder for the fantastic work here. As Google is changing there APIs with no backward-compatability: It would be perfect for me if Lightroom 6.14 could work with Openstreetmap or alike in conjunction with GPS.

[senarvi]

I agree, OpenStreetMap is often even better than Google Maps. This repository includes the OpenStreetMap hack (displays OSM when the "Light" map style is selected), but even that doesn't work for me anymore. Maybe the problem is that Lightroom tries to access other Google APIs too, at least the Geocoding API for converting place names to coordinates. I wonder if we could make the OpenStreetMap working by disabling all requests to Google APIs?

[doobes]

Good luck.

Wish knew enough to be of assistance.

[senarvi]

Scratch that. The whole thing is heavily tied to the Google Maps JavaScript API. The Google API is used for interacting with the map and OpenStreetMaps is used just for rendering the map tiles. I don't think there's other way except to get the Google API working.

[senarvi]

I tried something desperate, hoping to catch some kind of error - I tried to enclose every function in a try..catch block. Basically replacing every Lua block like this (find_top_level_braces() finds the first { and last } of a function):

    new_code = ""
    previous_end = 0
    pattern = re.compile("function([^)]*)")
    for match in pattern.finditer(code):
        start_index = match.end()
        indices = find_top_level_braces(code, start_index)
        if indices is not None:
            first, last = indices
            new_code += code[previous_end:first + 1]
            new_code += " try {"
            new_code += code[first + 1:last]
            new_code += "} catch (e) { alert( e.message ); } "
            previous_end = last
    new_code += code[previous_end:]

Still nothing happened in Lightroom.

[astuder]

I apologize for my inactivity on this project. Other projects keep me very busy these days. :-/

I suspect that the failure doesn't happen when rendering the HTML page, but in JavaScript code directly invoked from Lua, and/or the interface between the two. For example a change in a Google Maps data structure causing an error in the LUA code processing it.

[Cassiopeiaaa]

I just wanted to add that in my google-account I can see that LR6 is communicating with google and that the "error rate"(?) is 0%. Just to let you know. Maybe the answer is misinterpreted from LR6. (but I have absolutely no programming-skills).