You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sis.apache.org by "Martin Desruisseaux (JIRA)" <ji...@apache.org> on 2019/05/11 07:49:00 UTC
[jira] [Resolved] (SIS-446) NetCDF store should be robust to
non-linear localization grid
[ https://issues.apache.org/jira/browse/SIS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Desruisseaux resolved SIS-446.
-------------------------------------
Resolution: Fixed
Fixed with the use of Jacobian matrix in {{InterpolatedTransform.Inverse}} class. This fix can be improved with implementation of _satellite-tracking projection_ in order to store the localization grid in a more linear form, but implementation of that projection is tracked in a separated issue (SIS-452).
> NetCDF store should be robust to non-linear localization grid
> -------------------------------------------------------------
>
> Key: SIS-446
> URL: https://issues.apache.org/jira/browse/SIS-446
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing, Storage
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Major
> Fix For: 1.0
>
>
> Localization grid in netCDF files contain (longitude, latitude) values of all pixels. {{LocalizationGridBuilder}} first computes a linear (affine) approximation of a localization grid, then stores only the residual in its internal grid. The intent is to have small residual, which make easier to compute the _inverse_ transformation (given a latitude and longitude, find indices of the pixel at that location). However if the localization grid is non-linear, then the affine transform is a poor approximation of that grid and the residuals are high. High residual make _inverse_ transforms hard to compute, which result sometime in {{TransformException}} being throw with a "no convergence" error message.
> In practice, the localization grid in netCDF files is often used for storing the results of a map projection. The Mercator projection for example is often used. The proposed fix is to allow {{LocalizationGridBuilder}} to try to transform the grid using a given list of map projections and see if one of those projections results in a grid closer to a linear transform. In other words, we should be able to "guess" what the projection may be. It is okay if the guess is not a perfect match; if the residuals become smalls, it will resolve the "no convergence" errors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)