Skip to content

WIP: Increase population filter detail

John LaRocque requested to merge fixes/popdensity into master

Replaces the NASA population density GeoTIFF with a higher detail version from the GHSL. This source generally provides much more granular data, though there are still some patchy areas in Africa and central Asia.

ghsl_pop5.tif is a down-res'ed version of the 2015 GHS-POP dataset (WGS84 projection at 9 arcsecond resolution). The original data gives approximate populations under each pixel, but I didn't try to retain this property while reducing the file size. I used GDAL to, in order:

  • reduce the resolution to 25% (10800x5400),
  • square root the population values (to enhance detail in low-population areas),
  • truncate the floating point values at 3000.0 (anything higher than this is decidedly urban, so we don't care),
  • scale the resulting values to an 8-bit image,
  • recompress with the packbits algorithm (in the hope that this would be easier to decompress than LZW)

Command: gdal_translate fullpop.tif ghsl_pop5.tif -outsize 25% 0 -exponent 0.5 -scale 0 3000 0 255 -ot Byte -co "COMPRESS=PACKBITS"

The resulting file is 3.8MB (58.4MB decompressed), which I think is acceptable-ish. The problem is, it takes quite a while for the JS GeoTIFF library to decompress this (~30 seconds on my machine), which is less acceptable.
To keep from having to decompress the TIFF every time getLocationPopulation is called, this also makes some modifications to get_places.js. Performance is good once the initial decompression is done, but the script is still a bit messy.

The payoff of these changes is that the resulting location selection is quite good in the testing I've done.

TODO:

  • Reduce decompression time - maybe decrease resolution to 12.5%
  • Scale population filter to the polygon (for example, a polygon with a max population of 32/0.125 would count that rather than 255/1.0 as 100%)
  • Try decompressing only the bounding box of the polygon (don't know if this will be faster, but it's supported)

Potentially resolves: #39, #45, and #47

Edited by John LaRocque

Merge request reports