Displaying a study area in ArcMap


I am trying to create polygons using ArcMap to showing my study areas of Enceladus. I used camtrim to extract my study areas in ISIS, so I have a record of their lat/long ranges. I imported these values from Excel to ArcMap using a Geographic Coordinate System (GCS) I found on a feature nomenclature layer downloaded from the IAU page. It uses GCS_Enceladus_2003 and D_Enceladus_2003 datum.

I then proceeded to display the polygons I have created by overlaying them onto a south polar mosaic (downloaded from here) layer. This layer is in Sterographic_South_Pole projection and uses D_Enceladus datum.

Comparing my trimmed cube to the overlayed polygon, there is a slight discrepancy (perhaps due to differences in datum?).

This has been my approach, but perhaps there is a better way of showing one’s study area. Would appreciate getting an input on this matter.

(I hope this is the right place for my question; I can move it if necessary).
Thank you!

1 Like

Hi @BereketDM,

FYI - You can open isis cubes directly in ArcMap for comparison to a base mosaic.

There are ways to export an ISIS image polygon to Arc, but I’m not as well-versed in that as others (@thare). You will have to run footprintinit on your images to have a polygon written to the label though, it’s not automatically there.

I am not completely clear on how you are using camtrim to get that information. That program is typically used to set pixel dn’s to NULL that fall outside of a user specified lat/lon range. The program camrange will provide min/max lat/lon info in regard to an image, but that is not the same as a footprint polygon. Just having the corners of an image doesn’t adequately describe it’s shape.

The mosaic you are comparing to is a controlled product that projected the data to the mean radius of 252 km. Additionally, a new prime meridian was derived while creating the network to ensure the center of the prime meridian defining crater Salih is located at 5 degrees west. I’m not sure about the datum offset, but the change in prime meridian in that product would differ from the default IAU values acquired via ISIS spiceinit. Most importantly, if you did not tie your images to the base you are comparing to and constrain those points in jigsaw, then you are not likely to match the base perfectly.

From the site where you downloaded the south pole mosaic:

All images were map projected to the IAU mean radius (252.1 km/pixel). The map is an equidistant (simple cylindrical) projection and has a scale of 110 meters (360 feet) per pixel at the equator. The mean radius of Enceladus used for projection of this map is 252 kilometers (157 miles). Like other recent Enceladus global maps, this mosaic was shifted 3.5 degrees to the west to be consistent with the International Astronomical Union (IAU) longitude definition for Enceladus

Could you share a screen shot of the problem so we can better understand the issue?

Hi @lwellerastro,

Thank you for your response, and sorry if my question was not clear enough.

So I started with level 1 cubes (spiced using the improved camera pointing kernels you provided me several months ago; I believe this removes the longitude offset you mentioned). I used camtrim to set pixels outside a determined lat/long range to NULL, then ran cropspecial to crop out special pixels. This leaves me with pixels covering the area I would like to study.

What I want to do is show on the south polar mosaic the study areas I created by simply overlaying a polygon feature in ArcMap. I created the polygon feature from the min/max lat/long values I determined in the previous step and by specifying a GCS from a feature nomenclature Iayer downlaoded from the Gazetteer of Planetary Nomenclature. Here is how I did it exactly.

Here are screenshots of my results. The first one shows the extracted studied area and the the level one cube it was extracted from. The second is the polygon feature I created overlayed on the south polar mosaic. You can see differences in coverage at top of the polygon where there is a prominent trough on the surface. The feature is included in the first screenshot but not in the second. There is also a slight difference at the bottom side of the polygon, where a darker, curved feature is included in the second image but not in the first.

Hopefully, I have done a better job of describing my problem. Please, let me know if there are still steps that are unclear.

1 Like

Thanks for sharing the screenshot @BereketDM! This is really outside my scope - I work almost exclusively in ISIS and don’t use mapping software outside of it often except for the most basic of steps. Let’s give others a moment to catch up and see what the Arc users think might be happening with the polygon.

However, the things I pointed out in my previous reply still stand - you’re not tied to that base map and therefore are not likely to register it to well. The kernels I provided you earlier this year are a different product than the base you downloaded and in fact supersedes it. The kernels I provided are based on a network having more images than the 2016 product and are based upon improved spacecraft kernels that were released by the mission after the 2016 product was generated. Because of the additional images and changes to spice, the newly bundled images likely moved some and also resulted in a different prime meridian than the 2016 product.

We did not have funding remaining this year to recreate new mosaic products to compare against the 2016 work so other than differing values coming out of the bundle adjustment, we are not sure how much the new kernels will shift the data when compared to the 2016 mosaics.

I would expect to see a difference between products created using the kernels I supplied and the 2016 mosaics. I’m sorry you are running into this, but we are currently working on documenting some of this and making the kernels public.

Since you screen shot has an image name, I will take a look at the 2016 version of that image (if it exists - it might be one of the newer images added) and compare it to the most updated version to see how much of a shift exists. I’m not sure I can get to that this week though, but I’ll let you know what I see when I do get a chance to look.

1 Like

Ah, okay; makes sense. Thank you @lwellerastro for your attention to this issue.

1 Like

You might want to try this to see if it helps. ArcMap only projects the vertices it has access to in the polygon or line. Thus it is simply projecting 4 points of your polygon. You can try to “densify” the polygon with vertices and then try to map project which should allow for smooth curves.

In a new ArcMap, just add in the polygon. In the toolbar or search window type “densify”. Select the Densify (Editing) tool. Setting the units to decimal degrees and a Distance of 0.1 should be plenty of new vertices for a nice curve. Once run, open up your project with polar stereographic and add in this updated footprint file.

Thanks for chiming in @thareUSGS! @BereketDM, I think this is more of a problem with the polygon than the data. The image you are working with was in the original 2016 control network and basemap and a part of the starting point for the most recent work. The newly controlled image and originally controlled image match re markedly well. This is really good news because it means the base you are using to show where your research area is should align well with your study area image (that is all I checked, so there might be slight mismatches for other images/locations).

As @thareUSGS pointed out, it seems to be more an issue with the coarseness of the shape polygon. I am going to review some old notes in regard to getting a footprint polygon out of ISIS and into Arc (something I did long ago) and see if I can reproduce those steps. The other complicating factor (I think) is that you are not working with the entire image that contains your study area, but rather a chunk of it. I’ll have a look at some things and let you know if I find something useful, especially if the polygon densification doesn’t work the way you hope.

Thank you both @thareUSGS and @lwellerastro for your posts.

I tried to densify my polygon as @thareUSGS suggested, but it doesn’t seem to be making any difference.

@lwellerastro, it’s good that you found a good match between the new and older controlled images. I do plan to repeat what I am doing here at other locations from the same image, but I will see how this turns out first.

Could a difference in datum be the source of the issue? As you can see below, the south polar mosaic uses D_Enceladus while the polygon uses D_Enceladus_2003. But then again the semi-major/minor axes values of the polygon and the dataframe (after adding the mosaic layer first) are the same. I am not too versed in how these things work, so I’m hand-waving a little here.

Mosaic Coordinate System

Polygon coordinate system

Data frame coordinate system

@BereketDM, I can not find a way to nicely clip out an area and it’s polygon in ISIS for further work in Arc, but as I mentioned before, my Arc experience is limited. Seems to me all of your coordinate systems need to match, but I honestly don’t think that will fix your polygon. There just aren’t enough data points to best describe the shape.


Okay. I will try to find other methods if possible or perhaps determine more data points for the polygon. Thank you for trying.

What lat/lon range did you use for camtrim and what did you use for the map file? Just in case I get any ideas it would be helpful to know specific lat/lon range you used. Thanks!

For the polygon in the above screenshot, lat range is -65.0 to -55.0 degrees and the long range is 136.0 to 170.0 degrees. I didn’t use any map file; just left the field blank. Thanks again!

1 Like

Hi @BereketDM, I have something you might want to try for improving your polygon in ArcMap. It’s essentially a way to get more points to better describe your polygon.

Start with your camtrimmed, cropspecial area of study and run footprintinit on it using the defaults

footprint from=trimcrop.cub

The default is to walk the image boundary every 100 lines and 100 samples to build up a polygon. You can also make that finer, but that will result in more vertices which might be more than you need. You can also specify an inctype=vertices and ask for a specific number of vertices. Start with the default as that is likely plenty. The polygon information is stored in a table on the file that is not human readable.

Run the program caminfo and have the polygon vertices information reported in a human readable format. The output is not as nice as I would like, but you can get what you need from it.

caminfo from=trimcrop.cub to=info.pvl geometry=false uselabel=true

