Figure.psconvert: Add support for GeoTIFF output

[EJFielding]

Description of the desired feature

In classic GMT, I have long used this command to generate a GeoTIFF file from an EPS file:

gmt psconvert -A -P -Tt -W+g $out

I see there is a pygmt.Figure.psconvert call that wraps the GMT psconvert but it does not seem to have the -W+g option to make a GeoTIFF.

The GeoTIFF output is extremely helpful for taking a GMT or PyGMT map and loading it into Google Earth or QGIS to view it with other geographic information. I attach an example of a map that I made in GMT that I converted to GeoTIFF and then opened as an image overlay in Google Earth.

Are you willing to help implement and maintain this feature?

Maybe

[seisman]

@EJFielding
This feature seems easy to implement in PyGMT.

After reading the documentation, my impressions are:

• -W creates a world file which can be used by other software
• -W+g will use this world file and convert PS to GeoTIFF
• -W+c: the doc says "This option automatically sets -A -P. Append +c to not crop the image.", so it also affect the generated GeoTIFF
• All other -W modifiers are related to creating KML files instead?

Do I understand it correctly?

[EJFielding]

I have only used the -W+g modifier for my purposes. The GeoTIFF is good for loading in QGIS, ArcGIS, and other GIS systems in addition to Google Earth or Google Maps. I have not used the KML file generation, but I imagine that others use that, so it would be good to support as well.

[seisman]

I've done a few tests to understand GMT's behavior about GeoTIFF support.

The test PS file is generated using the following command:

gmt coast -R0/10/0/10 -JM10c -Baf -W1p -ps map

I've tried the following commands:

1. gmt psconvert map.ps -Tt produces map.tif (a normal TIFF file)
2. gmt psconvert map.ps -W produces map.jpw (the plaintext world file) and map.jpg (default image format)
3. gmt psconvert map.ps -W+g produces map.pgw (the plaintext world file) and map.tiff (GeoTIFF)
4. gmt psconvert map.ps -W+g -Tt produces map.tfw (the plaintext world file) , map.tif (normal TIFF) and map.tiff (GeoTIFF).

Usually, both .tif and .tiff are valid extensions for a TIFF file. You can't tell if a TIFF file is GeoTIFF or not from the file extension. But for files produced by GMT, .tif is a normal TIFF file, and .tiff is a GeoTIFF file.

I'm wondering if we should follow the same convention as GMT? If yes, then we can provide a Pythonic user interface for PyGMT users:

• Figure.savefig("map.tif") produces a normal TIFF file
• Figure.savefig("map.tiff") produces a GeoTIFF file

As PyGMT maintainers, we just need to check the file extension. If it's tiff/TIFF, then we add the -W+g option automatically.

If we decide not to follow the GMT convention, then we may want to add a new parameter (e.g., geotiff or georeference) to Figure.savefig. If it's True, then we add the -W+g option, but users may be surprised that Figure.savefig("map.tif", georeference=True) produces two TIFF files (map.tif and map.tiff). To avoid producing two TIFF files, we need to modify the logic of the codes (i.e., don't add -Tt if georeference=True), but it still produces map.tiff, rather than map.tif provided by users. Then we may need to rename map.tiff to map.tif to make users happy.

What do you think? @EJFielding @GenericMappingTools/pygmt-maintainers

[weiji14]

If I understand this feature request, it sounds like we just need to alias -W to altmode (or some other name) here?

pygmt/pygmt/figure.py

Lines 129 to 143 in e4bd4fb

	@fmt_docstring
	@use_alias(
	A="crop",
	C="gs_option",
	E="dpi",
	F="prefix",
	G="gs_path",
	I="resize",
	N="bb_style",
	T="fmt",
	Q="anti_aliasing",
	V="verbose",
	)
	@kwargs_to_strings()
	def psconvert(self, **kwargs):

I'm wondering if we should follow the same convention as GMT? If yes, then we can provide a Pythonic user interface for PyGMT users:

* `Figure.savefig("map.tif")` produces a normal TIFF file

* `Figure.savefig("map.tiff")` produces a GeoTIFF file

As PyGMT maintainers, we just need to check the file extension. If it's tiff/TIFF, then we add the -W+g option automatically.

Should be easier to follow the GMT convention to avoid adding another parameter that can get confusing. Technically, a normal TIFF file would become a 'GeoTIFF' if there is a corresponding tfw file, whereas a GeoTIFF has the geo metadata baked into the TIFF file directly. As long as we properly document that of tif=TIFF and tiff=GeoTIFF, it should be fine, and users can always rename .tiff to .tif if needed. Personally, I don't expect many users saving their figures as GeoTIFF files (though it is a cool feature to have)!

Oh, and just to be clear, modifying savefig is more of an additional enhancement, we should make the change in psconvert first.

[EJFielding]

Hi, I have been traveling for the last week. I am not sure which implementation is best. I think the details are not so important and you can choose what you think works best with the rest of PyGMT.

I am happy to test a developer version.

[seisman]

If I understand this feature request, it sounds like we just need to alias -W to altmode (or some other name) here?

-W is a very complicated option. Its +g and +c modifiers are used to generate GeoTIFF file, while all other modifiers are related to KML format. So, aliasing -W to any names likely makes little sense. We probably need two parameters, one controls geotiff and another one controls KML. So it needs more discussions.

modifying savefig is more of an additional enhancement, we should make the change in psconvert first.

See PR #2698. We don't need to modify psconvert to support GeoTIFF.

@EJFielding I've implemented the GeoTIFF support in PR #2698. It would be great if you can give it a try. It's not finished yet. I still need to add some tests to check if the generated file is georeferenced or not.

[seisman]

@EJFielding I've implemented the GeoTIFF support in PR #2698. It would be great if you can give it a try. It's not finished yet. I still need to add some tests to check if the generated file is georeferenced or not.

Sorry, PR #2698 doesn't work yet. Need more time to find out why.

Edit: Now PR #2698 should work.