[Proj] Differences in reprojection between using the cs2cs app and using the api

[Adri CS]

Hello!!

Hermann code is fine. After a new review, I've found the cause of the
disparities between cs2cs and my code's output: I forgot to set the number
of decimals places in the output file.

Thank you all for your help! :)

On 16 February 2015 at 18:41, Adri CS <acsantome at gmail.com> wrote:

> Hi!
>
> Thanks for your time! Your code works fine! I'll check mine tomorrow
> morning and see where I messed up.
>
> Thanks a lot!
>
> On 15 February 2015 at 09:41, Hermann Peifer <peifer at gmx.eu> wrote:
>
>> Adri,
>>
>> Just to confirm that using the API doesn't make any difference, as
>> expected. See mycode.c below, based on https://trac.osgeo.org/proj/
>> wiki/ProjAPI
>>
>> Your own sample code below has these coordinates:
>> > /double lat = -45.491596;
>> > /double lon = -23.570147;
>>
>> This point falls into the South Atlantic Ocean, somewhere in the middle
>> between Tierra del Fuego and Cape Town. So you'd have to swap lat/lon in
>> order to get to the Rodovia dos Tamoios, (SP-099).
>>
>> Hope this helps, Hermann
>>
>> $ echo -45.491596 -23.570147 769.750000 | ./mycode
>> 449834.145105   7393276.784821  769.75
>>
>> $ cat mycode.c
>> #include <stdio.h>
>> #include <proj_api.h>
>>
>> int main(int argc, char **argv) {
>>
>>         projPJ wgs, sirgas;
>>         double lon, lat, alt;
>>
>>         if (!(wgs = pj_init_plus("+init=epsg:4326")) )
>>                 exit(1);
>>
>>         if (!(sirgas = pj_init_plus("+init=epsg:31983")) )
>>                 exit(1);
>>
>>         while (scanf("%lf %lf %lf", &lon, &lat, &alt) == 3) {
>>                 lon *= DEG_TO_RAD;
>>                 lat *= DEG_TO_RAD;
>>                 pj_transform(wgs, sirgas, 1, 1, &lon, &lat, &alt);
>>                 printf("%.6f\t%.6f\t%.2f\n", lon, lat, alt);
>>         }
>>         exit(0);
>> }
>>
>>
>> On 2015-02-11 18:07, Adri CS wrote:
>>
>>> Hi,
>>>
>>> I built Proj4 4.8.0 for Windows with MinGW. I'm trying to reproject some
>>> WGS84 lat/long coordinates (degrees) from Brazil to UTM Sirgas 2000. The
>>> UTM zone would be 23S.
>>>
>>> **) Using the cs2cs app:
>>>
>>> /cs2cs.exe -f %.6f +init=epsg:3273 +proj=latlong +to +init=epsg:31938
>>> input.txt > output.txt/
>>>
>>> **The input file would contain coords like this: -45.491596
>>> -23.570147 769.750000
>>>
>>> And the output would be: 449834.145105    7393276.784821 769.750000
>>>
>>> /***********************************************/
>>>
>>> **) Using the api (I omit the error checking):
>>>
>>> /projPJ wgs = pj_init_plus("+init=epsg:32723 +proj=latlong");
>>> /
>>> /projPJ sirgas = = pj_init_plus("+init=epsg:31983");
>>> /
>>> /double lat = -45.491596;
>>> /
>>> /double lon = -23.570147;
>>> double alt = 769.750000;
>>>
>>> /
>>> /lat *= DEG_TO_RAD;
>>> /
>>> /lon *= DEG_TO_RAD;
>>> /
>>> /
>>> /
>>> /pj_transform(wgs, sirgas, 1, 1, &lon, &lat, &alt);/
>>>
>>> This outputs: 449834.127632      7393276.821296       769.750000
>>>
>>> In both cases, the left part of the returned UTM easting and northing
>>> coordinates are the same, but the numbers after the decimal point are
>>> different.
>>>
>>> I'm only transforming the input lat/lon coordintates when using the api,
>>> since if I transform them before calling cs2cs, it will output wron
>>> coords (the easting will have 7 digits before the decimal points).
>>>
>>> What's happening here? The only difference I can see it's the
>>> transformation of the lat/lon coordinates from degrees to radians: I'm
>>> multypling directly while in the cs2cs source, there's a call to the
>>> /dmstor/ function (which I can't call directly, it seems).
>>>
>>> Thanks for your time & cheers!
>>> Adri.
>>>
>>>
>>> _______________________________________________
>>> Proj mailing list
>>> Proj at lists.maptools.org
>>> http://lists.maptools.org/mailman/listinfo/proj
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20150218/3e5f1f34/attachment.html>