TileGrid Row issue after zoom 8 about gtiff2tiles HOT 9 CLOSED

Hello.
That issue is probably happens because that website (I'm not sure) doesn't use tms tile naming system (even though they are EPSG:4326). The difference is indeed in y tile numbers.
GTiff2Tiles now supports only tms naming system. Here you can read more about it.
To explicitly flip y number from code, you can use this:

//Tile.GetTileNumbersFromCoords method, 
int y1 = Convert.ToInt32(Math.Pow(2.0, zoom) - tilesYs.Min() - 1);
int y2 = Convert.ToInt32(Math.Pow(2.0, zoom) - tilesYs.Max() - 1);
int[] ys = {y1, y2};
return (tilesXs.Min(), ys.Min(), tilesXs.Max(), ys.Max());

Then, you should also change isFlipY parameter in Image.WriteTile (the one with NetVips.Image parameter) method:

//226 string in Image.cs
(double minX, double minY, double maxX, double maxY) = Tile.Tile.TileBounds(tileX, tileY, zoom, true);

It should work for crop algorithm (didn't test on join yet).

Hope this helps you. Please, let me know if it solves your issue, and also feel free to ask more questions if you need.
I think I will add functionality for non-tms tiles in the future.

from gtiff2tiles.

The web reference https://tile.gbif.org/ui/4326/ is similar to what is implemented in Openlayers and I am not sure if openlayer also implementing non-tms naming system.

By the way the above modifications work but now the Y naming is falling into different X folders.

Using the results as similar to modifications above, the layer could not be overlaid as the same location as the base in openlayers.

Please let me know if you need a tiff file to test it out?

Also, the output png is not showing any content, unless i change to jpegsave.

Thanks

from gtiff2tiles.

Yes, that would be great, if you're able to send me that .tif.
I tested the above code on my data, and the output is the same, as MapTiler Pro creates (with the following params: -geodetic -o D:/Test/MaptilerResult -work_dir D:/Test/MaptilerTemp -srs "+proj=longlat +datum=WGS84 +no_defs" -zoom 0 11 D:/Test/map_16_4326.tif (throwing out the -tms argument)).

P.S.
I found this code in gdal2tiles.py:

if self.options.tmscompatible:
    args['tmsoffset'] = "-1"
else:
    args['tmsoffset'] = ""

I suppose, there's exactly 1 tile number for y difference between tms tiles output only for OpenLayers. So, changing outputTileFileInfo value in Image.WriteTile method like this:

FileInfo outputTileFileInfo = new FileInfo(Path.Combine(tileDirectoryInfo.FullName, $"{tileY + 1}{Enums.Extensions.Png}"));

Gives me the same result, as on that website.

from gtiff2tiles.

The link to the tiff is at (~720MB)

https://1drv.ms/u/s!AmpFsfFEKx7Ki4Va0rdy39mhQYCXCw

Perhaps you can test the tiff above with openlayer if possible.
For this particular tiff location, the tileY is deviating from the openlayer grid by a series of increment value.

I will download a new set of GTiff2Tiles and do test again on this matter, then will have a clearer picture on what is happening.

Thanks a lot for your help!

from gtiff2tiles.

Refering to this https://www.maptiler.com/google-maps-coordinates-tile-bounds-projection/

Zoom 8 , X: 202, Y:127

I have downloaded a new set and run both test on TMS turned on and off, the X folder seems incorrect.

RUN ON CROPPING:

I put the maptiler result as reference here
Google
Zoom 8: X: 202, Y: 127
Zoom 9: X: 404, Y: 254
Zoom 10: X: 808, Y: 508
Zoom 11: X: 1617, Y: 1016
Zoom 12: X: 3234, Y: 2031

TMS
Zoom 8: X: 202, Y: 128
Zoom 9: X: 404, Y: 257
Zoom 10: X: 808, Y: 515
Zoom 11: X: 1617, Y: 1031
Zoom 12: X: 3234, Y: 2064

My result is

(TMS false with +1 at Image.WriteTile {tilesY +1})
Zoom 8, X: 404, Y:127
Zoom 9, X: 808, Y: 253
Zoom 10: X: 1617, Y: 505
Zoom 11: X: 3234, Y: 1009
Zoom 12: X: 6468, Y: 2017

(TMS true, Image.WriteTile {tilesY} )
Zoom 8, X: 404, Y:129
Zoom 9, X: 808, Y: 259
Zoom 10: X: 1617, Y: 519
Zoom 11: X: 3234, Y: 1039
Zoom 12: X: 6468, Y: 2079

I can see that it has some geometric progression happening in the Y naming, while X naming is not in correct zoom level.

from gtiff2tiles.

Thank you for your tests and .tif data.

That MapTiler website uses mercator projection to generate tiles. GTiff2Tiles now is able to create only geodetic (EPSG:4326) tiles.

I've tested Tokyo dataset (approximate location on Google Maps), here, take a look at the results for 11-8 zooms.

1. MapTiler website, Google tiles. The result should be the same, as MapTiler Pro generates with -mercator and without -tms arguments (see number 3):

2. MapTiler website, TMS tiles. The result should be the same, as MapTiler Pro generates with -mercator and -tms arguments (see number 4):

3. MapTiler Pro with -mercator and without -tms arguments. The result should be the same, as on MapTiler website, Google tiles (see number 1):

4. MapTiler Pro with -mercator and with -tms arguments. The result should be the same, as on MapTiler website, TMS tiles (see number 2):

That was all for mercator tiles. These tiles uses a bit different naming and zooming systems, so the values between it and geodesic tiles are differs. Now let's take a look at the geodesic tiles tests results:

5. Tile.gbif (OpenLayers, uses geodesic non-tms tiles). The results should be same, as GTiff2Tiles generates with tmsCompatible = false and tileY+1 in path (see number 8):

6. MapTiler Pro with -geodesic and with -tms arguments. The results should be the same, as GTiff2Tiles generates with tmsCompatible = true and tileY in path (see number 9):

7. MapTiler Pro with -geodesic and without -tms arguments. The results should be the same, as GTiff2Tiles generates with tmsCompatible = false and tileY in path (see number 10):

8. GTiff2Tiles with tmsCompatible = false and tileY+1 in path. The results should be the same, as on Tile.gbif (see number 5):

9. GTiff2Tiles with tmsCompatible = true and tileY in path. The results should be the same, as MapTiler Pro generates with -geodesic and with -tms arguments (see number 6):

10. GTiff2Tiles with tmsCompatible = false and tileY in path. The results should be the same, as MapTiler Pro generates with -geodesic and without -tms arguments (see number 7):

As you can see, all the test are passed. I'll test your data too and post the results later, when I'll be able to do so.

By the way, I've tested all this with join algorithm too, and it works the same as crop, with only exception for non-tms tileY+1, which generates some odd output.

from gtiff2tiles.

I've tested your GeoTiff. There's really have been an issue with empty tiles in output. It occured, because input GeoTiff is 32 bit, and before creating tiles it should be converted to 8 bit (I've added this code with f08f690).

Regarding the tile numbers, it seems to work correctly (I've checked the output data using scheme I've written above, and got the same location on both maptiler and tile.gbif websites).

Feel free to reopen issue and ask more question, if you problem hasn't been solved.

from gtiff2tiles.

after your testing, how is your output in terms of pngsave?
In my test it render nothing, unless i changed to jpegsave

from gtiff2tiles.

Output data seems correct. DId you check it using GTiff2Tiles with the latest commits? Output tiles were transparent because of the issue, that was fixed with today's commit f08f690.
On the data, you've send above it now works as it should. Just check out lower levels, you can definetely see the data on 11 zoom for example:

from gtiff2tiles.