Big Data search engine for full-text strings and photos with radius search

Mini-Google with Many Formats

Later, the script in Listing 2 finds files for predefined keywords, just like an Internet search engine. When you call this script with fs-search '*', the command matches every document in the index. (The single quotes stop the Unix shell from grabbing the metacharacter * and turning it into a glob in the local directory.) Anyway, Elasticsearch returns 10 more or less random results for fs-search '*', because with no further configuration, the maximum number of hits is set to 10. The script shown a little later changes this value to 100.

Listing 2

fs-search

 

The search() method called in line 12 expects the name of the search index under which the data resides (again fs), and it wants the query string in the body part of the request. From the documentation [7], you can see that Elasticsearch obviously understands a whole range of historically grown query formats, which necessitates the seemingly absurd nesting (lines 15-17) of query/query_string/query.

The result of the fact-finding mission is a reference to an array of hits, which the for loop iterates over in lines 20 and 21, printing only the names of the matching files, which are part of the result set.

Searching GPS Image Data

Elasticsearch can do even more, though. For example, the geo_distance filter [8] extends the classic full-text search, adding an interesting capability. If you configure the filter and store matching geodetic data for each document, the search engine will show you the entries that are located within a certain radius. This feature could be useful, for example, if you find yourself roaming around with your mobile phone late at night looking for a five-star restaurant in the area that is still serving.

Because my iPhone 5, just like any other smartphone, stores the GPS data in the Exif header of the JPEG file for every image I shoot, a search that starts with a given image in the phone's photo album ("Gallery") and finds images that I shot within a 1km radius of the image's location could be fun. As an example, Figure 2 shows a photo of the newly constructed eastern span of the Bay Bridge [9] in my city of residence, San Francisco. Since last year, pedestrians and bike riders can get to the middle of the bridge on a dedicated path, from where I shot a number of photos.

Figure 2: A picture of the new Bay Bridge shot with an iPhone.

Figure 3 shows the output of the exiftags command for the photos transmitted from the phone to my Linux machine. Almost at the bottom, you can see that the image was shot at the geolocation 37°48.87' north latitude and 122°21.55' west longitude.

Figure 3: The GPS values in the Exif header of the image file from the iPhone are 37°48.87' north latitude and 122°21.55' west longitude.

Modern Sextant

The photo_latlon() function in Listing 3 reads these GPS values with the CPAN Image::EXIF module and uses dm2decimal() from the Geo::Coordinates::DecimalDegrees module to convert them to floating point numbers. The regular expression in lines 47-53 searches the geodata for a letter (N or S for north or south latitude, W or E for western or eastern longitude), followed by the numerical degree value and the degree symbol encoded in UTF-8. The minutes follow after one or more spaces.

Listing 3

IPhonePicGeo.pm

 

Thus, 37°48.87'N becomes the value 37.816 and 122°21.55'W becomes the negative floating-point number -122.3555.

Google Maps confirmed (Figure 4) that the talented photographer really was standing in the middle of San Francisco Bay on the Bay Bridge when he pressed the button. To find out whether other pictures in the photo album were recorded within a radius of 1km, photo-index in Listing 4 examines all the transferred photos in the ~/iphone directory and stores their GPS data on the local Elasticsearch server.

Figure 4: The coordinates [37,816, -122.3555] really are located on the Bay Bridge in San Francisco.

Listing 4

photo-index

 

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Perl – Elasticsearch

    Websites often offer readers links to articles about similar topics. Using Elasticsearch, the free search engine, is one way to find related documents instantly and automatically.

  • ELK Stack

    A powerful search engine, a tool for processing and normalizing protocols, and another for visualizing the results – Elasticsearch, Logstash, and Kibana form the ELK stack, which helps admins manage logfiles on high-volume systems.

  • Logstash

    When something goes wrong on a system, the logfile is the first place to look for troubleshooting clues. Logstash, a log server with built-in analysis tools, consolidates logs from many servers and even makes the data searchable.

  • Beagle

    To find files, music, messages, and photos in a single search, try this desktop tool with the power of an Internet search engine.

  • Tutorials – Recoll

    Even in the age of cloud computing, personal computers often hold thousands of files: text files, spreadsheets, word processing docs, configuration files, and HTML files, as well as email and other message formats. If it takes too long to find the file you need, chase it down with the Recoll local search engine.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News