Hi Marc,
Just to understand your problem fully: You have data in your database in
WGS84, in geographical coordinates, or what? That would correspond to a
srs=osr.SpatialReference(), srs.SetWellKnownGeogCS("WGS84").
What kind of projection or geographical coordinate system do you want to
project to? It seems to be: EPSG:3557 which is: NAD83(NSRS2007) / Maine
East. Is this correct? If you have the GDAL_DATA env-variable pointing to
the right directory (containing EPSG definitions etc), gdal should be able
to also do:
srs2=osr.SpatialReference(), srs2.ImportFromEPSG(3557), which becomes:
>>> srs2.ExportToPrettyWkt()
'PROJCS["NAD83(NSRS2007) / Maine East",\n
GEOGCS["NAD83(NSRS2007)",\n
DATUM["NAD83_National_Spatial_Reference_System_2007",\n
SPHEROID["GRS 1980",6378137,298.257222101,\n
AUTHORITY["EPSG","7019"]],\n
TOWGS84[0,0,0,0,0,0,0],\n
AUTHORITY["EPSG","6759"]],\n PRIMEM["Greenwich",0,\n
AUTHORITY["EPSG","8901"]],\n
UNIT["degree",0.01745329251994328,\n
AUTHORITY["EPSG","9122"]],\n AUTHORITY["EPSG","4759"]],\n
UNIT["metre",1,\n AUTHORITY["EPSG","9001"]],\n
PROJECTION["Transverse_Mercator"],\n
PARAMETER["latitude_of_origin",43.66666666666666],\n
PARAMETER["central_meridian",-68.5],\n
PARAMETER["scale_factor",0.9999],\n
PARAMETER["false_easting",300000],\n PARAMETER["false_northing",0],\n
AUTHORITY["EPSG","3557"],\n AXIS["X",EAST],\n AXIS["Y",NORTH]]'
'
If you want to perform the actual coordinate transformation, besides just
having descriptions of the systems, you'll definitely need to have proj4.dll
somewhere in your system, where gdal can find it (I guess besides gdal.dll
or somewhere in your PATH).
Cheers,
Simon
On Wed, Oct 19, 2011 at 11:21 AM, <[email protected]> wrote:
> I have a big clue - I have inspected the output of ExportToWKT, and the
> results are interesting
>
> With WGS84SRS
> GDALError = .SetProjCS("WGS84 Datum")
> Debug.Assert(GDALError = OGRError.OGRERR_NONE,
> GetLastErrorMsg())
> GDALError = .SetWellKnownGeogCS("WGS84") ' Define WGS84
> coordinate system
> Debug.Assert(GDALError = OGRError.OGRERR_NONE,
> GetLastErrorMsg())
> End With
>
> Produces PROJCS["WGS84 Datum",GEOGCS["WGS
> 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]]
> With UTMSRS
> GDALError = .SetProjCS("UTM coordinate system")
> Debug.Assert(GDALError = OGRError.OGRERR_NONE,
> GetLastErrorMsg())
> GDALError = .SetWellKnownGeogCS("WGS84") ' Define a
> UTM coordinate system
> Debug.Assert(GDALError = OGRError.OGRERR_NONE,
> GetLastErrorMsg())
> End With
>
> Produces PROJCS["UTM coordinate system",GEOGCS["WGS
> 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]]
>
> With MapSRS
> GDALError = .SetProjCS("Map coordinate system")
> Debug.Assert(GDALError = OGRError.OGRERR_NONE,
> GetLastErrorMsg())
> GDALError = .ImportFromEPSG(i)
> Debug.Assert(GDALError = OGRError.OGRERR_NONE,
> GetLastErrorMsg())
> End With
>
> Produces
> GEOGCS["GDA94",DATUM["Geocentric_Datum_of_Australia_1994",SPHEROID["GRS
> 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6283"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4283"]]
>
> The error when I attempt to create the transformation is always with the
> SRS that seems to be a projection definition, not a datum. ImportFromEPSG
> seems to be correctly producing a GEOGCS, but SetWellKnownGeogCS seems to be
> producing a "PROJCS"
>
> I feel I'm very close to the answer, but I still can't see it.
>
> -----Original Message-----
> From: Peter J Halls P.Halls-at-york.ac.uk |GDAL| [mailto:
> [email protected]]
> Sent: Wednesday, October 19, 2011 7:54 PM
> To: [email protected]; [email protected]
> Subject: Re: [gdal-dev] Confused about datum transformations
>
> A comment from another GDAL user, rather than the development team.
>
> GDAL and OGR are actually C++ tools that have C, Java, Python and other
> language bindings. What you have picked up is an artefact of the fact that
> GDAL is not just C.
>
> The proj4 library for your platform is automatically loaded with GDAL and
> OGR:
> it must be present but no explicit action is required by the user.
>
> Chaitanya's advice was to double check that the transformation parameters
> are being passed correctly. Datum transformations *are* fiddly (full stop)
> to specify and this advice is sound. You appear to be specifying two parts
> of the transformation, presumably being content with the default values for
> the other parameters. Ideally, you need to get the system to regurgitate
> its understanding of your parameters in the WKT version of the final
> transformation specification - ie the complete string. This is what you are
> being advised to do.
>
> Problems like this are not confined to GDAL / OGR: I've lost count of the
> number of times I've handled projection problems here. What sounds to be a
> simple operation is not trivial and unpicking problems most often requires
> an understanding of the transformation method and all the parameters
> applied.
>
> Hoping that helps,
>
> Peter
>
> [email protected] wrote:
> > I have not used org2ogr. I have just realised that the C API for GDAL
> > uses a mixture of STD and CDECL. How annoying. Anyway – I have
> > carefully checked and all are correct. I get a stack balance problem
> > if they are not anyway. It’s hard to see how I could get the arguments
> wrong – one is the string “WGS84”, and the other is an integer.
> >
> >
> >
> > I still don’t know whether proj.dll is required.
> >
> >
> >
> > From: Chaitanya kumar CH chaitanya.ch-at-gmail.com |GDAL|
> > [mailto:[email protected]]
> > Sent: Wednesday, October 19, 2011 6:36 PM
> > To: [email protected]; [email protected]
> > Cc: [email protected]
> > Subject: Re: [gdal-dev] Confused about datum transformations
> >
> >
> >
> > Marc,
> >
> > You don't need to rebuild proj.4; you are already using it.. Since you
> were able to use ogr2ogr to do the transformation, it works.
> >
> > What you need to do is find out if the arguments you are passing to the
> transformation builder are good. Especially 'MapSRS'. If it doesn't show any
> problem, plug some debug messages in the OSR code in ogrct.cpp and rebuild
> gdal.
> >
> > On Wed, Oct 19, 2011 at 12:46 PM, <[email protected]> wrote:
> >
> > Thanks for all the suggestions – they have given me many possibilities to
> eliminate, but I still haven’t really got an answer to the original
> question.
> >
> >
> >
> > Am I required to have proj.dll built with support for the
> datums/projections I want to use, or is it sufficient to set GDAL_DATA such
> that gcs.csv and pcs.csv are visible? I’m working in VB.NET, and I’m not
> confident I can rebuild PROJ with the required datums, so I wish to avoid if
> possible. I’d even be prepared to use SetGeogCS explicitly as I only use a
> few datums. If I use SetGeogCS, I can’t see what purpose proj.dll serves.
> >
> >
> >
> > I have set GDAL_DATA to the correct folder.
> >
> > I have checked that the datum numbers I use are in the gcs.csv file.
> >
> >
> >
> > From: [email protected]
> > [mailto:[email protected]
> > <mailto:[email protected]> ] On Behalf Of
> > [email protected]
> > Sent: Tuesday, October 18, 2011 4:12 AM
> > To: [email protected]
> > Subject: RE: [gdal-dev] Confused about datum transformations
> >
> >
> >
> > I’m not sure the code will help too much, but here are the relevant
> > code fragments. I’m using a hand crafted VB.net wrapper which explains
> > some of the syntax
> >
> >
> >
> > Private WGS84SRS As New OGRSpatialReference ' Coordinate system in
> WGS84
> >
> > Private MapSRS As OGRSpatialReference ' Coordinate system of map
> >
> > Private ctWGS84toMap As OGRCoordinateTransformation ' Coordinate
> transform from WGS84 to map
> >
> >
> >
> > With WGS84SRS
> >
> > GDALError = .SetProjCS("WGS84 Datum")
> >
> > Debug.Assert(GDALError = OGRError.OGRERR_NONE, GetLastErrorMsg())
> >
> > GDALError = .SetWellKnownGeogCS("WGS84") ' Define WGS84
> coordinate system
> >
> > Debug.Assert(GDALError = OGRError.OGRERR_NONE, GetLastErrorMsg())
> >
> > End With
> >
> >
> >
> > With MapSRS
> >
> > GDALError = .SetProjCS("Map coordinate system")
> >
> > Debug.Assert(GDALError = OGRError.OGRERR_NONE, GetLastErrorMsg())
> >
> > GDALError = .ImportFromEPSG(3577)
> >
> > Debug.Assert(GDALError = OGRError.OGRERR_NONE, GetLastErrorMsg())
> >
> > End With
> >
> >
> >
> > ctWGS84toMap = GDAL.CreateCoordinateTransformation(WGS84SRS, MapSRS)
> ' Create a coordinate transformation - WGS84 to map
> >
> > Debug.Assert(ctWGS84toMap IsNot Nothing, GetLastErrorMsg())
> >
> >
> >
> > Marc,
> >
> > Can you provide the code leading to the error?
> >
> > On Tue, Oct 18, 2011 at 1:21 PM, Marc Hillman <[email protected]>
> wrote:
> >
> > I have a GIS database, and all data is stored in WGS84 datum. I have
> developed an application using GDAL, and I now need to translate my WGS84
> coordinates to several different datums, depending what map is loaded. I
> seem to be going around in circles, and need a nudge in the right direction.
> I am defining an OGRSpatialReference for each datum (WGS84 and current map)
> and then attempting to create an OGRCoordinateTransformation for the
> transformation.. This last step fails with a PROJ.4 error (“No PROJ.4
> translation for destination SRS, coordinate transformation initialization
> failed”
> >
> >
> >
> > My question is - Do I need PROJ.4 to do the translation? Can I not just
> use ImportFromWKT to define my OGRSpatialReference? If so, is there a nice
> canned list of all the WKT somewhere? I’m keen to avoid PROJ.4 if possible
> as I’m not sure I can build it.
> >
> >
> >
> >
> > _______________________________________________
> > gdal-dev mailing list
> > [email protected]
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > gdal-dev mailing list
> > [email protected]
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
>
> --------------------------------------------------------------------------------
> Peter J Halls, GIS Advisor & Team Leader Applications Support and Training,
> Information Directorate, University of York
> Telephone: 01904 323806 Fax: 01904 323740
> Snail mail: Harry Fairhurst Building, University of York,
> Heslington, York YO10 5DD
> This message has the status of a private and personal communication
>
> --------------------------------------------------------------------------------
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1831 / Virus Database: 2092/4560 - Release Date: 10/18/11
>
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
