[gdal-dev] ITRF issues

Akmanalp, Mehmet A makmanalp at wpi.edu
Sun Mar 27 18:45:41 EDT 2011


Hello,

I have a Trimble Ag252 GPS [0] and an OmniStar HP subscription for
corrections [1] for our robotics project [2]. According to that link [1],
OmniStar uses ITRF2005, which I'm having trouble getting to work on
python-gdal in Ubuntu 10.10.

I'm converting the lat / long pair we get from the GPS device into UTM
easting / northing so we can localize our robot and compare our current
position from the starting position by simply using addition / subtraction /
the pythagorean theorem. I'm using code similar to the following to convert
(slightly simplified):

-------------- snip -------------------
ellipsoid = "WGS84" # or could be EPSG:4919 etc

utm = osgeo.osr.SpatialReference()
utm.SetWellKnownGeogCS(ellipsoid)
ll = osgeo.osr.SpatialReference()
ll.SetWellKnownGeogCS(ellipsoid)

zone = int(math.floor((lon + 180.0) / 6.0) + 1.0)
utm.SetProjCS("UTM %d / %s" % (zone, ellipsoid))
utm.SetUTM(zone)
trans = osgeo.osr.CoordinateTransformation(ll, utm)

trans.TransformPoint(lat, lon, 0.0)

-------------- snip -------------------

When I grep inside /usr/share/gdal16/, I can find some references to ITRF
but no definition.

When I look up ITRF on spatialreference.org, I find EPSG numbers 4385 [3]
and 4919[4] for ITRF2000 but I get this error: "ERROR 6: EPSG PCS/GCS code
4919 not found in EPSG support files.  Is this a valid EPSG coordinate
system?" Same with 4896 for ITRF2005.

When I grep inside /usr/share/gdal16/ for ITRS, I find "6896,International
Terrestrial Reference Frame 2005,geodetic," in gdal_datum.csv. This seems to
be what I'm looking for, but I have no clue how to use it. How would I go
about doing this?

I've also read that "new realizations of WGS84" are at about 10cm from ITRF
[5], but is the WGS84 that GDAL uses one of the ones referred to in that
document? Also, it doesn't specify which ITRF looks like ITRF90, which is
old. Even though I could fall back to using WGS84, I'd prefer not to since
it seems that it'd defeat the purpose of using a +-10cm corrections service,
and I don't know if our application could tolerate much more than +-50cm.

We are, however, generating a *local* map that's based on the origin
position we start the robot at, so coordinates that were *uniformly* shifted
over would not be a problem. Is that the case with regards to ITRF2005 vs
WGS84?

Thanks,
-- 
~ mali (http://constant.inople.net/)

[0]
http://trl.trimble.com/dscgi/ds.py/Get/File-159152/AgGPS252_100A_UserGuide_55510-00-ENG.pdf
[1] http://www.omnistar.com/faq.html#accuracy
[2] http://www.igvc-wpi.org/
[3] http://spatialreference.org/ref/epsg/4385/
[4] http://spatialreference.org/ref/epsg/4919/
[5] ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110327/05e77e26/attachment.html


More information about the gdal-dev mailing list