You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am converting a dataset of geotiffs to web-optimized COGs with rio-cogeo using a TMS defined within the planetcantile project. The dataset consists of a large number of non-COG 4x4 degree tiles spanning -180 to 180 degrees and +/- 88 latitude, and have naming convention related to the lower left point, so tile E-180_N00 spans -180 to -176 longitude and 0 to 4 degrees latitude. Each tile has a 5x5 meter per pixel resolution.
The left-side boundary easting is -10669445.554195119, this will be important in a few more sentences...
Each raw TIF file is around 2 Gb in size, so I was surprised when a few COGs processed with rio-cogeo produced COGs that were only a few hundred Kb in size.
Specifically it was all of the tiles with a origin point on the antimeridian (-180 degrees longitude) except for the "center" tile on the equator (E-180_N00).
After inspecting the metadata on these tiles, it appears that it is a floating precision issue with the origin point X point. The origin easting for the E-180_N00 tile is -10669445.554197242483497 while the next tile above it at E-180_N04 has an origin of -10669445.554209999740124. The N04 tif also ends up wrapping all the way over to +180 degrees east, so although both origins are technically outside of the projection's extent, it seems that the E-180_N04 origin is large enough to be a problem.
While I will probably go through the exercise of using gdal_edit.py to modify the source Tif files to fix this (and I have already observed this fixing the issue of the resulting COG from rio cogeo, I wonder if there is a simple fix in rio-cogeo to make to avoid this extra step?
I would expect this to have something to do with the WarpedVRT usage and the lack of boundless reading, and I saw a related PR in rio-tiler that maybe could inspire a fix, but I haven't dug into this deeply enough to know for sure.
I made faux files for the inputs and outputs from rio-cogeo with the _tms.tif postfix, and the source files are prefixed by c_. Below are the info's for the COG outputs that shows that the N04 tif has a width that doesn't make sense and world spanning extent.
I am converting a dataset of geotiffs to web-optimized COGs with rio-cogeo using a TMS defined within the planetcantile project. The dataset consists of a large number of non-COG 4x4 degree tiles spanning -180 to 180 degrees and +/- 88 latitude, and have naming convention related to the lower left point, so tile E-180_N00 spans -180 to -176 longitude and 0 to 4 degrees latitude. Each tile has a 5x5 meter per pixel resolution.
I am specifically using the custom TMS from planetcantile for the IAU projection IAU_2015:49910 (https://www.opengis.net/def/crs/IAU/2015/49910, https://spatialreference.org/ref/iau_2015/49910/) that pyproj supports as well as recent rasterio releases.
The left-side boundary easting is
-10669445.554195119
, this will be important in a few more sentences...Each raw TIF file is around 2 Gb in size, so I was surprised when a few COGs processed with rio-cogeo produced COGs that were only a few hundred Kb in size.
Specifically it was all of the tiles with a origin point on the antimeridian (-180 degrees longitude) except for the "center" tile on the equator (E-180_N00).
After inspecting the metadata on these tiles, it appears that it is a floating precision issue with the origin point X point. The origin easting for the E-180_N00 tile is
-10669445.554197242483497
while the next tile above it at E-180_N04 has an origin of-10669445.554209999740124
. The N04 tif also ends up wrapping all the way over to +180 degrees east, so although both origins are technically outside of the projection's extent, it seems that the E-180_N04 origin is large enough to be a problem.While I will probably go through the exercise of using
gdal_edit.py
to modify the source Tif files to fix this (and I have already observed this fixing the issue of the resulting COG from rio cogeo, I wonder if there is a simple fix in rio-cogeo to make to avoid this extra step?I would expect this to have something to do with the WarpedVRT usage and the lack of boundless reading, and I saw a related PR in rio-tiler that maybe could inspire a fix, but I haven't dug into this deeply enough to know for sure.
I made faux files for the inputs and outputs from rio-cogeo with the
_tms.tif
postfix, and the source files are prefixed byc_
. Below are the info's for the COG outputs that shows that the N04 tif has a width that doesn't make sense and world spanning extent.faux_E-180_N00_tms.tif info:
faux_E-180_N04_tms.tif info:
faux_src.zip
faux_tms.zip
The text was updated successfully, but these errors were encountered: