Re: [Geotools-devel] Stereographic projection update

[Rueben S. <r_j...@ya...>]

To Martin,

Some comments below.

On Mon, 2004-02-23 at 07:08, Martin Desruisseaux wrote:
> Rueben Schulz a =E9crit :
>=20
> > Oblique_Stereographic now called Oblique_Stereographic_USGS
> > Oblique_Stereographic_EPSG now called Oblique_Stereographic
>=20
> Right. Yours Javadoc in Sterographic.java also gives nice tip. Actually=
,=20
> since ESRI's ArcGIS 8.x product use the following names:
>=20
>     "Stereographic"          for    "Oblique_Stereographic_USGS"
>     "Double Stereographic"   for    "Oblique_Stereographic"
>=20
>=20
> I suggest to adopts ESRI's naming instead of using our own.=20
> "Oblique_Stereographic" would be the EPSG alias for "Double=20
> Stereographic". Alias are allowed at least in the new GeoAPI.
>=20
> Projection Method #1:
>     authority=3D"EPSG"      name=3D"Oblique_Stereographic"
>     authority=3D"ESRI"      name=3D"Double Stereographic"
>=20
>=20
> Projection Method #2:
>     authority=3D"ESRI"      name=3D"Stereographic"
>=20
>=20
> So for now lets rename "Oblique_Stereographic_USGS" as "Stereographic"=20
> and add a @task TODO tag saying that this name should be declared as=20
> ESRI name, and ESRI name "Double Stereographic" should be added to the=20
> other projection. I will imlements alias when I will performs the CTS=20
> refactoring.

Once again, you came up with the simple solution that I did not see.
Thank you. Please change the java docs when you make the name change. I
just changed the name in the cts tutorial keyword table.


>=20
>=20
>=20
>=20
> > Polar_Stereographic_EPSG renamed Polar_Stereographic_Series (This is =
the
> > equation given by the epsg, but it calculates the same values as the
> > Polar_Stereographic (using itteration). I decided that it should have=
 a
> > functional name instead). Perhaps this class should be removed ?
>=20
> The functional name is nice. Maybe you already explained that, I don't=20
> remember: is there any advantage in one implementation instead of the=20
> other? (speed? accuracy? rubusteness to points far away?). If there is=20
> some advantages in one implementation over the other, it would be nice=20
> to said that in the Javadoc. We can decide later which one we keep.
>=20

I did the series implementation out of curiosity (it only over-rides the
inverseTransformNormalized(), so does not take up too much room). The
only benefit is a bit of speed at the expense of a bit of accuracy. The
iteration method is from proj4 and therefor better tested.=20


>=20
>=20
> > Added a rounding error check to
> > ObliqueStereographic.EPSG::inverseTransformNormalized (testing found
> > this one).
> >=20
> > Fixed PolarStereographic so sign of latitudeTrueScale is not changed
> > (added Math.abs elsewhere). This was done because I noticed that a
> > projection with a latOfOrigin of -90 was given a latitudeTrueScale of=
 90
> > (this is ok for the equations, but annoying when output in the wkt).
> >=20
> > Changed the default value of latitudeTrueScale so it is now decided i=
n
> > PolarStereographic (allows a latitudeTrueScale of -90 for south pole =
and
> > 90 for north pole).
>=20
> Nice, thank.
>=20
>=20
> > Added ObliqueStereographic.EPSG2 (should be temporary).
> >=20
> > Problems are:
> >=20
> > If you look at the testScript, you will see my new tests at the botto=
m.
> > As far as I know (from epsg correspondence from an employee at ESRI)
> > ESRI's "double stereographic" is the same as what the epsg calls the
> > oblique stereographic. Unfortunately this is not always the case (7
> > errors + some weird stuff happening with a south polar test). Notes
> > about this are in the comments in the testScript.
> >=20
> > I dusted off my original oblique stereographic implementation (EPSG2)=
 to
> > test these points. It gives the same answers as the EPSG class (plus
> > some extra errors with (0, 90) which I do not plan on fixing). EPSG2 =
was
> > based directly off the equations given by the epsg (very messy), so t=
his
> > gives me some hope that we are correct. Plus I have confidence in the
> > equations from libproj (Gerald Evenden). But, without further input f=
rom
> > esri, I am not sure who is wrong (I usually find it best to assume I =
am
> > wrong unless I have good evidence otherwise). I have ordered "The
> > Stereographic Double Projection" , a 1977 technical report from the
> > University of New Brunswick, and will pursue this further when this
> > arrives.
>=20
> I have the same approach: when I found discrepancy, I tend to suspect=20
> myself first. This is usually the best thing to do. But I also realized=
=20
> that commercial software are inaccurate more often then we believe. For=
=20
> example they were an article a few years ago in some scientific=20
> newspaper about the danger of relying to blindly on the =B4contour=A1=20
> function in Matlab. Lets see when you will have yours technical reports.

Yes, the reason that I usually use arcInfo for creating test points
(other than it being available) is that it is old and well used/tested.
There are many bugs still in ArcGIS 8.x and I suspect that I uncovered
one. However there is still a good chance that the problem was my fault,
so I will need to look into this further.


>=20
> 	Martin.
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Geotools-devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel