Skip to main content

We sometimes encounter a conflict between a format attribute held by the feature and writer parameter setting, especially in a case where the writer format is the same as the reader format.

It may be difficult to define generic rules regarding which one should take priority, but in this case, I think the Compression Method parameter setting for the writer should be respected regardless of the value of "geotiff_compression_method".

Convert Packbits geotiff to lzw

How do you think about this?

Hi @takashi. I believe that if a feature type parameter conflicts with a writer-level parameter, then the writer parameter will be ignored and the feature type parameter will be used.

 

Is this what you are asking about?

Hi @takashi. I believe that if a feature type parameter conflicts with a writer-level parameter, then the writer parameter will be ignored and the feature type parameter will be used.

 

Is this what you are asking about?
Hi @NatalieAtSafe, no, I mean that there is a case where a writer (feature type) parameter will be ignored if it conflicts with a format attribute held by the feature.

 

In the question I have linked, the GeoTIFF writer works with the pack-bits compression method when the GeoTIFF reader implicitly set "pack-bits" to a format attribute called "geotiff_compression_mode", even though the user explicitly set "lzw" to the "Compression Method" parameter in the writer feature type. This happens when the source GeoTIFF raster is compressed with the pack-bits method.

Hi @takashi. I added a comment to the question after discussion with development. Improvements are planned for raster and point cloud formats (Known Issue 31125), as well as GEOTIFF specifically (Known Issue 31121).


Hi @takashi. I added a comment to the question after discussion with development. Improvements are planned for raster and point cloud formats (Known Issue 31125), as well as GEOTIFF specifically (Known Issue 31121).

Thanks for your response. Hope the issue will be resolved in the near future.

 

 


Reply