[gdal-dev] Confused about datum transformations
Simon Lyngby Kokkendorff
silyko at gmail.com
Wed Oct 19 07:31:38 EDT 2011
Hi Marc,
I suppose that when you say: WGS84 datum, you mean geographical coordinates
based on the WGS84-datum (i.e. lat,lon)?
Which other datums are involved?
Cheers,
Simon
On Wed, Oct 19, 2011 at 12:53 PM, <dev4cx4m9z at snkmail.com> wrote:
> Well, it’s ‘working’ (sort of) but I’m still confused. I’ll try to explain
> better what I’m trying to do.****
>
> ** **
>
> I have a database of map coordinates stored in WGS84 datum.****
>
> I load and display a map in my application which may, or may not, use the
> WGS84 datum. I am setting up a coordinatetransformation to convert WGS84
> data to whatever datum the map is. I then use another transformation to
> translate to screen coordinates.****
>
> ** **
>
> I’m only worrying about the datum conversion issue first. I will worry
> about the map projection issue later.****
>
> ** **
>
> I have successfully created a number of CT’s with no error. When invoked,
> they’re giving the wrong answer, but I’m still looking into that.****
>
> ** **
>
> I still don’t understand proj.dll. I downloaded the prebuilt proj.dll, and
> it seems to only have a few datums. It certainly does not have the ones I’m
> using. Does it matter, or must proj.dll contain all the datums I intend to
> use? Is the data pointed to by GDAL_DATA sufficient to translate from any
> known datum to another?****
>
> ** **
>
> *From:* Simon Lyngby Kokkendorff silyko-at-gmail.com |GDAL| [mailto:
> r0dk224axt at sneakemail.com]
> *Sent:* Wednesday, October 19, 2011 8:55 PM
>
> *To:* marc.hillman at tpg.com.au; dev4cx4m9z at snkmail.com
> *Cc:* gdal-dev at lists.osgeo.org
> *Subject:* Re: [gdal-dev] Confused about datum transformations****
>
> ** **
>
> 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, <dev4cx4m9z at snkmail.com> 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:
> 6wyv643jct at sneakemail.com]
> Sent: Wednesday, October 19, 2011 7:54 PM
> To: marc.hillman at tpg.com.au; dev4cx4m9z at snkmail.com
> 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****
>
>
> dev4cx4m9z at snkmail.com 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:5rm5yuc82t at sneakemail.com]
> > Sent: Wednesday, October 19, 2011 6:36 PM
> > To: marc.hillman at tpg.com.au; dev4cx4m9z at snkmail.com
> > Cc: gdal-dev at lists.osgeo.org
> > 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, <dev4cx4m9z at snkmail.com> 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: gdal-dev-bounces at lists.osgeo.org
> > [mailto:gdal-dev-bounces at lists.osgeo.org****
>
> > <mailto:gdal-dev-bounces at lists.osgeo..org> ] On Behalf Of****
>
> > dev4cx4m9z at snkmail.com <dev4cx4m9z at snkmail..com>
> > Sent: Tuesday, October 18, 2011 4:12 AM
> > To: gdal-dev at lists.osgeo.org
> > 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 <dev4cx4m9z at snkmail.com>
> 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
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >
> >
> >
> >
> >****
>
> > ----------------------------------------------------------------------
> > --****
>
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev****
>
>
>
> ****
>
> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20111019/655a234c/attachment-0001.html
More information about the gdal-dev
mailing list