Refrain from transforming CRS of input data to CRS of TMS if input data is already in that CRS

[julietcohen]

In TileStager.py, we execute set_crs() for every input geodataframe and transform it to the CRS of the TMS. For certain input data, it may be advantageous to only do this transformation if the CRS is not already the CRS of the desired TMS.

During processing of the Circum-Arctic Permafrost and ground ice map, the polygons near the Arctic circle become corrupted when transformed from the projected CRS Sphere_ARC_INFO_Lambert_Azimuthal_Equal_Area to WGS 84. We need to execute this transformation in order to tile the data in the TMS WGS1984Quad. In order to resolve this issue, a possible short-term solution before processing the data with viz-staging is to manually transform the input data to that CRS and then clip the polygons with a mask. However, if the data is transformed to that CRS again during staging, the polygons will likely be corrupted again in the same way.

As a result, we should first check if the input data needs to be transformed before we do so. If we refrain from unnecessarily transforming it, we can avoid corrupting certain input datasets.

This issue is very similar to #26.

[julietcohen]

Update: The geometries that became invalidated when the CRS of the input geodataframe was transformed into the CRS of the TMS turned out to be only 6 geometries that intersected the antimeridian. This is a common problem in geospatial sciences that deforms the geometries to wrap the opposite way around the earth, creating ring-like shapes.

It still may be advantageous to refrain from transferring the CRS if it is already in the CRS of the TMS to save time with large datasets, but the amount of times this saves hasn't been tested and may be negligible.

For this situation, it would be more helpful to just check for any geometries that intersect the antimeridian, and remove or split them (so they are on either side of the antimeridian). This could be done manually with with a check (see the script in the issue comment here) and function to shift the geometry vertices, or the data can be transformed into geoJSON format and the antimeridian package could deal with them.