WGS84 reprojection issues

Jan 29, 2009 at 1:10 PM
Edited Feb 2, 2009 at 1:27 PM
Hi list,
I'm developing a Shapefile To KML conversion program with SharMap 2.0 and Proj.Net 1.1.
I'm using the latest SVN revision (http://sharpmapv2.googlecode.com/svn/trunk/)
Basically, I need to reproject all my shapes to WGS84.
However, I'm having some alignment issues when I try to open my KML files with Google Earth or Google Maps.

For example, take a look at this Google Maps screenshot:

Here's the code I'm using for reading reprojected shapefiles:

GeometryServices gs = new GeometryServices();
ShapeFileProvider sf = new ShapeFileProvider(path, gs.DefaultGeometryFactory, gs.CoordinateSystemFactory);
ICoordinateSystem srs = gs.CoordinateSystemFactory.CreateFromWkt(wktSrs);
ICoordinateSystem dst = gs.CoordinateSystemFactory.CreateFromWkt(wktDst);  // WGS84 WKT
ICoordinateTransformation ics = gs.CoordinateTransformationFactory.CreateFromCoordinateSystems(srs, dst);
sf.CoordinateTransformation = ics;

How can I fix the realignment?

Best regards,

Feb 24, 2009 at 5:25 AM
Judging from the size of the error, you are missing the correct datum transform parameters. Proj.NET doesn't automatically provide the datum transform parameter. Basically if you transform data in one datum to something in a different datum, specifying the TOWGS84 parameter is required.
May 20, 2009 at 3:03 PM
Edited May 20, 2009 at 4:03 PM

I'm having the same problem converting shapefiles from SRID 2276 to 4326 (WGS84/ Virtual Earth). My shapes are aligned 40 to 50 feet too far to the north. I'm using the same versions of SharpMap and Proj.net mentioned above. Here's an example screen shot of my VirtualEarth map:   http://sharpmap.codeplex.com/Thread/View.aspx?ThreadId=55756&ANCHOR#Post192295

I've been converting the CoordinateSystems using both the srs SRID's and the WKT files, but the alignment is off with either approach. I've read in some places that VE uses SRID 900913, but more often I've read that it uses 4326. I've tried both with the same results. In fact, yesterday I read from a chapter of Alisair Atchison's book that VE uses EPSG::3785 to display data:

"...Virtual Earth actually uses two spatial reference systems:
- When
displaying projected data, Virtual Earth uses a Mercator projection based on the WGS 84 datum, but applied to a sphere. This is the EPSG::3785 just described. 

- When accessing  data programmatically through the API methods, however, Virtual Earth uses (unprojected) geographic longitude/latitude coordinates based on the standard WGS 84 system - that is, EPSG::4326."


I'm not sure what he means by accessing versus displaying the data. I loaded my shape files into SQL Server 2008, reprojected in 4326. Should I transform my geometry to 3785 before passing the shapes back to Virtual Earth?

Any idea how to fix my problem? Could you please provide an example of how and where to pass the TOWGS84 parameter if you think it applies to my situation as well?

Much thanks,


May 22, 2009 at 5:51 AM

For more information on the spatial reference used in VE see these posts (considering Alisairs choice of words it looks like he pretty much copied the text from the following posts):


The 900913 is a code someone came up with. The number spells "Google" where 9=9, 3=e etc. Not really fair considering it was Microsoft who came up with this projection and google who copied it :-).

Whether you need to transform to 3785 or not depends on how you are planning on using your data. If you are rendering image tiles, then yes you need to reproject it, but if you are adding data using the javascript API, then you need to provide the data in 4326.

For the TOWGS84 parameter, you would have to ask USGS, Texas or whoever is responsible for that spatial reference for the correct values for your area. It varies from place to place, or get a professional tool that supports Datum transforms and convert the data first using that.

May 22, 2009 at 4:27 PM
Edited May 22, 2009 at 4:28 PM

My shapefiles are all vector data, no image tiles at all.

Today I found a solution! It may not be the best solution but it worked. I converted my shapefile using the WKT provided (parcels2008.prj ) to SRID 4326 (which I'd done about 50 times already), but this time I changed the False_Northing parameter in parcels2008.prj and it worked! I added 54, changing it from 6561666 to 6561720 and it moved all my shapes south by about 50 feet, putting them almost perfectly in line. Something tells me there is a better way of accomplishing this, but at this point I'm tired of messing around with it.

Thanks for your reply,