Hexagon Geospatial
MENU

Spatial Modeler

Discuss topics with other Hexagon Geospatial Product pioneers and experts to get the most out of our products.
Showing results for 
Search instead for 
Do you mean 
Reply
Highlighted
Occasional Contributor
Posts: 6
Registered: ‎01-23-2019
Accepted Solution

Spatial Modeler backward compatibility for .gmd model (Processing Properties)

Hello,

I have noticed a problem after my update from ERDAS 2016 to 2018.

 

Previously, if I opened a .gmd from Legacy Spatial Modeler in the Spatial Modeler, there was a 'Processing Properties' ribbon button defining global processing properties (window rule, pixel size etc...).

The model was then run according to the processing properties defined in the model (in my case Window rule = Union).

 

Since my update to ERDAS 2018, it seems that these 'Processing Properties' are not taken into account anymore. The ribbon button is still there but the model keeps running with Window rule = Intersection.

Of course, it stil works in the Model Maker (legacy) but I want those old .gmd models to run correctly in the Spatial Modeler as I am calling them from Python (m = modeler.Model(...))

 

Is it a known bug? Do you know any fix or workaround? (I would prefer to avoid converting all my .gmd models to .gmdx and adding some 'Define processing area' operators...)

 

Thanks

Nicolas

 

 

Staff
Posts: 590
Registered: ‎02-02-2016

Re: Spatial Modeler backward compatibility for .gmd model (Processing Properties)

Hi Nicolas,

 

You will need to set the Window rule for your model in the legacy Model Maker (Model menu > Set Window) or you can use the Define Processing Area operator to set the window rule in the Spatial Modeler.

 

Kind regards,

 

Stephen Bent

Hexagon Geospatial Support

Occasional Contributor
Posts: 6
Registered: ‎01-23-2019

Re: Spatial Modeler backward compatibility for .gmd model (Processing Properties)

Hi all,

I made a little example of my problem.

 

I have 2 rasters having 2 differents extents.

rasters.PNG

I have a simple gmd in Model Maker (see attached) that mainly "merges" the 2 rasters. Global processing window is set to Union of inputs. Here is the function used :

CONDITIONAL {
($n1_raster1!=0) $n1_raster1 ,
($n2_raster2!=0) $n2_raster2

 

The result after running from Model Maker is what I expected :

rasters_union_model_maker.PNG

 

If I run this gmd model from Spatial Modeler 2016, I get exactly the same result.

 

 

The problem appears if I try to run this model from Spatial Modeler 2018 :

rasters_union_spatial_model_2018.PNG

I tried as well to save as gmdx, to add a 'Define Processing Area', but the result is unchanged.

 

 

Am I missing something or has this bug appeared in 2018 version of ERDAS ?

 

Cheers,

Nicolas

 

PS : I attached the model + samples

Occasional Contributor
Posts: 8
Registered: ‎05-10-2018

Re: Spatial Modeler backward compatibility for .gmd model (Processing Properties)

[ Edited ]

Hi Nicolas,

 

When you say you tried it as a gmdx in 2018 do you mean you added the define processing area model? If not the below may help:

 

Drag the Define Processing Are operator into your model (I assume before your conditional operator) then link up your two rasters, double click to open up the operator > change window rule to Union. 

 

Emily 

Technical Evangelist
Posts: 759
Registered: ‎10-01-2015

Re: Spatial Modeler backward compatibility for .gmd model (Processing Properties)

This is almost certainly the difference in nodata handling between old model maker (which didn’t) and Spatial Modeler (which does). It’ll help to review this

 

https://community.hexagongeospatial.com/t5/Spatial-Modeler-Tutorials/Mosaic-a-set-of-Tiled-Imagery-h...

 

And this

 

https://community.hexagongeospatial.com/t5/Spatial-Modeler-Tutorials/Handling-NoData-in-Spatial-Mode...

 

Cheers

 

 

Ian Anderson
Chief Product Owner, Desktop Remote Sensing
Hexagon Geospatial
Occasional Contributor
Posts: 6
Registered: ‎01-23-2019

Re: Spatial Modeler backward compatibility for .gmd model (Processing Properties)

Yes it is NoData handling, you are right ! I was wondering where all my bugs were coming from... I am going to upgrade all my models by adding some 'Replace Nodata with 0' operator then.

Strangely, I had no problem with Spatial Modeler 2016, only with the 2018.

 

Anyway, thanks you for the highlight.

Nicolas

Do you need immediate support?
If you encounter a critical issue and need immediate assistance please submit a Service Request through our Support Portal.