I have a few thousand TIF tiles and need to extract polygons of the actual data coverage from inside these TIFs (see below for image showing what the coverage looks like). The resulting geometry will be loaded into a Postgres table.

Due to the number of TIFs, and the fact that the data-set will be regularly updated, I need the process to be as efficient and automated as possible.

I have tried gdal_polygonize.py, but this gives me a result like this:

enter image description here

I would then have to 'dissolve' these polygons, or run ST_Union with PostGIS to get the result I want, which looks like this:

enter image description here

Dissolving is very slow, and feels unnecessary when there must surely be a way to skip the multiple polygon result of gdal_polygonize.

Does anyone have any ideas how I could do it in one step, or just make the process faster/more efficient?

  • Please, have a look at my answer. It is more a workaround and I don't know if it could fit well to your case. – mgri May 9 '17 at 11:57

The following is a method that worked well for me some time ago, but it is not completely automatic.

Try to follow this workflow:

  1. run the Polygons to lines algorithm from the Processing Toolbox (your polygon layer as input);
  2. run the Line to polygons algorithm from the Processing Toolbox (the previous result as input).

This workflow (that you can easily implement using the QGIS Modeler or some lines of code) is really fast and will lead to the creation of a new polygon, which is smaller in terms of size in respect of the first one. It stores several features and you only need to select the lower one, which you should find easily. If you judge this last step as problematic for your needs, you may try to run again the dissolve tool after the second step of the workflow: it could less time-consuming in respect of running it as you did previously.


I would then have to 'dissolve' these polygons, or run ST_Union with PostGIS to get the result I want, which looks like this:

Which version of PostGIS and PostgreSQL are you using? PostGIS in 2009 got a massive speed improvement in ST_Union. And, again in 2016 with PostGIS 2.3 with parallel functions using ST_MemUnion

Try using ST_MemUnion and setting

SET max_parallel_degree=2; (or however may cores you have)

And if you're using PostgreSQL 9.6 don't forget to set your max_parallel_workers_per_gather. In Pg9.6 parallel queries are disabled by default.

  • Thanks for your answer @Evan. I'm using Postgres 9.4 at the moment and PostGIS 2.1.4. I'll upgrade and see how much faster things are! – Matt May 11 '17 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.