4/4 Support GeoTIFF data in TIFF #586
Conversation
don-vip
force-pushed
the
geotiff-support
branch
6 times, most recently
from
70dc76f
to
7bef8a1
Compare
… than passing TIFF header offsets around everywhere.
Note that while BigTIFF supports files greater than 2 GiB in size, our current implementation does not due to the pervasive use of Int32 throughout the code to represent offsets into the data.
This will only ever be a 16-bit value.
This allows combining the add and test operations into a single lookup.
If the byte order changes during extraction, a new reader is made via WithByteOrder. That new reader is naturally scoped to the sub-reading operation, and the byte order does not need to be reverted.
We have been steadily adding parameters to members of ITiffHandler. We are about to add more to support GeoTIFF. Rather than do that, introduce a new type that encapsulates this common state. This makes the API simpler, and means we can add members in future without it being a breaking change.
|
OK everything is rebased now. I have created drewnoakes/metadata-extractor-images#53 for test data. If you accept these changes, feel free to drop the last commit of this PR which added test data to this repository, before I knew about the other one. |
|
Hi @drewnoakes is it possible to merge this? I believe to have done everything that was required. |
|
@don-vip Does this support https://www.wikidata.org/wiki/Q112509098 COG also? |
|
"A Cloud Optimized GeoTIFF (COG) is a regular GeoTIFF file, aimed at being hosted on a HTTP file server, with an internal organization that enables more efficient workflows on the cloud.", so it should. |
|
@dpriskorn as Dirk said, yes it should. I had to create a release for my own project in my fork, you can give it a try to check until this PR is merged in the main repository. |
This is the fourth and final step towards solving #278
It includes:
It is based on #585. Feel free to close the three others if you prefer to merge all my work in this PR :)