Prime meridian projection issues

I’ve been having some issues with image projections where the prime meridian is present in the mosaic. Anytime I project image in this situation, it gets split in half with a giant section of null pixels in the middle. This can lead to images getting excessively large when projected at full resolution. In one example, I have an image that’s roughly 57000 pixels wide.

The one way I’ve figured out how to keep images from doing this is to project up to the 0 or 360 longitude point and then add padding past that point. I’ll then project the original using the padded image as the match image (with the matchmap parameter set to yes). This can be finicky. Sometimes it works and other times it doesn’t.

The main problem is that project requires that I deliver the finished products in 360 positive east longitude, and projecting images this way always switches the longitude convention to 180. I’ve been totally unable to figure out a way to switch an image in this situation back to 360 longitude. Is there a way to do this?

Here’s an example of a mosaic that I’ve been having this problem with:

Hi Marty,
Projecting images that cross the prime meridian or anti-meridian is often tricky. I want to make sure I understand your situation: You want to create a mosaic in a simple cylindrical projection with the prime meridian on the left edge and 180ºE in the center. Is that correct?

What is the sequence of ISIS commands that you’re using to create the final mosaic? Can you share the map template you’re using?

Hi @mvalenti-seti - the software is working as intended, though I understand why this is a problem. For some data (lower resolution usually and with disk present) projecting to essentially the entire globe is not an issue, but higher resolution data is for sure a problem.

The main problem is that project requires that I deliver the finished products in 360 positive east longitude, and projecting images this way always switches the longitude convention to 180. I’ve been totally unable to figure out a way to switch an image in this situation back to 360 longitude. Is there a way to do this?

You should be specifying londomain=360 centerlongitude=180 in your map file and setting lonseam=continue on the command line to make images match the domain, but then you get longitude boundary images being split in two, like your example image.

The only way I have been able to work through this sort of situation is to purposefully break up an image into 2 projected parts if I want/need to maintain the longitude domain. I would run camp2map (as an example making up number here) setting the longitude range to say 0-5 for one part and 355-360 for the other. You could add a 0.5 degree padding on those (-0.5 instead of 0 and 360.5 instead of 360) to ensure overlap - this is something I have seen others do many times over the years. Obviously the min/max longitude would be whatever is appropriate for your particular image. This is a fine way to do for a few images, but if the data set is large and you trying to automate this, you will need a script to help out.

I don’t quite understand what your work around does that doesn’t always seem to work for you - commands sometimes are more useful to me.

In this situation using cam2map is not feasible. I’ve basically redone the Callisto basemap, except for the voyager images since map projection see to be broken for voyager images. I’ve been chopping up sections of various other mosaic that I spent months putting together to create the finished products. I have to use the map2map for this and I see that there’s no lonseam=continue parameter for map2map.

The situation is much more complicated, but this what I’ve been doing:

1.  First I'll project the image up to prime meridian.  I'll set the default range set to 270-360.

    map2map from=valhalla_mosaic.cub to=valhalla_mosaic_simp.cub map=simp.map pixres=map defaultrange=map

2. The I'll add padding to push it beyond the prime meridian.

    pad from=valhalla_mosaic_simp.cub to=reference_mosaic.cub right=2000

3. Then I'll use the padded image as the map.

    map2map to=valhalla_mosaic.cub to=valhalla_mosaic_simp.cub map=reference_mosaic.cub matchmap=yes

This always ends up with the longitude getting switched to 180. The results are rather unpredictable. I just tried this and it wiped away all the coordinates in this example

I tried breaking up the image into two sections on either side of the prime meridian. What commands are you using to join the images? Anything I’ve tried has resulted in large center space of null pixels.

(The formatting on that list above is giving me some trouble. It doesn’t look how I intended it to look.)

Also, I should include an example map template:

Group = Mapping
  ProjectionName     = SimpleCylindrical
  CenterLongitude    = 330.0
  TargetName         = CALLISTO
  EquatorialRadius   = 2409400.0 <meters>
  PolarRadius        = 2409300.0 <meters>
  LatitudeType       = Planetocentric
  LongitudeDirection = PositiveEast
  LongitudeDomain    = 360
  MinimumLatitude    = -23.0
  MaximumLatitude    = 63.0
  MinimumLongitude   = 270.0
  MaximumLongitude   = 360.5
  PixelResolution    = 397.81955934683 <meters/pixel>
