Tracking: GeoTIFF support

[HeroicKatora]

It's not quite clear how much we want to move into the main library as a feature or if it should live in a separate crate. The split could be similar to gif/gifski where the format gives access to the format while the latter interprets and composes the individual parts with a high-level interface. In any case, GeoTIFF naes a few custom tags which we definitely want to support:

// GeoTiff
pub const MODELPIXELSCALE: Tag = Tag::Unknown(33550);
pub const MODELTIEPOINT: Tag = Tag::Unknown(33922);
pub const MODELTRANSFORMATIONTAG: Tag = Tag::Unknown(34264);
pub const GEOKEYDIRECTORYTAG: Tag = Tag::Unknown(34735);
pub const GEODOUBLEPARAMSTAG: Tag = Tag::Unknown(34736);
pub const GEOASCIIPARAMSTAG: Tag = Tag::Unknown(34737);

// GDAL
pub const GDALMETADATA: Tag = Tag::Unknown(42112);
pub const GDALNODATA: Tag = Tag::Unknown(42113);

@Farkal Further discussion on the GeoTIFF specific problems here. I've hidden our comment chain in the other issue.

[Farkal]

I think we should choose where we stop the implementation of Geotiff.

• Tags ?
• Decoding specific tags ? (GDALMETADATA are stored as xml)
• Getting image from coordinates ? From X, Y, Z ? (for tiled cloud optimized geotiff)
  If we just want to add some tags the one you listed are a good start and as I said we can add some function to get the origin and the resolution.
  If we want to go any further we will have to add proj and include some math to get the image from coordinates and i don't think this need to be there.

[ruffson]

I added support for reading out and parsong the geokey dir and the additonal tags.

Currently I think it would be enough to either just return a hashmap with the geokey dir entries or make the values paris available via a method similar to the get_tag method. I will PR my branch later today and we can discuss there.

[ruffson]

@Farkal How far are you with your implementation of geotiff support? Maybe we can work together on some of this?

[Farkal]

I have create my own little lib here that just read the geo tags i need https://github.com/Farkal/rust_geotiff

[ruffson]

I have create my own little lib here that just read the geo tags i need https://github.com/Farkal/rust_geotiff

Ah and is this based on the georust/geotiff repo?

[Farkal]

Yeah but i didn't implement the function getting pixel value because it doesn't fit my use cases

The issues is the use cases, currently i use cloud optimized geotiff (COG), i only need to decode the index and the size and forward the range to s3. It's difficult to make a generic lib for geotiff because the format and the tags used can change, there is also the cache management (optimise request to s3) etc... And today i think the zarr format would be better for this use case than the geotiff (it's complicated to debug geotiff and explore data inside a geotiff because the format was made for image and adapted for geo data, it's also very bad when you start having multiple dimensions (time, altitude)).

But we can define some common uses cases and try to make a lib together yes 😉

[ruffson]

Yeah but i didn't implement the function getting pixel value because it doesn't fit my use cases

The issues is the use cases, currently i use cloud optimized geotiff (COG), i only need to decode the index and the size and forward the range to s3. It's difficult to make a generic lib for geotiff because the format and the tags used can change, there is also the cache management (optimise request to s3) etc... And today i think the zarr format would be better for this use case than the geotiff (it's complicated to debug geotiff and explore data inside a geotiff because the format was made for image and adapted for geo data, it's also very bad when you start having multiple dimensions (time, altitude)).

But we can define some common uses cases and try to make a lib together yes wink

Okay interesting, although I have to desire to work with COGs, I wish we could work together on a library that interprets the geo data from TIFFs and makes it available for other geo libraries like I stated here. However it looks like many of these efforts are made to solve a specific problem (some application), which is also the case for me. A consolidated effort with work devided up, would be sweet.

The georust org looks pretty good, it just needs a thin layer that interprets the TIFF data and makes it available.

[Farkal]

Ok so i think you should list you use cases here or you can open a new issue in my lib and we could try to define a common design 😉
Then we could propose to the georust group to take it

[ruffson]

Ok so i think you should list you use cases here or you can open a new issue in my lib and we could try to define a common design

My requirements are relatively simple: I just need to project between raster and geo coordinates.
But the reason why I am more interested in parsing more of the geodata is, that I am also building a (geo)TIFF image viewer and would like to display as much geo meta data as possible. Which is just a bit of tedious work. (That is more of a debug tool than anything else)

[Farkal]

What do you mean exactly by project between raster and geo coordinates ? You have bounding box of coordinates and need to get the raster values ? You have point coordinates and need the pixel value ?
As i use cog i need to get raster from X,Y,Z on a tile grid, this can be converted to a bounding box of coordinates on a Z level so it could also match the bounding box use case but not the pixel one.

[ruffson]

I don't care about elevation data (and my data doesn't contain that) but for a given coordinate in raster space [X,Y] I need to know the coordinates in model space.
And vice versa for coordinates given in model space I need to find the raster coordinates in my image (given, that my images contains these model coordinates). (Also I am doing this for Mars currently)

[Farkal]

In cog Z levels are not elevation but resolution levels from a tile pyramid. I suppose you need to be able to read any projection (what is the mars projection?). Do you plan to use proj as dependencie or did you try with proj5 (proj in rust) ?

[ruffson]

I suppose you need to be able to read any projection (what is the mars projection?).

Nope, at this point all my data uses equidistant cylindrical projection.

Do you plan to use proj as dependencie or did you try with proj5 (proj in rust) ?

Oh man proj5 looks sweet, at this point I thought of doing it myself, but I will have look into this. Sometimes it is hard to tell which Rust packages are mature enough to use and which take more effort to make them work vs. doing it yourself.

[Farkal]

Ok currently i hardcoded my proj resolutions and i also force the geotiff grid to match mercator because i didn't want to have proj5 or proj as dependency for only one projection. Equidistant is EPSG:4326 no ?

[ruffson]

Sorry, needed to take a break.

Ok currently i hardcoded my proj resolutions and i also force the geotiff grid to match mercator because i didn't want to have proj5 or proj as dependency for only one projection. Equidistant is EPSG:4326 no ?

It should be EPSG:1028. Actually it is super simple, if you know the corner points (tiepoints) in raster and model space, you can just linearly interpolate between them.
In my particular case, the data is really easy to deal with as it turns out. Each pixel is 5mx5m, from the top left tie point I can convert any raster coordinate into model space and to convert to degrees I just convert by using the circumference.

Nevertheless I am currently working on parsing all geotiff key codes into enums in my geo repo, which makes it easier to work with them. But for my particular use case there is actually surprisingly little I have to do in terms of projections.

[VaasuDevanS]

Hi. Can one use this library to read / write any GeoTIFF file preserving all it's basic attributes (crs, nodata etc.,)?

[fintelia]

@VaasuDevanS not easily, but you may be able to implement it based on the APIs we expose