Calculating value for filename_tile_size

[tombarton]

Probably an incredibly stupid question but how does one go about calculating the filename_tile_size value? I'm trying to implement a dataset for Northern Ireland. I've tiled my data so filenames follow the appropriate convention, but I can't get my head around the tile size value? I realise they're supposed to covered degrees of coverage rather than meters. Any advice would be much appreciated!

[MaRaSu]

I'm by no means an expert here, having just started to use the OpenTopoData. But based on docs, code and examples I think filename_tile_sizeis in the units of the projection being used, so it can be either degrees or meters (e.g. for my DEM dataset it is in meters). Anyhow, in the config.yamlit is given without any unit.

Run gdalinfo command on one of your tiles and observe values for Size (for pixel extent) and Pixel Size and multiple those to get tile_size (e.g. for my dataset it 3000x3000 and 2,-2 so 2x3000 for tile_size of 6000). You can also look at Corner Coordinates because they need to also reflect tile_size.

[ajnisbet]

filename_tile_size is in the units of whatever filename_epsg is set to. filename_epsg would typically be set to the projection of the dataset.

By default, filename_epsg is 4326 which is the code for lat/lon projection, so filename_tile_size is in units of degrees. But you can change this!

For example, if the projection of your dataset is TM75 / Irish Grid, that projection is in metres, so your tile size would be in metres. If your tiles were of size 2000 x 2000, at a 10m resolution, then you would use

filename_epsg: 29903  # Corresponds to TM75 / Irish Grid
filename_tile_size: 20000  # Size of tile, in metres.

In otherwords, filename_tile_size should be upper_left_y - lower_left_y, in whatever units the file is in. A limitation of opentopodata is that this needs to be the same as upper_right_y - lower_right_y and lower_right_x - lower_left_x etc

If you have access to gdal tools you can run gdalinfo your_file.tif to see what the resolution, size, projection, and bounding coordinates are as @MaRaSu suggested. If you can't figure out the settings, please share the output of the gdalinfo command here (or link to the file) and I can help with the exact settings needed.

---

That said, if you're using the OSNI 10m DTM then unfortunately it's not going to be possible to do this: opentopodata needs square tiles to do the filename coordinates trick, and these tiles are 209 x 640.

So you would need do re-tile the data files: splitting them up into even squares. Which would be most unpleasant and timeconsuming.

Instead, because that full dataset is only 300 files, I'd suggest to use gdalwarp to merge them all into a single tile (which opentopodata will easily handle!) or make them into a VRT like this: https://www.opentopodata.org/datasets/eudem/#adding-eu-dem-to-open-topo-data

---

This tiling stuff is a bit of a hack, extended from when opentopodata only worked with SRTM files. I would like to handle arbitrary datasets without having to rename a bunch of files (https://github.com/ajnisbet/opentopodata/issues/91) but haven't got round to it yet :(

Let me know how you get on!

[tombarton]

That is amazing, thank you both so much.

@ajnisbet that is exactly what I ended up doing with the NI dataset and it worked a treat.