The "beer belly" of the fuchsia rasterized polygon hanging over the orange one makes me suspect the following cause: The polygons' mutual boundaries are made up of points that were collinear in some original CRS, but are not quite collinear in the CRS you're using for the rasterization.
Things I would do fix:
To explore, go into edit mode (even though you won't make edits) and use the vertex tool to visualize the vertices on both polygons, to check whether this hypothesis is correct. You could also add a layer in symbology to mark vertices, but this is probably more work.
Do your rasterization in the same CRS as the one the polygons were (originally) defined in. If this is disruptive to your project, open a new project and just pull in the vector layer and set the project CRS to what it needs to be, do the rasterization in that CRS, save the output raster with that CRS -- and then pull it pack into your actual project.
Not sure what algorithm you're using for rasterization, but if its gdal_rasterize
or an invocation of it via QGIS' processing panel, add the command line option -at
to burn in all touched raster points (see https://gdal.org/programs/gdal_rasterize.html for brief docs).
Use grass
processing algorithms instead (from within QGIS), for instance v.to.rast
. You may need to play with v.in.org
snap tolerance and minimum area under advanced parameters (consult the Grass documentation). The reason for this is that grass processes polygons topologically, as a tiling of a region with boundaries rather than as separate polygons that might have sliver topological errors. So any point will be unequivocally in one polygon and so rasterization should not have the issues you're having. The v.in.ogr
parameters are preprocessing that gets done to make this tiling, and so it's where the little slivers will get resolved.
Editing to add: If all of this is a one-off, and a kluge from where you are now is better than redoing it properly, try applying the Sieve
algorithm (with a threshold less than the size of your genuine polygons) to remap the slivers to the neighbouring value. Or maybe Fill NoData
if they're NODATA in the raster. You may be assigning them to the wrong polygon, but the error may be at a scale you don't care about.