From: Rueben Schulz <r_j_schulz@ya...>  20030317 05:24:29

Hello, After spending some more time with cts and some epsg and other coordinate transformation references, I am finally at the point were I can trace what is happening in the cts module. I now, hopefully, understand things well enough to start doing some real work. My focus so far has been on datum shifts, since this seemed like a good place to start. So far I have not found any problem with the equations used or any test case that show a problem (my tests have only used 3 parameters for the datum shift up to this point). If anyone has a case that fails please send it to me. I suspect that the cause of one of the failure in CT_TestScript.txt is in the transverse mercator projection. I have now started looking into the equations for this. What I need is an idea of how to go about doing this. Any comments to help me accomplish this will be appreciated. This is my current plan for doing this: 1) start moving the projections to a proj subpackage as Martin suggested. 2) cheak the equations against the proj and/or epgs/snyder references and test them against simple test cases. 3) repeat for each projection I started learning the transverse mercator yesterday, but proj uses different equations from epgs, so this is going to take some time. I plan to work on this steadily, but learning more about geodesy and projections is taking up much of my effort so far. Rueben On Thu, 20030227 at 06:52, Martin Desruisseaux wrote: > Hello > > Sorry to disturb peoples again with this issue, but coordinate > transformation problems are hurting Geotools's users again and again. > As I see it, there is three mean problems: > > * Datum shift probably broken. > > * Some transforms like Conic Lambert 1SP not implemented. > > * Transformation formulas seems corrects (they come from the Proj4 > library), but I'm really not sure that parameters like "central > latitude" and the like are used correctly for formulas > initialization. > > > We badly need a volonter here. In order to make easier to look at the > projection code, we should create a org.geotools.ct.proj subpackage > and move there all classes ending with "Projection" (less than 10). > Then, some refactoring should be done (e.g. splitting code for > elliptical and spherical ellipsoid). Then, comparaison should be made > with Proj4j. Is someone up to look at that? I would be very happy to > give stepbystep indications, but can't do them myself (I'm in a > terrible rush with my work). > > Martin. 
From: Martin Desruisseaux <martin.desruisseaux@te...>  20030317 09:25:25

Rueben Schulz a =E9crit: > My focus so far has been on datum shifts, since this seemed like a good > place to start. So far I have not found any problem with the equations > used or any test case that show a problem (my tests have only used 3 > parameters for the datum shift up to this point). If anyone has a case > that fails please send it to me. Datum shift was just a guess from me. I had no proof that it failed. I'm=20 sorry if I misleaded you with that... Anyway, I would be very happy if I could gets your test cases (if you=20 want of course). I would add them to the ctscoordtrans/tests/unit=20 directory. > I suspect that the cause of one of the failure in CT_TestScript.txt is > in the transverse mercator projection. I have now started looking into > the equations for this. What I need is an idea of how to go about doing > this. Any comments to help me accomplish this will be appreciated. >=20 > This is my current plan for doing this: >=20 > 1) start moving the projections to a proj subpackage as Martin > suggested.=20 > 2) cheak the equations against the proj and/or epgs/snyder references > and test them against simple test cases.=20 > 3) repeat for each projection Sound good. A possible approach too may be to start with the plain=20 Mercator projection rather than TransverseMercator. The cylindrical=20 Mercator projection is much simplier. Furthermore, the=20 TransverseMercator projection is basically a Mercator projection rotated=20 90=B0. This simple rotation has huge impact that make the formulas much=20 more complex. I suggest that starting with Mercator projection may be a=20 gentler curve. There is an other point to take in account: it is possible that the=20 formulas are correct, but the projection initialization isn't (i.e. the=20 way the constructor uses the ParameterList). For example, do I do the=20 right thing with "central_latitude"? Actually, I tend to favor this=20 hypothesis at this time (but I already misleaded you one time, so be=20 careful with my word!) > I started learning the transverse mercator yesterday, but proj uses > different equations from epgs, so this is going to take some time. I > plan to work on this steadily, but learning more about geodesy and > projections is taking up much of my effort so far. I'm not sure (since I'm not the original author of the projection=20 formulas used there), but I thing that the formulas are derivated from=20 the Proj4 package, available there: http://remotesensing.org/proj/ However, the derivative work was done many years ago, and it is quite=20 possible that the Proj4 formulas as evolved since this time. As part of=20 refactoring the projection code in a 'proj' package, it may not be a bad=20 idea to put it in closer sync with Proj4. If we go among this path, then=20 we should put a very clear comment at the begining of every Java classe=20 or method saying from wich Proj4 file (together with the Proj4 version=20 number and date!) the formulas come from. Of course, the Proj4J module=20 in Geotools 2 may be a good starting point! I will commit a 'proj' subpackage with abstract 'MapProjection' classes=20 in a few minutes, and will send a new notice on this mailing list. Thank again for your hard work, it is truly appreciated! Martin. 
From: Rueben Schulz <r_j_schulz@ya...>  20030318 04:38:16

On Mon, 20030317 at 01:26, Martin Desruisseaux wrote: > Rueben Schulz a =E9crit: > > My focus so far has been on datum shifts, since this seemed like a good > > place to start. So far I have not found any problem with the equations > > used or any test case that show a problem (my tests have only used 3 > > parameters for the datum shift up to this point). If anyone has a case > > that fails please send it to me. >=20 > Datum shift was just a guess from me. I had no proof that it failed. I'm=20 > sorry if I misleaded you with that... >=20 > Anyway, I would be very happy if I could gets your test cases (if you=20 > want of course). I would add them to the ctscoordtrans/tests/unit=20 > directory. >=20 I went through datum shifts knowing my test cases worked. It was a good, way to start looking at cts and figuring out how it worked. Plus I did not know the equations for geodetic  > geocentric transforms before this.=20 I will pass on my additions to Simple_TestScript in a few days, once I clean up what I did (I put in comments, but they are a bit messy). >=20 > > I suspect that the cause of one of the failure in CT_TestScript.txt is > > in the transverse mercator projection. I have now started looking into > > the equations for this. What I need is an idea of how to go about doing > > this. Any comments to help me accomplish this will be appreciated. > >=20 > > This is my current plan for doing this: > >=20 > > 1) start moving the projections to a proj subpackage as Martin > > suggested.=20 > > 2) cheak the equations against the proj and/or epgs/snyder references > > and test them against simple test cases.=20 > > 3) repeat for each projection >=20 > Sound good. A possible approach too may be to start with the plain=20 > Mercator projection rather than TransverseMercator. The cylindrical=20 > Mercator projection is much simplier. Furthermore, the=20 > TransverseMercator projection is basically a Mercator projection rotated=20 > 90=B0. This simple rotation has huge impact that make the formulas much=20 > more complex. I suggest that starting with Mercator projection may be a=20 > gentler curve. >=20 Yes, this is a good idea. If I start with TransverseMercator, I will probably get overwhelmed.=20 > There is an other point to take in account: it is possible that the=20 > formulas are correct, but the projection initialization isn't (i.e. the=20 > way the constructor uses the ParameterList). For example, do I do the=20 > right thing with "central_latitude"? Actually, I tend to favor this=20 > hypothesis at this time (but I already misleaded you one time, so be=20 > careful with my word!) >=20 This is my suspicion as well. The cases that fail are using the british=20 national grid that uses a latitude of origin of 49 deg.=20 >=20 > > I started learning the transverse mercator yesterday, but proj uses > > different equations from epgs, so this is going to take some time. I > > plan to work on this steadily, but learning more about geodesy and > > projections is taking up much of my effort so far. >=20 > I'm not sure (since I'm not the original author of the projection=20 > formulas used there), but I thing that the formulas are derivated from=20 > the Proj4 package, available there: >=20 > http://remotesensing.org/proj/ >=20 > However, the derivative work was done many years ago, and it is quite=20 > possible that the Proj4 formulas as evolved since this time. As part of=20 > refactoring the projection code in a 'proj' package, it may not be a bad=20 > idea to put it in closer sync with Proj4. If we go among this path, then=20 > we should put a very clear comment at the begining of every Java classe=20 > or method saying from wich Proj4 file (together with the Proj4 version=20 > number and date!) the formulas come from. Of course, the Proj4J module=20 > in Geotools 2 may be a good starting point! >=20 > I will commit a 'proj' subpackage with abstract 'MapProjection' classes=20 > in a few minutes, and will send a new notice on this mailing list. >=20 I will start on this in the next few days. Hopefully I will be able to get=20 Mercator working by the weekend. I may need your help to get the new projec= tion=20 code working with cts though. But that can wait for latter.=20 > Thank again for your hard work, it is truly appreciated! >=20 > Martin. >=20 >=20 >=20 >  > This SF.net email is sponsored by:Crypto Challenge is now open!=20 > Get cracking and register here for some mind boggling fun and=20 > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgibin/redirect.pl?thaw0031en > _______________________________________________ > Geotoolsdevel mailing list > Geotoolsdevel@... > https://lists.sourceforge.net/lists/listinfo/geotoolsdevel 
From: Martin Desruisseaux <martin.desruisseaux@te...>  20030317 14:45:32

Hello Rueben A new 'proj' subpackage has been commited. It contains a 'MapProjection' base class, which is the only nontrivial one in this package (except maybe Provider, which may be ignored for now). Other classes are an Exception and some MapProjection subclasses mostly for documentation purpose (they add no new functionalities). Only three methods need to be overriden by 'MapProjection' subclasses: * getName(...), which is trivial. * transform(...) * inverseTransform(...) My proposal: Lets start with MercatorProjection, since it is the simpliest one. Copy it in the 'proj' package and rename it only 'Mercator' (since we are in the 'proj' package, I think we can ommit the 'Projection' suffix. 'MapProjection' and its friends are exceptions since 'Map' would have been a little bit short...). Add yours name in the @author tag :) and do some refactoring: * the 'transform' and 'inverseTransform' implementation currently contains code like: if (isSpherical) { // Do some stuff } else { // Do some stuff } I have removed the 'isSpherical' flag. Instead, the implementation for ellipsoidal and spherical projections should be splitted in two classes: 1) The main Mercator class contains formulas for the ellipsoidal projection only. 2) An inner class contains formulas for the spherical projection only. This inner class should be declared as below: protected static class Spherical extends Mercator { } Just override the 'transform' and 'inverseTransform' method with the code currently inside the 'if (isSpherical)' blocks. Then, test it as extensively as we can (note: if you agree, we will add your test code in the ctscoordtrans/tests directory). Next, go on with LamberConformalProjection (which is the second simpliest after Mercator), then TransverseMercator and lastly with Stereographic. Next step would be to add more projections. Best regards, Martin. 
From: Martin Desruisseaux <martin.desruisseaux@te...>  20030321 11:40:42

Hello Rueben Rueben Schulz a =E9crit: > I now have Mercator working on its own. I still have to compare the > equations to snyder/proj and do more testing. Hopefully I will have tim= e > on the weekend.=20 Great!!! > In the old MercatorProjection class there are hashcode() and equals() > methods. Are these needed in the new map projection classes. They are i= n > the super class, but I do not yet fully understand what the hashcode > does and the equals() method was testing for the easy case of transform > =3D=3D this. We are better to provides them. Don't botter with that. Just copy them=20 from the old MercatorProjection to the new one, and I will take care of=20 checking them. > Also, what needs to be done to integrate these new projections with cts. > I see a change will be needed in MathTrasformFactory. Are there any > others? No. MathTransformFactory is the only change. Again, I can take care of=20 that. Once the new Mercator (or maybe we should name it=20 CylindricalMercator) projection will be working and tested, I will make=20 the change in MathTransformFactory and delete the old MercatorProjection. Regards, Martin. 
From: Rueben Schulz <r_j_schulz@ya...>  20030328 06:15:27
Attachments:
Simple_TestScript.txt
Mercator.java

To Martin, Attached is my copy of Simple_TestScript with the tests I did for the datum shifts. Feel free to include this with the cts testing. I also have a transverse mercator test that failed, but will leave that out until I am working on that projection.=20 The projections are taking more time than I thought, but hopefully this will change once I get over the initial learning curve. Also attached is the current version of Mercator.java. It is almost done, but I have a few questions: 1) where is the best place to put constants shared by mercator and the spheroid inner class. Right now I have 2 copies of them, because I cannot think of a better way. 2)should the 2SP mercator case be handled separately, the way it is for Lambert? Right now this class handles both 1SP and 2SP cases.=20 3)does the Sphere inner class need to override Provider as well, and will this require a new provider to be listed in MathTransformFactory to use it? I will start on Lambert once I get these issues and a bit more testing done. Thank you, Rueben On Fri, 20030321 at 03:41, Martin Desruisseaux wrote:=20 > Hello Rueben >=20 > Rueben Schulz a =E9crit: > > I now have Mercator working on its own. I still have to compare the > > equations to snyder/proj and do more testing. Hopefully I will have tim= e > > on the weekend.=20 >=20 > Great!!! >=20 >=20 > > In the old MercatorProjection class there are hashcode() and equals() > > methods. Are these needed in the new map projection classes. They are i= n > > the super class, but I do not yet fully understand what the hashcode > > does and the equals() method was testing for the easy case of transform > > =3D=3D this. >=20 > We are better to provides them. Don't botter with that. Just copy them=20 > from the old MercatorProjection to the new one, and I will take care of=20 > checking them. >=20 >=20 >=20 > > Also, what needs to be done to integrate these new projections with cts= . > > I see a change will be needed in MathTrasformFactory. Are there any > > others? >=20 > No. MathTransformFactory is the only change. Again, I can take care of=20 > that. Once the new Mercator (or maybe we should name it=20 > CylindricalMercator) projection will be working and tested, I will make=20 > the change in MathTransformFactory and delete the old MercatorProjection. >=20 > Regards, >=20 > Martin. >=20 >=20 >=20 >  > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Geotoolsdevel mailing list > Geotoolsdevel@... > https://lists.sourceforge.net/lists/listinfo/geotoolsdevel 
From: Cameron Shorter <cameron@sh...>  20030317 19:35:30

On Monday 17 Mar 2003 4:29 pm, Rueben Schulz wrote: > After spending some more time with cts and some epsg and other > coordinate transformation references, I am finally at the point were I > can trace what is happening in the cts module. I now, hopefully, > understand things well enough to start doing some real work. Another useful thing you might be interested in is to write up the CTS design for the http://geotools.org/gt2docs/design.html .  Cameron Shorter http://shorter.net/cameron Open Source Developer http://mapbuilder.sourceforge.net http://geotools.sourceforge.net Software Engineer/Team Lead http://www.adilimited.com/ 
From: Rueben Schulz <r_j_schulz@ya...>  20030318 04:38:14

Hi, I doubt I know enough about the design, at present, to contribute much. What I did do was trace out how CoordinateTransformationFactory decides which transforms to use and how these equations are applied. The one thing that did (and still does a bit) confuse me when I started learning cts were the adapters. This is discussed in the design document, but made more sense to me when I found an older email discussing them. It that email, Martin gave 3 lines of code to create a org.opengis interface. They were: Ellipsoid e = CoordinateSystemFactory.createEllipsoid(...); CS_Ellipsoid oe = Adapters.export(e); e = Adapters.wrap(oe); Rueben On Mon, 20030317 at 12:27, Cameron Shorter wrote: > On Monday 17 Mar 2003 4:29 pm, Rueben Schulz wrote: > > After spending some more time with cts and some epsg and other > > coordinate transformation references, I am finally at the point were I > > can trace what is happening in the cts module. I now, hopefully, > > understand things well enough to start doing some real work. > > Another useful thing you might be interested in is to write up the CTS design > for the http://geotools.org/gt2docs/design.html . > >  > Cameron Shorter http://shorter.net/cameron > Open Source Developer http://mapbuilder.sourceforge.net > http://geotools.sourceforge.net > Software Engineer/Team Lead http://www.adilimited.com/ > > > >  > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgibin/redirect.pl?thaw0031en > _______________________________________________ > Geotoolsdevel mailing list > Geotoolsdevel@... > https://lists.sourceforge.net/lists/listinfo/geotoolsdevel 
From: Martin Desruisseaux <martin.desruisseaux@te...>  20030318 09:38:17

Rueben Schulz a =E9crit: > I doubt I know enough about the design, at present, to contribute much. > What I did do was trace out how CoordinateTransformationFactory decides > which transforms to use and how these equations are applied. Sure, a bug is possible there. But 'CoordinateTransformationFactory' is=20 build on top of 'MathTransformFactory'. It means that 'MathTransform'=20 implementations are involved in an earlier stage, and are also more=20 sensitive since they are the place where Proj4 formulas live. The intent with 'proj' subpackage is precisely to make it easier to=20 forget about 'CoordinateTransformationFactory' and its friends.=20 Developpers don't have to know the overall ctscoordtrans design for=20 looking at 'proj'; one can just look at 'proj' and forget everything else. > The one thing that did (and still does a bit) confuse me when I started > learning cts were the adapters. This is discussed in the design > document, but made more sense to me when I found an older email > discussing them. The Adapters trick still a controversal approach. Normally, we should=20 extends directly the OpenGIS interfaces. However, I didn't do this that=20 way because, in my point of view, OpenGIS interfaces are good for what=20 they are designed for: interoperability with different language,=20 software and distant machines. However, they are suboptimal for local=20 use in Java. The following area are problematic:  Performance problem with CT_MathTransform.transformList(double[]) signature. This method is very extensively used, and OpenGIS's signature make it difficult to use it efficiently. However, OpenGIS's signature is probably the best one for RMI use.  Critical performance problem with FittedCoordinateSystem.getToBase(). OpenGIS seems to want to avoid reciprocal dependencies between packages. However, we pay here a very high price for that (FittedCoordinateSystem is extensively used in the rendering engine find in the 'renderer' module).  Behaviour of Ellipsoid.getInverseFlattening() annoying when the ellipsoid is spherical. The OpenGIS behaviour is a compromise for language without infinite numbers. Java doesn't suffer this limitation, since it has Double.POSITIVE_INFINITY.  'throw RemoteException' declared in many places, since OpenGIS interfaces are designed for RMI use. It put some burden on the developper side when RMI are not wanted.  The 'CS_Unit' interface is a little bit poor (not sufficient for my need at least). We need a much more full featured Unit object, something among the line of JSR108 (I know, I know, this JSR is not advancing very fast at this moment...)  PT_CoordinatePoint, PT_Envelope and PT_Matrix are a little bit poor too. We can do better with our own implementation. What I would like is a revision of the OpenGIS interfaces in the GeoAPI=20 project. Or maybe the creation of a brand new set of interfaces, very=20 close to OpenGIS's one, but tuned for Java (two set of interfaces may=20 help to preserve the interoperability goal of OpenGIS interface  using=20 the same set of interfaces for interoperability and for local use in a=20 "Java only" world is like trying to apply the same solution to two=20 different problems). As long as we don't have such a set of interfaces,=20 I'm afraid it will be difficult to use the OpenGIS's one directly in an=20 efficient way... In any case, I suggest also that you ignore Adapters for now, unless you=20 need them. Martin. 
From: Martin Desruisseaux <martin.desruisseaux@te...>  20030328 10:10:38

