Project

General

Profile

Crash #947

isis2pds hidtmgen fails with Polar Stereographic product

Added by Tammy Becker over 5 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Applications
Impact:

no impact

Software Version:
Test Reviewer:

Description

External Post:
https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,3403.0.html

Original Post Date: 20Feb2012

Description:
Hello,

I am incorporating some modified processing in SOCET Set to work on polar DTMs in polar coordinates. The export of these from SS to ISIS produces cubes that have mapping groups in their labels that do not include min/max lat/lon. This causes hidtmgen (isis2pds?) to fail. In the past we have used hidtmgen successfully to produce Polar Stereographic projects but in SS they were generated in the typical geographic coordinates and had the min/max lat/lon keywords in their labels.

I have heard that ISIS3 can georeference with just the upper left corner map coordinates, and that lat/lon ranges are not necessary.

Thanks for your help with this.
Sarah

Below is an example of the mapping group in the cube exported from SOCET Set (polar processing):

New polar dem2isis3 script results:

Group = Mapping
ProjectionName = PolarStereographic
CenterLongitude = 0.0
TargetName = Mars
EquatorialRadius = 3396190.0
PolarRadius = 3376200.0
LatitudeType = Planetocentric
LongitudeDirection = PositiveEast
LongitudeDomain = 180
UpperLeftCornerX = -464283.5
UpperLeftCornerY = 224634.5
PixelResolution = 1.0
Scale = 58925.806205833
CenterLatitude = -90.0
End_Group
End_Object

Hidtmgen fails with this error message:

PVL ERROR Keyword [MaximumLongitude] does not exist in [Group = Mapping]

Report to moderator Logged

michaelaye
Ra (Power Member)

Posts: 118

Re: isis2pds hidtmgen fails with Polar Stereographic product 

« Reply #1 on: February 25, 2012, 02:54:10 PM » Quote Modify Remove Split Topic


Hi Sarah,
as I wanted to understand this myself, having a DTM here without the ground range defined, I digged a bit into this.
I believe it is not possible to properly work without the lat/long max/mins defined, because according to what I see, the upper left coordinates relate to the pixel(0,0) of the map projected image, meaning in most cases of map-projected data this will be a black pixel outside the imaged region.
Therefore I believe the ground range is the only information in the label precisely defining the imaged map-projected region inside the whole frame that can not be calculated just from the coordinates of pixel(0,0).
Do I make sense?
Michael

Report to moderator Logged

michaelaye
Ra (Power Member)

Posts: 118

Re: isis2pds hidtmgen fails with Polar Stereographic product 

« Reply #2 on: February 26, 2012, 12:11:04 PM » Quote Modify Remove Split Topic


I got second thoughts on this. A mathematical operation should not care if the pixel content is filled with something relevant or not. Therefore it should be possible to calculate the ground range extent via the sample/line and the upper left corner ground reference values.
Therefore I checked the code of hidtmgen again to see what does it need the ground range for. And it seems that all it needs these values for is to calculate a PDS label keyword called "NORTH_AZIMUTH". I don't know what that is required for, but I know that my standard polar stereographic ISIC mosaics created fully inside ISIS don't have this keyword defined in their labels.
If it's only a "nice-to-have", maybe one could make the calculation of the NORTH_AZIMUTH optional?

Michael

Additional information:

elevated triage from 3 to 5; since it involves a crash


Related issues

Related to ISIS - Bug #1500: Problems with crop and automos Closed
Related to ISIS - Feature #1503: Create a new class and associated application to calculate the Lat/Lon extents of an image Acknowledged

History

#1 Updated by Tammy Becker over 5 years ago

Elevated triage based on related phocube post, hirise team is waiting for a solution

#2 Updated by Tammy Becker about 5 years ago

Q2S7 Task.

#3 Updated by Elpitha Howington-Kraus almost 5 years ago

Tracie stopped by to get some feedback on this ticket, and requested a sample input file.

For the record, this issue is not limited to Hidtmgen. Polar Stereographic map products produced in Socet Set can only be geo-refereneced using the upper-left pixel (as in ARCMAP) - which omits a lat/lon range on the labels. This causes some ISIS3 programs to fail (e.g. automos, Hidtmgen), and causes problems when exporting these cubes to ISIS2 and PDS which require a lat/lon range on the labels.

Here is an example problem cube:

/work/projects/socetset/ahowington/Mars_Polar_Output_Products/PHX_LS_1_edit_dg.cub

To see how it was generated, please see:

/work/projects/socetset/ahowington/Mars_Polar_Output_Products/PHX_LS_1_edit_dg_dem2isis3.sh

#4 Updated by Tracie Sucharski almost 5 years ago

I have unassigned this from Kim due to complications that will be discussed in the 2/15/2013 Developer's Mtg. This might be a more complicated problems which will probably be > 20 hrs.

#5 Updated by Tammy Becker almost 5 years ago

Unassigned from Q2. This issue goes beyond just a single application. Estimated hours are now greater than 20.

The development team decided to create a new class that will calculate the lat/lon extents of an image and update the mapping group labels. There will be a application created for this purpose; as well as other existing applications such as crop can call this class to add the functionality.

This post will be related to the new class ticket.

#6 Updated by Tracie Sucharski almost 5 years ago

After discussion in Developer's Mtg on 2/15/2013, decided to create a Class and an app to determine the lat/lon ranges for output to cube labels. Applications such as crop, would use the class. The app would be available for other projections where the range is not normally put in the labels or for creating pds products which require these keywords.

Possible algorithms for finding the range:
4 coners
walk the edges (footprint algorithm)
project each pixel

#9 Updated by Anonymous over 4 years ago

  • Target version deleted (150)

#12 Updated by Stuart Sides over 2 years ago

  • Assignee set to Makayla Shepherd

#13 Updated by Makayla Shepherd over 2 years ago

  • Status changed from Acknowledged to In Progress
  • Target version set to 3.4.11 (FY16 R1 2015-10-28 Oct)
  • Impact updated (diff)

#14 Updated by Makayla Shepherd over 2 years ago

  • Status changed from In Progress to Resolved

#15 Updated by Makayla Shepherd over 2 years ago

To Test: setisis /work/projects/isis/latest/m00947/isis

#16 Updated by John Shinaman over 2 years ago

The issue with the ingestion by "isis2pds" has been resolved. Tested on data listed by Annie.
Jac

#17 Updated by John Shinaman over 2 years ago

The location of the test results is /work/users/jshinaman/Support/RM_0947.

#18 Updated by Tammy Becker over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF