ThinkGeo.com    |     Documentation    |     Premium Support

Projection Problem

#1

I am getting a misalignment problem when using MapSuite to reproject a shapefile from a client. I don't get the problem if I manually use Safe Software's FME Desktop to reproject the shapefile.


In the image below, Blue is MapSuite, Red is FME.


shapefiles_off.png576×576 60.1 KB


Here is my conversion code:



string dir = ConfigurationManager.AppSettings["MapsRoot"];
string originalFile = dir + "Original.shp";
string convertedFmeFile = dir + "FME_Converted.shp";
string convertedThinkgeoFile = dir + "TG_Converted.shp";

Proj4Projection proj4 = new Proj4Projection();
proj4.InternalProjectionParametersString = Proj4Projection.GetEpsgParametersString(4267);
proj4.ExternalProjectionParametersString = Proj4Projection.GetEpsgParametersString(4269);
ShapeFileFeatureLayer.SaveToProjection(originalFile, convertedThinkgeoFile, proj4, OverwriteMode.Overwrite);
ShapeFileFeatureLayer.BuildIndexFile(convertedThinkgeoFile, BuildIndexMode.DoNotRebuild);

Original and FME Converted shapefiles are attached



001_shapefiles.zip (319 KB)

#2

 


Hi Rob,
I have no experience with FME software, but we tried using the GlobalMapper and TatukGIS viewer,  both of them gave the same result – there is an offset compared with the “FME_Converted.shp”. Please have a look at the screenshot we got from the two viewers:

The Yellow one is the “FME_Converted.shp”. Can you have a check if there is anything that we missed?
Thanks,
Johnny

#3

I agree that there is an offset, that is the problem.  
  
 If I use FME to reproject the shapefile to DecimalDegrees, then use MapSuite to reproject it in memory to GoogleMaps, it aligns perfectly with streets. 
  
 If I use MapSuite to reproject the shapefile to DecimalDegree, then reproject it in memory to GoogleMaps, it does not align with the streets. 
  
 So I think there is a problem in how Proj4 is handling reprojecting from EPSG 4267 to EPSG 4269 (at least with this shapefile, since I am able to reproject it fine using other software).

#4

Hi Rob, 
  
 Have you ever tried the “TatukGIS Viewer”? Just from 4267 to 4269, it gets the same result to MapSuite. We also tried using ProjNet library to do the conversion, but get a bigger offset. Can you let us know what kinds of “other software” that you have tried? And then we can do some research about why this happened. Additionally, we are gonna try the origin Proj4 library to see if there is any difference. 
  
 Thanks, 
  
 Johnny  


#5

