I added the proximity-search feature to my blog several years ago, and I
use it often in various ways because proximity search can be extremely
useful, but my blog proximity search is obviously limited to photos I've
actually published on my blog. My full catalog of photos in Adobe Lightroom
is much, much bigger.

To take advantage of proximity search, your photos have to be geoencoded to begin
with (that is, each photo must be associated with latitude/longitude
coordinates of where it was shot). At the timeI first released the plugin,
there was no way to geoencode photos within Lightroom, so one had
to somehow take care of it before importing photos into your catalog. It was a pain.

But, while working on that plugin I figured
out a tricky way to build another plugin that
allows you to geoencode within Lightroom, and my Geoencoding Support
plugin was released a couple of weeks later;
it remained the only way to geoencode within Lightroom until Adobe
introduced the Map Module last year. (My Geoencoding Support plugin is all
the more useful now that Lightroom supports location editing, because it
extends the usefulness of location information far beyond what Lightroom
provides.)

Anyway, I was happy that I could do a
proximity search on my photos, but the unfortunate reality was that
Lightroom's catalog interface for plugins was simply too slow, creating
a high barrier to use: I'd use it sparingly, only
when it was worth the several-minute wait for a
result.

Still, even today it's better than what Lightroom itself now supplies,
at least on my machine. If I set Lightroom's Map
Module to an area I'm interested in, then switch to Library and select
“All Photographs”, then go back to Map to see which ones show up,
Lightroom completely locks up for eight minutes. Locks up. Eight minutes. Painful.

(I hear that Lightroom is faster in this respect on Windows; someone who
tested my catalog said the lockup was only two minutes there.)

I don't understand why plugin access to the Lightroom catalog is so
slow, but to gain some insight I tried accessing the Lightroom-catalog
SQLite database directly. The results? The same search that locked up
Lightroom for eight minutes took 0.6 seconds.

Even though the very first Lightroom-related article on my blog was a
post in 2006 about accessing the Lightroom
database directly, I've purposefully stayed away from doing so within
my plugins as a matter of principle, keeping instead to the official plugin infrastructure.

But come on, an 800-fold speedup is just too much to pass up, especially
for a feature that blooms in usefulness when you can use it on the spur of
the moment with little friction. So for the first time in my
plugin-development life, I did an end around Lightroom's interface, adding
a “Fast Full-Catalog Proximity Search” plugin-extra feature to my Proximity
Search and Geoencoding Support plugins last week. This is the fast search
that I mentionedon my
previous post.

The search is nominally invoked from the “File > Plugin Extras >
Geoencoding Support > Fast Full-Catalog Proximity Search” menu, but on my system I mapped it to a keyboard
shortcut, so while looking at an image that's geoencoded, a quick tap
brings up this dialog:

Upon activation, the plugin goes outside of Lightroom to grab the data,
then import just those results back in, creating a collection with them. It took justa few seconds to isolate the 548 photos from that general area over the years.

One bummer about the workaround that achieves this: it doesn't work on
Windows, nor on Lr4 or earlier, so in those situations the “Fast
Full-Catalog Proximity Search” plugin-extra item reverts to the slower,
official, much-less-compelling method. )-:

(If you can figure out a way to give sqlite3.exe readonly access a locked database, please let me know.)

Still, if you're using Lr5 on a Mac and find this useful, please let
Adobe know; perhaps they'll add this kind of thing directly into Lightroom...
where it will presumably work on Windows as well.

sqlite databases can be opened in WAL mode (Write-Ahead Logging).
see http://www.sqlite.org/wal.html
With “PRAGMA journal_mode=wal;”, executed from an sqlite shell, this mode can be made persitent for a databse. This would allow access to the Lightroom catalog from more than one process concurrently.
However, if Lightroom is started with a WAL-mode catalog which is NOT already opened by an other process, it resets the journal_mode to “delete” and prevents access to the catalog from other processes. To get around this “limitation” I am using the following cmd script to start Lightroom:

The file initcmds as a parameter for the sqlite3.exe init option has the following contents:
—initcmds starts here—
PRAGMA journal_mode=wal;
.table
—initcmds ends here—

This script opens the catalog in WAL mode, executes the sqlite table command, which creates the files LightroomCatalog5.lrcat-wal and LightroomCatalog5.lrcat-shm, and then starts Lightroom.

This time Lightroom seems to honor the already opened catalog in WAL mode and allows access to the catalog from other processes.

I know, that this is not a solution for the majority of Lightroom users, but I am really wondering if you can use it to implement your “Fast Full-Catalog Proximity Search” on Windows. So please let me know

Greetings from Berlin
Jacques

Good info to know, thank you, but yeah, not something for the masses. I suppose I can try to detect whether read mode is supported and enable it if so… I’ll give it some thought… —Jeffrey

Yeah, but is there an actual benefit to doing it their way? Or are you just diplomatically saying they just didn’t care?

I’m not so privy to the internals to know whether optimizing for this particular need would have detrimental effects on other things; more likely, this particular whole-catalog need would benefit from separate API hooks, that one can diplomatically say haven’t yet made the priority cut. —Jeffrey