Access to raster attribute tables

[qgib]

Author Name: Kurt Menke (Kurt Menke) Original Redmine Issue: 14449

Redmine category:rasters Assignee: Nathan Woodrow

---

Many categorical raster datasets, such as those representing vegetation and landcover, have associated attribute tables. There are the usual value and count columns, but there are also often additional fields that hold useful vegetation descriptions. These might include vegetation type, vegetation complex, landcover type etc. ERDAS Imagine raster files will have a .vat.dbf with these attributes.

It would be incredibly useful to be able to open this attribute table as you can with a vector dataset. Then queries could be run and the corresponding cells highlighted. Additional columns could be added, and used to classify cells into new categories without having to do an r.recode or similar operation. For instance, you could assign weights this way, to prepare for site selection model. Additionally, these attribute columns could be made available to style the raster via the Categorized or Rule based renderers. For example, a vegetation dataset could be brought in and styled by the vegetation type attribute column. Or groups of vegetation/landcover types could be given a color with the Rule based renderer.

---

• VegetationRaster.zip (Kurt Menke)

---

Related issue(s): #26793 (duplicates), #28332 (duplicates) Redmine related issue(s): 18962, 20512

---

[qgib]

Author Name: shenriod - (shenriod -)

---

Related to #22798

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• easy_fix was configured as 0

[qgib]

Author Name: Alexander Bruy (@alexbruy)

---

• duplicated was configured as #26793

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

• duplicated was configured as #28332

[alexbruy]

See also #14258

[GlenRice-NOAA]

I am looking for information regarding the status of this feature request. While it appears this feature was recently assigned to the Future Release - High Priority milestone, it looks like that milestone was closed. Does that mean this feature is recognized as high priority but has not been assigned to a release?

[elpaso]

@GlenRice-NOAA feature requests are usually implemented either by volunteers or (more often these days) by a developer that is being paid by a customer. Even if we had a formal/official milestone for feature requests, that would not be of much use if nobody will actually work on that feature request.

There are a few ways you can help and they have been very well summarized by Nyall Dawson in this blog post: https://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/

I would be personally interested in working on this feature if some form of sponsorship is available but there are many other very well qualified companies/individuals that can offer this kind of service, there is a page about commercial support on the main QGIS website.

Feel free to contact me in private if you need more information.

[GlenRice-NOAA]

Thank you for the help and perspective.

I would be interested in the ability to at least visualize the raster attribute table in QGIS, primarily in support of attributed bathymetry. As described in a proposal to update the BAG format, being able to describe the quality metrics and source information on a cell by cell basis is valuable (if not essential). For example, the attribute table can inform the user which elevation data comes from source and which is interpolated, so some ability to extract a mask from the RAT raster by row or by attribute field query and apply it to other rasters would be helpful.

While we are not actively creating BAGs with RAT information yet (pending acceptance of the BAG V2 branch, but also available to read through GDAL 3.2), we have begun experimentally populating GeoTIFF RATs (example included). I would note that we are intentionally populating these GeoTIFF RATs with surveys that do not exist in the raster to communicate surveys that were considered for inclusion in the area but were superseded by other sources. Also, we have only separated the RAT layer into a separate file due to other software requirements. For my perspective all layers would be packaged in a single file.

bathymetry_RAT_example.zip

[geomenke]

It is good to see this request getting some attention! This is the link to the online document where we were discussing potential use cases.

[GlenRice-NOAA]

There is now an experimental python plugin available for working with raster attribute tables (RAT) in QGIS. There are a few desirable features that can only be implemented once this functionality is part of the QGIS core, but this initial step is meant to flesh out RAT use in an adaptable environment before that additional effort is attempted. Thank you to @elpaso for this work.

[Saijin-Naib]

You already answered my question: QGIS Core if/when.

This looks incredible! Time to poke at it.

[elpaso]

@Saijin-Naib we all want this functionality to be eventually rewritten in C++ and land into core but I think that experimenting with a plugin is a good starting point to understand the different use cases and the limitations of the current API and to design the final API to integrate RAT with rasters, for instance: do we want/need an abstract raster -> vector join where the RAT is seen as a vector layer but not limited to RAT?

We should probably wait a little, collect ideas and use cases, then start a QEP and find sponsors.

As a side note, I already wrote some parts of the plugin (the model/views and the editing part) with C++ porting in mind and there is a great unit test coverage.

[Saijin-Naib]

@elpaso ,

That all sounds brilliant. No point spending significant development time to shape a tool into something nobody works with comfortably, right?

Off the top of your head, would this plugin be able to access RATs that are stored in FileGeoDatabases? Or does that require something on GDAL's end?

[elpaso]

@Saijin-Naib no idea sorry, the plugin uses GDAL to read/write RATs for all non-dbf formats, if GDAL reads it the plugin will as well.

[Saijin-Naib]

As of this release, no, the RasterAttributeTable plugin can not interact with RATs within a FileGeoDataBase. I imagine that is because of lack of a currently viable way to access raster data from within a FGDB currently. I thought maybe the RAT would still have been readable.

Still, incredible work and super valuable for the community!

[gioman]

can not interact with RATs within a FileGeoDataBase

@Saijin-Naib or maybe just because they are in a proprietary format?

[alexbruy]

Alreasy possible in master