End_Group
End

Thanks for the extra information Marty. I misunderstood that you wanted to work with you current map and not go back to reprojecting data. I need to think about this for a minute and maybe even try to emulate the problem on my end with data I have on hand. I don’t have any experience using pad so can’t comment on that step and would likely try something different.

It’s possible you discovered a bug with map2map - switching the longitude domain to 180 despite asking for 360.

I wonder if @thare has insight into this (because I think he has spent more time fiddling with mosaics after the fact than most others in Astro)?

Seeing the pad command is helpful. It looks like you’re trying to create a mosaic that “hangs over” the right edge of a 0-360 longitude domain by right padding a projected image whose eastern extent is already at 360:

There are ways to do this, but it’s non-standard and will not interoperate well with other datasets or applications.

If you must deliver a single file in the 0-360 longitude domain, the standard way to handle this is will result in a large region of NULLs in the middle, as in your earlier screenshot.

If you can deliver multiple files, then it would be straightforward to run map2map twice on the original input, but specifying different extents each time in order to have the output match only the regions on the left and right side of the 0-360 longitude domains. This would eliminate the problem of an overly large file, while still meeting the requirement to use the 0-360 longitude domain. (If the end product will be used outside of ISIS, there is also the possibility of creating a virtual mosaic from the 2 images using GDAL and the gdalbuildvrt tool. Desktop GIS software such as QGIS and Arc will read the .vrt file and treat the 2 images as a single mosaic.)

Just to emphasize something @lwellerastro said earlier, the CenterLongitude of projection should be set to 180 in the map template. This is considered best practice when working in simple cylindrical with globally-extensive data and using the 0-360 longitude domain.

The person I’m working with has figured out of way to fix this problem with gdal. I was hoping to find a way to do this within in Isis, since it’ll add extra layer of complication when I’m putting things together. Currently, I don’t have any software that can use geotiffs. With Callisto there happens to good NIMS coverage, and interesting features right around the prime meridian. With Europa, the last moon I was working on, not so much.

I’ll use 180 as the center longitude from here on out. I had been using either the center of the longitude range, or the center of the main feature the mosaic is covering.

Just in case you want to look at the files I’ve been trying this on, I uploaded them here:
http://phillips.seti.org/mvalenti/Callisto_mosaics/failures/360-180_projection/

Thanks for pointing to the files you’ve been working on. I normally use GDAL to perform longitude domain swaps for global mosaics, but I was able to use ISIS to create a cube in the 360 domain that overhangs on the left (rather than on the right, as in my sketch above).

  1. I created a map template describing a simple cylindrical projection centered on 180ºE:

Group = Mapping
ProjectionName = SimpleCylindrical
CenterLongitude = 180.0
TargetName = CALLISTO
EquatorialRadius = 2409400.0
PolarRadius = 2409300.0
LatitudeType = Planetocentric
LongitudeDirection = PositiveEast
LongitudeDomain = 360
MinimumLatitude = -23.0
MaximumLatitude = 63.0
MinimumLongitude = -90.0
MaximumLongitude = 20.0
PixelResolution = 397.81955934683 <meters/pixel>
End_Group
End

  1. map2map from=valhalla_mosaic_simp180pe_mv01_str.cub to=valhalla_mosaic_simp180pe_mv01_str_360_c180.cub map=callisto_eqc_c180.map pixres=map defaultrange=map, with the input file from here.

Because the mosaic overhangs on the left of the 0-360 domain, it’s visually similar to a map centered near 0º in the +/- 180 domain. The significance of the longitude domain breaks down when the data extend outside of the domain. Would this still meet your requirements, or do you need it to overhang on the right?

Edited to add:
You can create a cube that will overhang on the right by changing the min/max longitude values in the map template above to

MinimumLongitude = 270
MaximumLongitude=380