r.in.mat(1grass)

πŸ’– r.in.mat(1grass) β€” the GRASS User's Manual page, bestie edition πŸ’–

okay so welcome to r.in.mat, the lil GRASS module that slurps up a binary MAT-File (v4) and turns it into a raster map. it's giving ✨time travel✨ because it wants the old format. let's get into it 🫢

🌸 NAME 🌸

r.in.mat β€” imports a binary MAT-File(v4) to a GRASS raster. literally that's the whole job πŸ’…

🏷️ KEYWORDS 🏷️

raster, import


✨ SYNOPSIS ✨

r.in.mat
r.in.mat --help
r.in.mat input=name  [output=name]   [--overwrite]  [--help]
[--verbose]  [--quiet]  [--ui]

πŸŽ€ Flags:

  • --overwrite β€” let your output files just bulldoze over existing files, no cap
  • --help β€” prints the usage summary so you know what's up
  • --verbose β€” verbose module output, for when you want ALL the tea
  • --quiet β€” quiet module output, for when you want it to shush πŸ™ˆ
  • --ui β€” forces the GUI dialog to launch, main character energy

πŸ¦‹ Parameters:

  • input=name [required] β€” name of the input MAT-File(v4). yes bestie it's mandatory, you can't skip it 😭
  • output=name β€” name for the output raster map (it overrides, periodt)

🌈 DESCRIPTION 🌈

r.in.mat will import a GRASS raster map from a Version 4 MAT-File β€” the kind made with Matlab or Octave. and the best part? attributes like the map title and bounds get imported too, if they exist. obsessed 😍

so specifically, these array variables get read:

  • map_data
  • map_name
  • map_title
  • map_northern_edge
  • map_southern_edge
  • map_eastern_edge
  • map_western_edge

any other variables chillin in the MAT-file? simply skipped over. not our business, not our problem πŸ’…

the map_name variable is optional β€” if it exists and it's valid, the new map gets named that. if it doesn't exist, or you specified a name with the output= option, then the raster map's name gets set to "MatFile" or the name you specified, respectively. (max 64 characters; normal GRASS naming rules apply, so no silly business ✨)

the map_title variable is also optional β€” if it exists, the map's title gets set. cute.

but the map_northern_edge and its lil sibling variables? mandatory, bestie. unless you're importing into an "XY" non-georeferenced project (like imagery data, for example). latitude and longitude values should be in decimal form, don't be doing anything weird 🌸


πŸ“ NOTES πŸ“

r.in.mat imports a Version 4 MAT-File. these files can be successfully created with more modern versions of Matlab and Octave (peep the "EXAMPLES" below, i gotchu).

everything should be Endian safe, so the file you're importing can just be copied between different system architectures without any binary translation needed. (caveat: see "TODO" below β€” yes there's a catch, there's always a catch πŸ’€)

so here's a thing: since there's no IEEE value for NaN in integer arrays, GRASS's null value might be used to represent it inside these maps. usually Matlab will save any integer based matrix with NaN values as a double-precision floating point array, so this usually isn't an issue. but to save space β€” once the map is loaded into GRASS β€” you can convert it back to an integer map with this command:

r.mapcalc "int_map = int(MATFile_map)"

NaN values in either floating point or double-precision floating point matrices should translate into null values as expected. slay.

⚠️ real talk: r.in.mat must load the entire map array into memory before writing, so it might have problems with huge arrays. (a 3000x4000 DCELL map uses about 100mb RAM β€” that's not a vibe for tiny machines 😭)

GRASS defines its map bounds at the outer-edge of the bounding cells, not at the coordinates of their centroids. so these Matlab commands may be used to determine and check that the map's resolution information will be correct:

[rows cols] = size(map_data)
x_range = map_eastern_edge - map_western_edge
y_range = map_northern_edge - map_southern_edge
ns_res = y_range/rows
ew_res = x_range/cols

remember: Matlab arrays are referenced as (row,column), i.e. (y,x). don't flip it, i'm begging πŸ™

and bonus: r.in.mat and r.out.mat together make a nice binary container format for transferring georeferenced maps around, even if you don't use Matlab or Octave at all. iconic duo fr fr πŸ‘‘


πŸ’« EXAMPLES πŸ’«

in Matlab, save with:

save filename.mat map_* -v4

in Octave, save with:

save -mat4-binary filename.mat map_*

🚧 TODO 🚧

  • Robust support for mixed-Endian importation. (this is a work in progress, please help by reporting any failures to the GRASS bug tracking system πŸ™)
  • Add support for importing map history, category information, color map, etc. if they exist.
  • Option to import a version 5 MAT-File, with map and support information stored in a single structured array. (one day bestie, one day ✨)

πŸ’€ KNOWN ISSUES πŸ’€

if you encounter any problems, please contact the GRASS Development Team. they wanna hear about it, fr.


πŸ‘€ SEE ALSO πŸ‘€

r.out.mat, r.in.ascii, r.in.bin, r.mapcalc, r.null.

The Octave project


πŸ‘‘ AUTHOR πŸ‘‘

Hamish Bowman Department of Marine Science University of Otago New Zealand


πŸ”₯ SOURCE CODE πŸ”₯

Available at: r.in.mat source code (history)

Latest change: Friday Feb 07 19:16:09 2025 in commit: a82a39f673b97fafcfce1604dc3e6015cb96487a

Main index | Raster index | Topics index | Keywords index | Graphical index | Full index

Β© 2003-2026 GRASS Development Team, GRASS 8.5.0 Reference Manual


and that's the whole page, bestie πŸŽ€ this was GRASS 8.5.0 / r.in.mat(1grass) energy, go import something cute, ily, bye πŸ’–πŸ¦‹βœ¨

πŸ“¦ where this page comes from