Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to raster attribute tables #22427

Closed
qgib opened this issue Mar 9, 2016 · 17 comments
Closed

Access to raster attribute tables #22427

qgib opened this issue Mar 9, 2016 · 17 comments
Labels
Feature Request Rasters Related to general raster layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented Mar 9, 2016

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.



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


@qgib
Copy link
Contributor Author

qgib commented Jan 10, 2017

Author Name: shenriod - (shenriod -)


Related to #22798

@qgib
Copy link
Contributor Author

qgib commented Apr 30, 2017

Author Name: Giovanni Manghi (@gioman)


  • easy_fix was configured as 0

@qgib
Copy link
Contributor Author

qgib commented May 16, 2018

Author Name: Alexander Bruy (@alexbruy)


@qgib
Copy link
Contributor Author

qgib commented Nov 16, 2018

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


@alexbruy
Copy link
Contributor

See also #14258

@GlenRice-NOAA
Copy link

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
Copy link
Contributor

elpaso commented Oct 8, 2020

@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
Copy link

GlenRice-NOAA commented Oct 9, 2020

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
Copy link

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
Copy link

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.

image

@Saijin-Naib
Copy link

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

This looks incredible! Time to poke at it.

@elpaso
Copy link
Contributor

elpaso commented May 14, 2021

@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
Copy link

@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
Copy link
Contributor

elpaso commented May 15, 2021

@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
Copy link

image
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
Copy link
Contributor

gioman commented May 17, 2021

can not interact with RATs within a FileGeoDataBase

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

@alexbruy
Copy link
Contributor

alexbruy commented Dec 3, 2023

Alreasy possible in master

@alexbruy alexbruy closed this as completed Dec 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Rasters Related to general raster layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

7 participants