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.
warme...@gdal64[264]% setenv PROJ_DEBUG
warme...@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,
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev