Some comments below.
On Mon, 2004-02-23 at 07:08, Martin Desruisseaux wrote:
> Rueben Schulz a =E9crit :
> > Oblique_Stereographic now called Oblique_Stereographic_USGS
> > Oblique_Stereographic_EPSG now called Oblique_Stereographic
> Right. Yours Javadoc in Sterographic.java also gives nice tip. Actually=
> since ESRI's ArcGIS 8.x product use the following names:
> "Stereographic" for "Oblique_Stereographic_USGS"
> "Double Stereographic" for "Oblique_Stereographic"
> 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.
> Projection Method #1:
> authority=3D"EPSG" name=3D"Oblique_Stereographic"
> authority=3D"ESRI" name=3D"Double Stereographic"
> Projection Method #2:
> authority=3D"ESRI" name=3D"Stereographic"
> 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
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.
> > Polar_Stereographic_EPSG renamed Polar_Stereographic_Series (This is =
> > equation given by the epsg, but it calculates the same values as the
> > Polar_Stereographic (using itteration). I decided that it should have=
> > functional name instead). Perhaps this class should be removed ?
> 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.
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
> > Added a rounding error check to
> > ObliqueStereographic.EPSG::inverseTransformNormalized (testing found
> > this one).
> > 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=
> > (this is ok for the equations, but annoying when output in the wkt).
> > Changed the default value of latitudeTrueScale so it is now decided i=
> > PolarStereographic (allows a latitudeTrueScale of -90 for south pole =
> > 90 for north pole).
> Nice, thank.
> > Added ObliqueStereographic.EPSG2 (should be temporary).
> > Problems are:
> > If you look at the testScript, you will see my new tests at the botto=
> > 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.
> > I dusted off my original oblique stereographic implementation (EPSG2)=
> > 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 =
> > based directly off the equations given by the epsg (very messy), so t=
> > gives me some hope that we are correct. Plus I have confidence in the
> > equations from libproj (Gerald Evenden). But, without further input f=
> > esri, I am not sure who is wrong (I usually find it best to assume I =
> > 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.
> 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=
> that commercial software are inaccurate more often then we believe. For=
> 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.
> 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!
> Geotools-devel mailing list