> For the complete documentation index, see [llms.txt](https://pavewise.gitbook.io/pavewise-style-guide-and-more/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pavewise.gitbook.io/pavewise-style-guide-and-more/backend/ruby-gems.md).

# Ruby gems

* [mini\_exiftool ](#mini_exiftool)(metadata extractor)
* [mini\_magick](#mini_magick) (convert .heic files > .jpeg)

***

## mini\_exiftool

<details>

<summary>More Details</summary>

From [PR that introduced this gem](https://github.com/pavewise-pro/pavewise-api/pull/318):

I'm storing the “other” metadata (metadata not automatically captured by Rails/ActiveRecord/ActiveStorage) in the new “other\_metadata” company\_file field.

I think I’ll keep the raw extraction value for each “metadata of interest” field that we collect, each stored as a key/value pair in the “other\_metadata” object.

Additionally, I’ll create a new field with “Formatted” appended to the end of the field name for any field that we want to always try to have consistent data type & format for (e.g. latitude/longitude fields)

**Example: latitude/longitude**

* HEIC, HEIF files
  * the lat/long values are in the keys GPSLatitude/GPSLongitude and in the “DMS” format (as shown in attached screenshots), but this format isn’t super usable (nor the same data type or format as our project lat/lon data), so I have a method to convert it to decimal degrees and store it in the GPSLatitudeFormatted/GPSLongitudeFormatted fields
* …other file types
  * Maybe other file types also have latitude and longitude fields (maybe they are also called GPSLatitude/GPSLongitude, or maybe something else), possibly as different data types or formats as well…. we can always still depend on the GPSLatitudeFormatted/GPSLongitudeFormatted fields being present in the correct “decimal degrees” format (because we will handle the conversions of whatever latitude/longitude types we come across, adding new methods to the controller to convert them to decimal degrees format)

(Note: it seems that GPSLatitude/GPSLongitude seem to be consistent among file types so far, if they have latitude/longitude data present, but I think it’s a safe idea to keep the same sort of system — never modifying the actual metadata values (storing them as is) + creating a “xFormatted” field as needed for data type consistency/dependability)

</details>

* [Github link](https://github.com/janfri/mini_exiftool/)
* requires [Exiftool](https://exiftool.org/) to be locally installed
* This gems results are possibly just “EXIF” category metadata, but it might be multiple categories of metadata put together, as [mini\_exiftool says it can read/write EXIF-data, IPTC-data and XMP-data](https://github.com/janfri/mini_exiftool)
* to see all available metadata fields for a file ran through mini\_exiftool, place the following code in company\_files\_controller:

```ruby
# company_files_controller

# within :create action (within "if file_params[:attachments] ... end" block)
# read and log metadata (use this when wanting to see available metadata fields on an attachment)
file_params[:attachments].each do |attachment|
    read_and_log_metadata(attachment)
end


# private method
def read_and_log_metadata(attachment)
  begin
    file = attachment.tempfile
    puts "Reading file: #{file.path}"
    puts "Using Exiftool command: #{MiniExiftool.command}"
    if File.readable?(file.path)
      metadata = MiniExiftool.new(file.path)
      metadata.to_hash.each do |key, value|
        puts "#{key}: #{value}"
      end
      puts "Metadata errors: #{metadata.errors.join(', ')}" unless metadata.errors.empty?
    else
      puts "File not readable: #{file.path}"
    end
  rescue => e
    Rails.logger.error "Error reading metadata for file #{attachment.original_filename}: #{e}"
  end
end
```

***

## mini\_magick

* requires imagemagick to be locally installed
*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://pavewise.gitbook.io/pavewise-style-guide-and-more/backend/ruby-gems.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.