geometry is true by default, but we don’t need that info now so I set it to false. uselabel is part of the polygon output options and tells the program to use the polygon information already stored on the label (otherwise you can run the polygon process here on the fly, but it is not stored on the image).

Here’s what the GisFootprint information looks like in the Polygon output for caminfo for your images using the camtrim information you supplied me earlier:

GisFootprint = “MULTIPOLYGON (((149.9355977706205465
-47.6443188005552329, 160.9339545789757722
-52.3205254193069607, 173.8797411889152613
-55.8902603217638969, 176.2093257385774905
-56.3890784978853148, 170.3497769582220656
-64.5510879306014687, 159.1810679794427870
-72.8074695611632734, 140.5039200711113665
-67.1294165965472729, 128.5233898726329471
-60.4700816909435162, 126.9758000911804743
-59.2878792578666634, 140.5019345059907891
-53.9593086919343961, 149.9355977706205465

Those are longitude/latitude pairs and unfortunately not easy to read since they are staggered. There are some ways to get this into other formats, but with so few vertices it probably won’t take too long to put those into the Arc app to build up a polygon from xy data. If this works the way you hope then an easier method of extracting the polygon vertices would be desired since you said you had other areas you wanted to apply this process to.

Let us know how it goes!

In case the above is not adequate… @thareUSGS, can you ogr2ogr and isis cube with a footrprint and bring that into Arc? I have done it hitting a database containing polygon information, but not an isis cube. For some reason I am reminded of a script you might have offered Tammy years ago to something like this…am I remembering correctly?

Hi @lwellerastro,

Thanks your for your replies. I followed your suggestion by running footprintinit and caminfo, and here is the result. It appears a little worse than what I got initially. I am not sure why but the GISFootprint has polygon vertices outside the lat/long range I used when running camtrim. Perhaps, it is due to the presence of NULL pixels with valid lat/long information outside the edges of the camtrimmed, cropspecial area. I will try other approaches and see what works.

Maybe if you can share the data we can look into it more. There are many ways to get footprints using ISIS, GDAL, ArcMap but none are perfectly automatic. I even have some older code (which would need Python v3 updates), to extract a footprint from a cube (after footprintinit or isisminer) and save out a shpefile (using GDAL – see ogr_*): https://github.com/USGS-Astrogeology/GDAL_scripts

But before going down that path, having sample data either your cube or shapefile (includes all the *.shp, *.dbx, *.shx, ect. files) for testing would be great.

BTW, the datum names being different is fine. The radii are the same which is the key.

Hi @thareUSGS,

Yes, I can share my data. I don’t know if it’s possible to share files on Astrodiscuss; would email work?

Yes - you can just zip up the files to help bring down their size. thare@usgs.gov

Just sent you my files.

@BereketDM, Yes using the footprintinit polygon you sent (and I also tested), the outline is oddly around the NoData (Special pixels) – not just the image pixels. The pixels are correctly set as NoData and I am sure footprintinit follows the pixel data only so that is odd behavior to see from footprintinit. I’m not sure what is going on. UPDATE: I was told this was because footprintinit uses the camera model not the valid pixels to walk the image’s edge which is generally what you want for non-map projected (level1) data. So again, this means running a camtrim will not impact the footprint boundary when running footprintinit (see more from Lynn below).

Anyway, just to get you something I took your cube and did a 3rd polynomial warp using ArcMap’s georef tool (link). Not recommended for standard workflows, but can help in a pinch.

I sent you the updated image files (1) copy of the cube, (2) *.cbw (GIS worldfile) lists the output 6 parameter affine and (3) *.xml, lists the ground control points used to warp the image. ArcMap will apply that transformation on-the-fly upon loading this *.cub.

Then I did a raster “reclassify” tool to map all valid pixels to 1 (resulting in a 8bit file with pixel values set to 1 and the collar still NoData). Then I ran “raster to polygon” tool to outline the image. The shapefile in projection is shown in the jpeg.

Not great for lots of images but again perhaps works in a pinch. Ideally the path should be to run cam2map to polar stereographic and then bring that into ArcMap. Simply setting the image symbology to a single value with transparency would allow you to show your region of interest (or you can reclass and convert to a polygon). BTW, just because you run cam2map doesn’t image the image will be perfectly placed – that is dependent on the spacecraft pointing (SPICE) and the image still might need to be moved into place (or better yet bundle adjusted with other images and a basemap in ISIS).

1 Like