FME Desktop is the only other one I have tried. It reprojects the shapefile fine, and everything lines up, so I didn’t try anything else. 
  
 FME detects the source projection automatically from the .PRJ file, and I set “LL83” as the destination projection. So perhaps I have the source or destination EPSG code wrong. 
  
 Here is the details/output from FME, maybe that will help: 
  
 FME Configuration: Destination coordinate system set to `LL83’ 
 Coordinate System `LL83’ parameters: CS_NAME=`LL83’ DESC_NM=`NAD83 Lat/Long’s, Degrees, -180 ==> +180’ DT_NAME=`NAD83’ GROUP=`LL’ MAP_SCL=`1’ MAX_LAT=`90’ MAX_LNG=`180’ MIN_LAT=`-90’ MIN_LNG=`-180’ PROJ=`LL’ QUAD=`1’ SCL_RED=`1’ SOURCE=`Mentor Software’ UNIT=`DEGREE’ ZERO_X=`1e-009’ ZERO_Y=`1e-009’ 
 Coordinate System `LL83’ as OGC Well Known Text: GEOGCS[“NAD83 Lat/Long’s, Degrees, -180 ==> +180”,DATUM[“North_American_Datum_1983”,SPHEROID[“Geodetic Reference System of 1980”,6378137,298.2572221009113],AUTHORITY[“EPSG”,“6269”]],PRIMEM[“Greenwich”,0],UNIT[“degree”,0.0174532925199433]] 
  
 The OGC definition of the FME coordinate system ‘LL-27’ is ‘GEOGCS[“GCS_North_American_1927”,DATUM[“D_North_American_1927”,SPHEROID[“Clarke_1866”,6378206.4,294.9786982]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]]’. 
 FME Configuration: Source coordinate system for reader SHAPE_IN[SHAPE] set to `LL-27’ as read from input data 
 Coordinate System `LL-27’ parameters: CS_NAME=`LL-27’ DT_NAME=`NAD27’ ESRI_WKT=`GEOGCS[“GCS_North_American_1927”,DATUM[“D_North_American_1927”,SPHEROID[“Clarke_1866”,6378206.4,294.9786982]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]]’ MAP_SCL=`1.0’ PROJ=`LL’ UNIT=`DEGREE’ 
 Coordinate System `LL-27’ as OGC Well Known Text: GEOGCS[“North_American_Datum_1927”,DATUM[“North_American_Datum_1927”,SPHEROID[“Clarke - 1866”,6378206.4,294.9786982139006],AUTHORITY[“EPSG”,“6267”]],PRIMEM[“Greenwich”,0],UNIT[“degree”,0.0174532925199433]] 
  
 Reproject: Using datum conversion type `Nad27ToNad83’ 
 Reproject:`Nad27ToNad83’ will use the following grid shift files: 
 Reproject:     .\GridData\Canada\ntv2_0.gsb  
 Reproject: The following fallback datum will be used `NAD27-48’

#6

 I went to the bottom of the problem by testing the change in value in X and Y of a point going from ESPG 4267 (NAD27) to ESPG 4269 (NAD83). What should happen here is a Datum Shift from NAD27 to NAD83 while staying in Geodetic and as you can see on the map below, for this area in California, there should be a difference of more than 80 meters. But by doing the test with the code below, no change in X and Y is happening. That leads me to think that there is a bug with ManagedProj4Projection where the datum shift is not occuring. I pass the problem to the developement team so that they can determine exactely what is going on.



 



           ManagedProj4Projection proj1 = new ManagedProj4Projection();
            proj1.InternalProjectionParameters = ManagedProj4Projection.GetEpsgParameters(4267); //"+proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs"; //4267);
            proj1.ExternalProjectionParameters = ManagedProj4Projection.GetEpsgParameters(4269); //"+proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs" 

            proj1.Open();
            //shiftVertex.X should be different from -119.1448
            //shiftVertex.Y should be different from 34.248
            Vertex shiftedVertex = proj1.ConvertToExternalProjection(-119.1448, 34.248);
            proj1.Close();


#7

 


Hi Rob,
Sorry for waiting so long time. The issue is caused by the proj4 library used in MapSuite. It seems like there is something missed in the code when do the conversion between “EPSG:4267 (NAD27)” to “EPSG:4269 (NAD83)”. We has submitted it into issue list and hope it can be fixed in the future. Now please try the workaround introduced as following.
Just shown in the attached sample, we defined a custom projection called “MyProjection” to especially do the conversion from “EPSG:4267 (NAD27)” to “EPSG:4269 (NAD83)” only, it’s inherited from Projection and references assembly “MapSuiteCommon.dll”. Here is the code about how to use it:

string dir = Server.MapPath(@"~\App_Data") + @"\";
string originalFile = dir + "Original.shp";
string convertedFmeFile = dir + "FME_Converted.shp";
string convertedThinkgeoFile = dir + "TG_Converted.shp";

MyProjection myProjection = new MyProjection();
ShapeFileFeatureLayer.SaveToProjection(originalFile, convertedThinkgeoFile, myProjection, OverwriteMode.Overwrite);
ShapeFileFeatureLayer.BuildIndexFile(convertedThinkgeoFile, BuildIndexMode.DoNotRebuild);

PS: We remove the data referenced in the sample because of the limitation of the size allowed by the forum.

 


Thanks,
Johnny

Post8419.zip (229 KB)