This project is read-only.

DotSpatial.Projections Transform Issue

Sep 10, 2010 at 8:29 PM

When performing a transform from NAD1983UTM11 to WGS1984, there are no issues.

N,E,Z coordinates in, Lat/Long generated (decimal degrees).

Data used is:

xy(0) = 337286.313 (easting)
xy(1) = 4694674.076 (northing)
z(0) = 182.366 (elevation)

myProjIn = DotSpatial.Projections.KnownCoordinateSystems.Projected.NationalGridsCanada.NAD1983MTM1
myProjOut = DotSpatial.Projections.KnownCoordinateSystems.Geographic.World.WGS1984
Reproject.ReprojectPoints(xy, z, myProjIn, myProjOut, 0, 1)
 
Results:
 
xy(0)=-82.1054299846804 (longitude)
xy(1)=42.391001348558135 (latitude)
z(0)=182.366 (height)
 
Correct! 

When performing a transform from WGS1984 to NAD1983UTM11, there are issues.

Lat/Long/Height in (decimal degrees), NEZ not generated?

Data used is:

xy(0) = -82.105429984679 (longitude)
xy(1) = 42.3910013476671 (latitude)
z(0) = 182.366 (height)

myProjIn = DotSpatial.Projections.KnownCoordinateSystems.Geographic.World.WGS1984
myProjOut = DotSpatial.Projections.KnownCoordinateSystems.Projected.NationalGridsCanada.NAD1983MTM1
Reproject.ReprojectPoints(xy, z, myProjIn, myProjOut, 0, 1)

Results:

xy(0)=-1.#IND
xy(1)=-1.#IND
z(0)=182.366

Also, if my projection of WGS1984 is a GeographicInfo, how do I go about setting this to a ProjectionInfo, because Reproject.ReprojectPoints is excpecting both systems to be Projections.ProjectionInfo and not a Projections,GeographicInfo.

For example, the user is selecting the GeographicInfo and ProjectionInfo values from list boxes.

Dim myGeographic As New DotSpatial.Projections.GeographicInfo
myGeographic.Name = ComboBox2.Text
Dim myProjection As New DotSpatial.Projections.ProjectionInfo
myProjection.Name = ComboBox5.Text

So how does myGeographicInfo become a ProjectionInfo required by Reprohject?

Thanks,

Terry

 

 

Sep 10, 2010 at 9:26 PM

I will post the projection bug you are getting to our issues list (instead of the discussion board).  It will be addressed in a cue of other issues, but basically we are making steady progress against bugs like this in the system, and every user that posts a problem they are having helps us to make it better.

As to your second question about converting between Geographic and Projection info classes, every projected coordinate system incorporates a "GeographicInfo" property as part of its description, but it also describes additional content.   For specifying known projections, I strongly recommend using the KnownCoordinateSytems class, which lets you create the proper ProjectionInfo class for both projected and geographic coordinate systems.  For geographic systems, I think you want to set the "IsLatLong" property to true, and then flesh out the GeographicInfo class.  You can also read in ESRI strings or Proj4 strings if you are starting from either of those.

There is also a built in projections dialog that you can use to make your life easier as a programmer.  If you don't mind the appearance of the form, it would save you a lot of time to use it.  However, there are plans to pull the windows form out from DotSpatial.Projections since forms are a problem for some developers.

Shade1974 (Ted)

 

 

Sep 15, 2010 at 3:43 PM

I have some general questions about the DotSpatial implementation of Proj4.

As fixes/enhancements are made to the OSGeo implementation of Proj4, how do we ensure the DS port of Proj4 is kept up-to-date, or do we? 

Sep 15, 2010 at 5:37 PM

We set up over 3000 unit tests to compare each of our coordinate system transformations to a version that adds a reference to proj4.  Since the internal code of Proj4 effectively transforms coordinate system A to WGS84 and from WGS84 to projection B, if every coordinate system has a unit test that transforms A into WGS84 and then from WGS84 back to A, it should be sufficient to trigger any bugs that would occur.  These unit tests are for the projections that are shared between ArcGIS and Proj4, so there are projections in each of those worlds that we didn't implement, but that have no corresponding representation in the other domain.  Having the unit tests means that all we have to do is swap out the version of the proj4.dll that the unit test library uses for its comparisons and run all the tests.  It will tell us which coordinate systems are no longer identical with the proj4 dll, but it will not tell us about new projections added to proj4, or the ESRI sets.  At the moment we haven't even fixed all the bugs with the ones we have implemented, but it's on the to-do list and something like 3000 of the 3200 total coordinate systems pass inspection.  In point of fact, there are only something like 55 mathematical projections common between ArcGIS and Proj4, and of those only about 10 are used with any regularity.  The mathematical projections themselves are reused by many different "Coordinate Systems" which effectively plug in slightly different parameters to the same mathematical transform.  It is also very unlikely for either those parameters or the fundamental math to change once it is established.  The reality is that once UTM Zone 60 North is defined, that definition will not change with regard to how it gets to WGS84.  The only real updates we would expect would be adding new coordinate systems/projections.  This falls into the category of new feature implementation, and is not as dire as bug fixing.  Since proj4 might have bugs itself, however, we have the unit tests to help identify if updates to proj4 include bug fixes that change the math for their coordinate systems.