[gdal-dev] Re: C# Nad27 to WGS 84

Tomas R monshi at home.se
Thu Jul 16 16:38:11 EDT 2009


no one?

To bad, well, I will see what I can do on my own.

/Tomas

Tomas R skrev:
> I have no luck
>
> Downloaded compiled package form http://vbkto.dyndns.org:1280/sdk/ 
> (MSVC2008 (Win32) -stable, v 1500).
>
> I set the path as described before, that is:
>
> nadPath = 
> Path.Combine(Path.GetDirectoryName(this.GetType().Assembly.Location), 
> @"Gdalbin\Nad");
> Environment.SetEnvironmentVariable("PROJ_LIB", nadPath);
>
> If I check the environment variable it is set. But proj.dll perhaps do 
> not share the environment variables with the C#-project? Must it 
> perhaps be set globally?
>
> I also try setting a GDAL setting with same arguments:
>
> OSGeo.GDAL.Gdal.SetConfigOption("PROJ_LIB", nadPath);
>
> and also that one checks out OK afterwards, that is, the setting 
> exists in Gdal.
>
> The result of the code is the same with my first version, with an 
> unknown version of proj.dll. That is just de given values back. (no 
> matter what target projection I use). No exception thrown as with the 
> latest version of Proj4 from their website.
>
> And the, the same as before:
>            SpatialReference spatNad27 = new SpatialReference("");
>            spatNad27.SetWellKnownGeogCS("Nad27");
>            SpatialReference spatNad83 = new SpatialReference("");
>            spatNad83.SetWellKnownGeogCS("WGS84");
>            CoordinateTransformation trans = new 
> CoordinateTransformation(spatNad27, spatNad83);
>            double[] p = new double[3];
>            trans.TransformPoint(p, -117, 30, 0);
>            this.textBox1.Text = p[0] + ", " + p[1] + ", " + p[2];
>
>
> and the result in the textbox is
> -117
> 30.0000000008175
> 2.61394307017326E-05
> which is the same result  as I get if I remove the path setting or 
> remove all of Projs data files. Something is amiss.
>
> Gdal-test env. Unsure how to set up. Should not the code above be enough?
> A friend did a test in Python and he could do the transform, but that 
> is no big help for me.
>
> Any ideas what I miss or what I should test?
>
> /Tomas
> Frank Warmerdam skrev:
>> Tomas R wrote:
>>> Hi again,
>>>
>>> New problems arises as the world of Gdal is quite complex to grasp.
>>>
>>> Have understood that the transformation of coordinates from Nad 27 
>>> datum to WGS 84 requires some look up tables to be done correctly, 
>>> tables that differ with the are the Nad 27 is valid in.
>>>
>>> Simple question is, how to set up a general solution in C# that uses 
>>> these shift tables.
>>> I have in code a simple test:
>>>           SpatialReference spatNad27 = new SpatialReference("");
>>>            spatNad27.SetWellKnownGeogCS("Nad27");
>>>            SpatialReference spatNad83 = new SpatialReference("");
>>>            spatNad83.SetWellKnownGeogCS("Nad83");
>>>                      CoordinateTransformation trans = new 
>>> CoordinateTransformation(spatNad27, spatNad83);
>>>            double[] p = new double[3];
>>>            trans.TransformPoint(p, -117, 30, 0);
>>>
>>> that gives back
>>> -117, 30,0000000008175
>>> which I believe is not correct ( see 
>>> http://proj.maptools.org/faq.html )
>>>
>>> I have Proj4.dll, I have set an environment path to PROJ_LIB where 
>>> the nad shift tables should exist. Must I do something else in the 
>>> setup or is the call to the transform different? or have I done 
>>> correctly but misinterpreted the results?
>>>
>>> What I in reality is interested is transforming whatever coordinate 
>>> in whatever projection/datum to and from WGS84 without any extra 
>>> hassle fast and easy via the C# interface. That should not be to 
>>> hard? Or?
>>
>> Tomas,
>>
>> If I test with the testepsg program (using GDAL services) with
>> CPL_DEBUG and PROJ_DEBUG defined ON I get the following output.
>>
>> warmerda at gdal64[264]% setenv PROJ_DEBUG
>> warmerda at gdal64[265]% testepsg -t NAD27 NAD83 -117 30
>> OGRCT: Source: +proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs
>> OGRCT: Target: +proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs
>> pj_open_lib(conus): call 
>> fopen(/wrk/home/warmerda/bld/share/proj/conus) - succeeded
>> Ctable Conterminous United States 273x121: LL=(-131,20) UR=(-63,50)
>> pj_open_lib(alaska): call 
>> fopen(/wrk/home/warmerda/bld/share/proj/alaska) - succeeded
>> Ctable Alaska 529x249: LL=(-194,46) UR=(-128,77)
>> pj_open_lib(ntv2_0.gsb): call 
>> fopen(/wrk/home/warmerda/bld/share/proj/ntv2_0.gsb) - failed
>> pj_open_lib(ntv1_can.dat): call 
>> fopen(/wrk/home/warmerda/bld/share/proj/ntv1_can.dat) - succeeded
>> NTv1 393x177: LL=(-142,40) UR=(-44,84)
>> pj_open_lib(conus): call 
>> fopen(/wrk/home/warmerda/bld/share/proj/conus) - succeeded
>> pj_apply_gridshift(): used Conterminous United States
>> (-117.000000,30.000000,0.000000) -> (-117.000806,30.000113,0.000026)
>>
>> I don't know if it is practical for you to enable debugging and see
>> stderr output, but if you can it might help you deduce what is
>> or is not working.
>>
>> It *sounds* like you have done what is necessary, but it is hard
>> for me to know if you have made some mistake, such as preprocessing
>> the grid shift file into binary form.
>>
>> Best regards,



More information about the gdal-dev mailing list