Transform 2868 <-> 4326 SRIDs


I'm having some trouble transforming coordinates. I've tracked down the SRID's and searched and looked at this for hours. Using one coordinate pair I've converted back and forth in ArcGIS and MsSqlSpatial to compare the results.. My initial test was over 400,000 pairs but soon realized that I missed something so I pulled one pair....

-- ESRI Transform for my input test
--> NAD1983HARNStatePlaneArizonaCentralFIPS0202Feet_Intl

dd: -110.99537 32.21563 = ft: 984923.1 443399.1

select st.x(geom),st.y(geom) from ( select geom =
ST.Transform( ST.GeomFromText('POINT( 984923.1 443399.1 )', 2868) , 4326) ) t
--> MsSqlSpatial Returns: -108.797329180134 34.9583360237288

select st.x(geom),st.y(geom) from (select geom=
ST.Transform( ST.GeomFromText('POINT(-110.99537 32.21563 )', 4326) ,2868) ) t
--> MsSqlSpatial Returns: 786844.803188649 135147.80629036

oddly ... 135147.80629036 looks real close to 443399.1 *.3048

SRID: 2868
select srtext from st.spatialrefsys where srid=2868
PROJCS["NAD83(HARN) / Arizona Central (ft)"
,SPHEROID"GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"],AUTHORITY"EPSG","6152"]

-- ESRI Projection File .prj

Thanks in advance...


Odegaard wrote Apr 17, 2007 at 6:30 PM

Here's my take on it (but untested).See the following function in MapProjection.cs:protected MapProjection(Collection<ProjectionParameter> parameters)The two projection parameters 'semimajor' and 'semiminor' should be multiplied by the linear unit of the projection. Unfortunately this is not accessible here, so the MapProjection should have an override that takes an extra parameter LinearUnit, and multiplies it to the semiminor and semimajor which is always specified in meters;The reason that only one of the values fit if you multiply by 0.3048 is that False_Northing is 0.0 which is the same value in feet and meters. If you change the False_Easting to a meter unit, both X and Y should give you a meter-unit you can multiply by 0.3048. Or in other words:(786844-700000)/0.3048+700000 = 984921 feetOf course this is just a workaround, and not a solution to the real problem.

SharpGIS wrote Aug 26, 2007 at 7:53 PM

This has been fixed in the Proj.NET library, so when the newest release has been included in MsSqlSpatial, this issue can be closed.

wrote Feb 14, 2013 at 6:56 PM