octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #10022] [octave forge] (mapping) Auxillary


From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #10022] [octave forge] (mapping) Auxillary Latitudes
Date: Sun, 2 Jan 2022 16:10:19 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #15, patch #10022 (project octave):

Sorry for long delay.

In the meantime I checked with Matlab and AFAICS con2geo.m/geo2con.m,
auth2geo.m/geo2auth.m and rect2geo.m/geo2rect.m seem to work fine. They've
already been pushed, as was geo2iso.m
However, iso2geo seems to yield incorrect answers.

According to Matlab docs and tried here in r2020b:


>> phi = [-90 : 10 : 90];
conv = map.geodesy.IsometricLatitudeConverter(wgs84Ellipsoid);
psi = forward(conv,phi)   % geodetic to isometric
psi =
  Columns 1 through 9
      -Inf   -2.4296   -1.7291   -1.3112   -1.0055   -0.7586   -0.5460  
-0.3541   -0.1743
  Columns 10 through 18
         0    0.1743    0.3541    0.5460    0.7586    1.0055    1.3112   
1.7291    2.4296
  Column 19
       Inf
>> psi = rad2deg (forward(conv,phi))
psi =
  Columns 1 through 9
      -Inf -139.2081  -99.0708  -75.1234  -57.6137  -43.4647  -31.2810 
-20.2878   -9.9846
  Columns 10 through 18
         0    9.9846   20.2878   31.2810   43.4647   57.6137   75.1234  
99.0708  139.2081
  Column 19
       Inf


and conversely (using inverse rather than forward).

Your geo2iso does it fairly well, apart from the Inf extremes:

>> format bank     % to avoid scientific notation
>> pssi = geo2iso ([-90 : 10 : 90])
pssi =
 Columns 1 through 8:
  -2178.29   -139.21    -99.07    -75.12    -57.61    -43.46    -31.28   
-20.29
 Columns 9 through 16:
     -9.98         0      9.98     20.29     31.28     43.46     57.61    
75.12
 Columns 17 through 19:
     99.07    139.21   2178.29


Before invoking iso2geo the latitude interval checks have to be dropped, and
then:

>> iso2geo (geo2iso (0:10:90))
ans =
       0   10.00   20.01   30.03   40.08   50.15   60.24   70.35   80.47  
90.61


... so iso2geo and geo2iso don't seem to be exactly each other's inverse.
AFAICS it's esp. iso2geo.m which doesn't seem to be sufficiently accurate.
It was already months ago that I first noted this but I simply hadn't time to
delve deeper into it, sorry.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?10022>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]