[OSRS-PROJ] Weirdnesses in the source code

[Judd Taylor]

Perl, eh?

I've got a pretty stable version that uses PDL::PP I've been meaning to
release out to CPAN. It works reall well and is real fast... I just need to
add a function to query the actual values that Proj is using (after
defaults, files, etc have been applied to the command line options) so I can
put in out output product metadata, but the guts are all there.

got PDL?

Running it through PDL::PP is many many many many times faster than using
any perl-level interfaces (PDL::PP generates PerlXS interfaces to the c
libraries), so if you don't have PDL, you probably should.

Here's a perl usage example (from my test script):

use strict;
use PDL;
use PDL::Transforms::Cartography::Proj4;

print "Testing forward transformation...\n";
my $proj = "+proj=merc +ellps=WGS72 +lon_0=80.25w +lat_0=30n";
print "Perl level params: \'$proj\'\n";

my $lon = double [-90.0, -95.0, -86.0];
my $lat = double [  0.0,  33.0,  77.0];

my ($x, $y) = fwd_transform($lon, $lat, $proj);
print "Inputs:\n\t\$lon = $lon\n\t\$lat = $lat\n";
print "Result:\n\t\$x = $x\n\t\$y = $y\n";

Let me know if you're interested and I'll tar it up and get it off to you--
hopefully it will save you some time.

______________________________
Judd Taylor
Systems Engineer
Institute for Marine Remote Sensing
University of South Florida
140 7th Ave. South
St Petersburg, FL 33701
(727) 553-1186
(727) 553-1103 (fax)
judd at marine.usf.edu


----- Original Message -----
From: <proj at ton.iguana.be>
To: <osrs-proj at remotesensing.org>
Sent: Tuesday, July 08, 2003 11:23 AM
Subject: [OSRS-PROJ] Weirdnesses in the source code


> Hi,
>
> I'm busy transforming some of the proj code to perl, and ran into a
> number of strange things.
>
> PJ_aeqd.c
>   in PROJ_HEAD, lat_0 should be lat_0=
>
> PJ_aitoff.c
>   in PROJ_HEAD, lat_1 should be lat_1=
>
> In PJ_imw_p.c, the function loc_for
>   has a parameter double *yc that never gets actually set
>   (the else branch in the code has it's own local yc)
>   It is however used in e_inverse, so that basically picks up random
>   garbage from memory (whatever the local yc there gets as value)
>
> PJ_lcca.c use errors 50 and 51, which don't exist. They are positive,
> so maybe they are meant to pick up plain errno values, but in that case
> i don't know which ones you mean and it's not portable
>
> PJ_ocea.c, PROJ_HEAD basically declares Sphlonc (forgotten newline)
>
> PJ_cea.c
>
> if (pj_param(P->params, "tlat_ts").i &&
> (P->k0 = cos(t = pj_param(P->params, "rlat_ts").f)) < 0.) E_ERROR(-24)
> else
> t = 0.;
>
>   P->k0 doesn't get set if pj_param(P->params, "tlat_ts").i isn't done.
>   It's however used.
>   For t=0 the corresponding k0 is 1, which is the default (except when
>   it gets explicitely set), so maybe it's what you want. But it at least
>   deserves a comment in that case I'd say
>
>   PS, k0 seems nowhere explained in the docs. Shouldn't it be ?
>
> PJ_stere.c:
>
> P->phits = pj_param(P->params, "tlat_ts").i ?
> P->phits = pj_param(P->params, "rlat_ts").f : HALFPI;
>
>   Not exactly a bug, but the double assign to P->hits is weird. Probably
>   meant to be:
> P->phits = pj_param(P->params, "tlat_ts").i ?
> pj_param(P->params, "rlat_ts").f : HALFPI;
>
> PJ_vandg2.c:
>   projection vandg2 itself only supports spherical, but forgets to set
>   P->es to 0 (Yeah, i know it's not used in s_forward itself)
>
> PJ_mpoly.c:
>   always returns (0,0), so it doesn't do anything.
>   It's still linked into the final proj though.
>
> pj_enfn and pj_authset are handled inconsistently. Sometimes the
> returncode gets checked, other times it's just assumed it will work.
> ----------------------------------------
> PROJ.4 Discussion List
> See http://www.remotesensing.org/proj for subscription, unsubscription
> and other information.
>

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.