There are a whole bunch of equivalent projection to EPSG:3857. Let OSR deal with them.
If the Dataset's projection isn't recognisable by OSR, try to determine its EPSG code, try to identify an equivalent ESRI code instead. If it succeeds, the SpatialReference returned will be based on a EPSG one.
Added two ESRI WKID in the constants file along with their equivalent EPSG code.
Some times, when upscaling and slicing a partial world, the bottom TMS extents, which is used to determine the Y position of tiles, would be wrongfully rounded down, thus rendering the tiles exactly 1 tile downward from where they should be on the map. Rounding the calculations of the TMS extents before converting the floating point values into integers fixes the problem.
EPSG:3857 is understood by Proj4 and thus understood by GDAL. It is also the projection that is used in most web apps, such as Google Maps or Microsoft Bing. Having the default to EPSG:3785 is not good.
… epsilon We might have to deal with floating point errors when computing the new width and height of the upsampled image. Using an epsilon makes sure that we're within an acceptable integer range. After verifying that, we round the resulting width and height, and int() them before continuing normally.
Since we removed scripts/gdal2mbtiles, we need something to run against before we install the console entry point.
Also, configure logging by default.
…rruption The band's X and Y size was not referring to the dataset, so if you got a handle on the band and then scaled the dataset, the X and Y sizes were not changed and were thus wrong. Always report the X and Y sizes from the dataset. There was a bug in the band and dataset ReadAsArray methods where if you tried to read from the buffer, the values could be modified because the ndarray returned was referring to the direct buffer in memory. Copying the buffer before returning the ndarray is the correct thing to do.
When upsampling, if the scaling ratios cause the number of pixels of the output image to be a fraction of a pixel, we round up so we don't lose any data. Before, we were rounding the number of pixel to the closest integer, but that means that we could lose up to half a pixel worth of data. This shouldn't have much of an impact on the output image, especially when using nearest neighbour.
The old implementation, where we had the tiles view compute the offset, was architecturally cleaner but slower because SQLite had to scan the entire map table before it could locate a single tile. Instead, there are only two lookups now, directly from the index, because the zoom_level for the map table is already offset when we write the file.
Because TileJSON offers minzoom and maxzoom metadata, we add this to the MBTiles metadata to make serving this information quicker. Otherwise, the TileJSON server would have to query the tiles table for this information.
A VipsBand is a band that belongs to a VipsDataset which you can read from using ReadAsArray, just like a normal GDAL band. Other reading methods, such as ReadRaster and ReadRaster1, are now disabled in both VipsBand and VipsDataset to prevent you from shooting yourself in the foot.