Hello Rueben Rueben Schulz a =E9crit: > Attached is my copy of Simple_TestScript with the tests I did for the > datum shifts. Feel free to include this with the cts testing. I also > have a transverse mercator test that failed, but will leave that out > until I am working on that projection.=20 Wonderful!!! I will commit this Simple_TestScript today and lets peoples=20 know when it will be done. Many thanks for all yours work! > 1) where is the best place to put constants shared by mercator and the > spheroid inner class. Right now I have 2 copies of them, because I > cannot think of a better way. Mercator is the right place. Just declare it 'protected' instead of=20 'private' and remove the declaration in the 'Spherical' inner class. Add=20 the following constructor to 'Mercator': /** * Construct a Mercator projection with an explicit {@link #ak0} * parameter. This constructor is used for the initialisation of * spherical projection only. */ private Mercator(final Projection parameters, final double ak0) throws=20 MissingParameterException { super(parameters); this.ak0 =3D ak0; } The 'Spherical' constructor will then become: protected Spherical(final Projection parameters) throws=20 MissingParameterException { super(parameters, scaleFactor * semiMajor*Math.cos(latitudeTrueScale= )); } I removed the Math.abs(latitudeTrueScale) call since this formula use=20 'latitudeTrueScale' in Math.cos(...) only, and cos(theta) =3D=3D cos(the= ta). > 2)should the 2SP mercator case be handled separately, the way it is for > Lambert? Right now this class handles both 1SP and 2SP cases.=20 Maybe. I have to admit that I have not looked deeply to the formulas for=20 1SP. What are the differences in the formulas? > 3)does the Sphere inner class need to override Provider as well, and > will this require a new provider to be listed in MathTransformFactory t= o > use it? No. Instead, the existing Provider need to be updated. Replace the=20 following line in the 'create' method: return new Mercator(parameters); By: if (isSpherical(parameters)) { return new Spherical(parameters); } else { return new Mercator(parameters); } I will commit the 'isSpherical(Projection)' convenience method in a few=20 minutes (right now it doesn't exists). > I will start on Lambert once I get these issues and a bit more testing > done. Great!!! Martin. 
From: Martin Desruisseaux <martin.desruisseaux@te...>  20030328 10:57:16

Martin Desruisseaux a =E9crit: > I will commit the 'isSpherical(Projection)' convenience method in a few= =20 > minutes (right now it doesn't exists). Done. I also changed the 'create(Projection)' method from 'protected'=20 access to 'public'. This change will need to be caried in Provider inner=20 class as well. Martin. 
From: Rueben Schulz <r_j_schulz@ya...>  20030329 08:11:01

To Martin, Thanks. I have a few more questions/ comments. First on Mercator_2SP. The only difference in the formula is the calculation of the scale factor. For 2SP (ellipse), the scalefactor is multiplied by msfn(...). This function needs values from the standard parallels (does not mater which one if abs() used). This additional scalefactor =3D 1 when the equator is the standard parallel, so it works in all cases. Right now the standard parallel is coming from the centralLatitude parameter. Anyone who wants to use Mercator_2SP needs to set the centralLatitude to one of their standard parallels. A specific 2SP version would allow for first and second parallel parameters to be added and set (it is also listed in the cts specification, but valid parameters are not shown). I have implemented your suggestions below (thanks), but have two problems.=20 1) calling the new Mercator constructor from the Spherical constructor has the problem of needing mapProjection constants (to calculate aKO) before they have been fetched. I can get around this by getting them directly from parameters, but this is a bit messy.(I can not think of anything else, almost time for bed). 2) using the isSpherical() method from the static Provider class is giving me problems. Solutions I can think of are to make it static and to take parameters as an argument. Can you think of any less annoying solutions? Thank you again for the help, Rueben On Fri, 20030328 at 02:11, Martin Desruisseaux wrote: > Hello Rueben >=20 > Rueben Schulz a =E9crit: > > Attached is my copy of Simple_TestScript with the tests I did for the > > datum shifts. Feel free to include this with the cts testing. I also > > have a transverse mercator test that failed, but will leave that out > > until I am working on that projection.=20 >=20 > Wonderful!!! I will commit this Simple_TestScript today and lets peoples=20 > know when it will be done. Many thanks for all yours work! >=20 >=20 >=20 >=20 > > 1) where is the best place to put constants shared by mercator and the > > spheroid inner class. Right now I have 2 copies of them, because I > > cannot think of a better way. >=20 > Mercator is the right place. Just declare it 'protected' instead of=20 > 'private' and remove the declaration in the 'Spherical' inner class. Add=20 > the following constructor to 'Mercator': >=20 >=20 > /** > * Construct a Mercator projection with an explicit {@link #ak0} > * parameter. This constructor is used for the initialisation of > * spherical projection only. > */ > private Mercator(final Projection parameters, final double ak0) throws=20 > MissingParameterException { > super(parameters); > this.ak0 =3D ak0; > } >=20 >=20 >=20 > The 'Spherical' constructor will then become: >=20 > protected Spherical(final Projection parameters) throws=20 > MissingParameterException { > super(parameters, scaleFactor * semiMajor*Math.cos(latitudeTrueScale= )); > } >=20 >=20 > I removed the Math.abs(latitudeTrueScale) call since this formula use=20 > 'latitudeTrueScale' in Math.cos(...) only, and cos(theta) =3D=3D cos(the= ta). >=20 >=20 >=20 >=20 >=20 > > 2)should the 2SP mercator case be handled separately, the way it is for > > Lambert? Right now this class handles both 1SP and 2SP cases.=20 >=20 > Maybe. I have to admit that I have not looked deeply to the formulas for=20 > 1SP. What are the differences in the formulas? >=20 >=20 >=20 > > 3)does the Sphere inner class need to override Provider as well, and > > will this require a new provider to be listed in MathTransformFactory t= o > > use it? >=20 > No. Instead, the existing Provider need to be updated. Replace the=20 > following line in the 'create' method: >=20 > return new Mercator(parameters); >=20 > By: >=20 > if (isSpherical(parameters)) { > return new Spherical(parameters); > } else { > return new Mercator(parameters); > } >=20 >=20 > I will commit the 'isSpherical(Projection)' convenience method in a few=20 > minutes (right now it doesn't exists). >=20 >=20 >=20 > > I will start on Lambert once I get these issues and a bit more testing > > done. >=20 >=20 > Great!!! >=20 > Martin. 
From: Rueben Schulz <r_j_schulz@ya...>  20030331 01:26:17
Attachments:
Mercator.java

To Martin, I have sorted most of this out and can finally produce a Mercator transform from the MathTransformFactory (I was using the constructor directly in my testing before). Attached is a newer version of Mercator. My comments are below. On Sat, 20030329 at 12:23, Martin Desruisseaux wrote: > Hello >=20 > Rueben Schulz a =E9crit: > > First on Mercator_2SP. The only difference in the formula is the > > calculation of the scale factor. For 2SP (ellipse), the scalefactor is > > multiplied by msfn(...). This function needs values from the standard > > parallels (does not mater which one if abs() used). This additional > > scalefactor =3D 1 when the equator is the standard parallel, so it work= s > > in all cases. >=20 > Thank for the precision. Then, we need to update the Provider in such a=20 > way that it can be used as a provider for both Mercator_1SP and=20 > Mercator_2SP. I propose to add a boolean arguments to the constructor.=20 > If the boolean argument is <code>false</code>, this is a Provider for=20 > Mercator_1SP. Otherwise, this is a provider for Mercator_2SP. >=20 Done >=20 >=20 > > Right now the standard parallel is coming from the centralLatitude > > parameter. Anyone who wants to use Mercator_2SP needs to set the > > centralLatitude to one of their standard parallels. A specific 2SP > > version would allow for first and second parallel parameters to be adde= d > > and set (it is also listed in the cts specification, but valid > > parameters are not shown). >=20 > The 'centralLatitude' name in MapProjection is misleading, since it is=20 > set from the "latitude_of_origin" parameter. I will rename this field as=20 > 'latitudeOfOrigin' later. >=20 > "latitude_of_origin" and "standard_parallel" should probably not be=20 > merged together as they currently are... Actually, "latitude_of_origin"=20 > is not currently supported in the Mercator projection implementation. I=20 > don't know if it should be. Is "latitude_of_origin" an OGC spec for=20 > "Mercator_1SP" / "Mercator_2SP"? It is my understanding the the latitude_of_origin for mercator is always 0. This is used for the standard parallel in the 1sp case.=20 Unfortunately the OGC CTS spec does not give parameters for mercator. They do give parameters for lambert conic 1sp and 2sp. Here the 2sp drops the scale factor and adds 1 and 2sp parameters. I think this should be the same for mercator and is what I have done currently. A related question is whether MapProjection should have constants for the 2 standard parallels. These would not be used for every projection, but could be used here and for Lambert. This may cause other problems (I justed looked at toString() for lambert). Ok, they can probably stay in the projection. Some of these issues will probably be clearer once I start working on Lambert.=20 >=20 > I suggest the following changes to the Provider constructor: >=20 > remove("latitude_of_origin"); > put("standard_parallel", 0, LATITUDE_RANGE); >=20 > Here, 0 is a default value (unless there is a better default to=20 > provides?). Then, the 3 first lines of the Mercator constructor should=20 > replaced by: >=20 > super(parameters); > final double latitudeTrueScale =3D=20 > Math.abs(latitudeToRadians(parameters.getValue("standard_parallel", 0),=20 > false)); >=20 >=20 > Actually, if my understanding is right, "latitudeTrueScale" should be=20 > renamed by "standardParallel". Is it right? (I mean is=20 > "standardParallel" intentended to do what "latitudeTrueScale" actually do= ?) >=20 I think they are the same for the mercator. You will notice that I have added a parameter to the mercator constructor (boolean sp2). In the 1sp case, the standard parallel used for the scale factor calculation is the latitude of origin (this results in no change to the scale factor). In the 2sp case the abs() of one of the standard parallel is used.=20 >=20 >=20 >=20 > > 1) calling the new Mercator constructor from the Spherical constructor > > has the problem of needing mapProjection constants (to calculate aKO) > > before they have been fetched. I can get around this by getting them > > directly from parameters, but this is a bit messy.(I can not think of > > anything else, almost time for bed). >=20 > Good point; I didn't thank about that. Then, I propose an alternative way= : >=20 > Replace the Mercator constructor by the following one: >=20 > final double standardParallel =3D=20 > Math.abs(latitudeToRadians(parameters.getValue("standard_parallel", 0),=20 > false)); >=20 > ////////////////////////// > // Compute constants // > ////////////////////////// > if (isSpherical()) { > ak0 =3D scaleFactor * semiMajor*Math.cos(standardParallel); > } else { > ak0 =3D scaleFactor * semiMajor*msfn(Math.sin(standardParallel),=20 > Math.cos(standardParallel)); > } >=20 >=20 > As you see, it is basically the old contructor except that I replaced=20 > the 'isSpherical' field by a method call (you may need to perform a CVS=20 > update in order to gets this 'isSpherical()' method) and renamed=20 > "latitudeTrueScale" by "standardParallel", as suggested above. >=20 > This approach is an exception to the rules saying that the mathematic=20 > for spherical model should be isolated in a "Spherical" inner class. But=20 > may have no real choice (especially with the LamberConical constructor,=20 > when we will be there). I think it is okay, since the most important=20 > place for spherical/ellipsoidal separation is in transform and=20 > inverseTransform methods. >=20 > The constructor for Spherical would then be: >=20 > super(parameters); > assert isSpherical(); >=20 > It just lets Projection do that work, and I added a "isSpherical()"=20 > assertion just as a precaution. >=20 >=20 >=20 >=20 >=20 > > 2) using the isSpherical() method from the static Provider class is > > giving me problems. Solutions I can think of are to make it static and > > to take parameters as an argument. Can you think of any less annoying > > solutions? >=20 > Oups! It should has been static!!! Thank for pointing that out. I will=20 > commit the fix in a few seconds. >=20 > Best regards, >=20 > Martin. >=20 